Entendendo Waterfall e Scrum e quando usar?

De acordo com a página sobre o modelo waterfall na wikipédia:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model.

Que traduzindo para o português é:

A primeira definição formal do modelo waterfall é frequentemente apontada como sendo o artigo de Winston W. Royce de 1970, embora Royce não tenha usado o termo “waterfall” neste artigo. Royce apresentou este modelo como exemplo de um modelo falho e não-funcional.

Que interessante! O modelo waterfall já nasceu com a percepção de ser falho e não-funcional! E isso há mais de 40 anos atrás, então imagine hoje!

Bem, vamos dar uma olhada mais afundo no artigo do Royce:

Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.

[…]

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. […], then invariably a major redesign is required. […] The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

[…]

Hopefully, the iterative interaction between the various phases is confined to successive steps.

[…]

Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.

Traduzindo para o português:

A Figura 3 demonstra a relação iterativa entre sucessivas fases de desenvolvimento neste esquema. A ordenação dos passos é baseada no seguinte conceito: que cada passo é um progresso e o design é melhor detalhado, há uma iteração entre passos precedentes e sucedentes, mas raramente entre passos remotos na sequência.

[…]

Eu acredito neste conceito, mas a implementação descrita acima é arriscada e é um convite a falhar. O problema é ilustrado na Figura 4. A fase de teste que ocorre no final do ciclo de desenvolvimento é o primeiro evento para o qual o tempo, armazenamento transferência de entrada e saída, etc., revelam-se diferentes do que o que foi analisado. […], e então invariavelmente um redesign pesado é necessário. […] As mudanças necessárias no design serão provavelmente tão perturbadoras que os requisitos no qual o design foi feito e que proveem a razão para tudo foram violados. Ou os requisitos deverão ser modificados ou uma mudança substancial no design é necessária. O efeito é que o processo de desenvolvimento retornou à origem e então pode-se esperar um estouro de 100% no prazo e/ou nos custos.

[…]

Espera-se que a interação entre as várias fases seja confinada a passos sucessivos.

[…]

Infelizmente, para o processo ilustrado, as iterações demonstradas nunca estão confinadas a passos sucessivos.

Recomendo ler o artigo inteiro, e novamente friso que ele é do distante ano de 1970. Porém, isso continua assim até hoje, waterfall parte do preceito de que o desenvolvimento é composto por etapas rígidas e sequenciais, mas isso nunca funciona e todo mundo que já entrou em algum projeto nisso sabe porquê:

  • O cliente muda de ideia a toda hora.
  • O cliente não sabe o que quer.
  • Surgiu um bug no teste e descobrimos que há um erro lá no começo do projeto.
  • No meio do projeto acontece uma coisa e então temos que voltar e mudar um monte de coisa.
  • O usuário não gostou do produto.
  • O concorrente resolveu o problema de uma forma diferente e melhor.
  • O cliente pediu mudanças em uma determinada parte, alterando um requisito importante.
  • Existem dois ou mais requisitos em conflito.
  • O cliente uma hora diz uma coisa e depois diz o contrário.
  • Ocorreu um problema difícil de resolver no desenvolvimento e o prazo já foi pro saco.
  • Etc.

Se quiser algo mais recente, é muuuuito, mas muuuuito fácil achar na internet, poderia facilmente citar Martin Fowler, práticas de TDD, ou até mesmo o livro Head First sobre desenvolvimento ágil, que lá dentro explica porquê que o waterfall não funciona.

E agora, para garantir o meu downvote, eu vou dar a minha observação pessoal sobre o que vemos hoje em dia: De fato, é difícil achar algum material que defenda o waterfall atualmente e que venha de alguém que tenha uma mínima ideia sobre o que está falando, e não apenas papagaiando conceitos antigos que nunca se deu o trabalho de questionar.

Na lista cima eu citei alguns motivos pelo qual o waterfall falha. Basicamente tudo se resume ao fato de que as coisas mudam ao longo do tempo. O que ontem era um requisito, hoje pode não ser mais. O que ontem não era importante, hoje é fundamental. Hoje nós temos uma restrição importante, mas amanhã não temos mais. É aí que as metodologias ágeis entram: elas foram pensadas em atacar estes problemas, assumindo que estas coisas mudam ao longo do tempo e bolando estratégias para que mudanças possam ser implementadas rapidamente.

Bem, confesso que até aqui só dei metade da resposta e não falei nada sobre scrum. Não vou entrar muito em detalhes do scrum e vou apenas fazer uma lista rápida para recomendar quando usar o metodologias ágeis (de forma mais genérica, seja scrum ou não) ou quando usar waterfall, e tenho certeza que depois que você ler isso e já ter dado o downvote, ainda vai chamar os seus amigos para também votarem contra:

  • Se o seu escopo e os seus requisitos são inegocivelmente fechados, imutáveis e escritos em pedra, e o seu código é absolutamente perfeito e livre de bugs, você pode se dar bem com o waterfall. Caso contrário, eu recomendo o ágil.
  • Se a sua função ou a função da sua empresa seja gerar milhões de páginas de documentos de requisitos, regras de negócio, decisões arquiteturais, fluxogramas, etc, e estes documentos não serão lidos e nem criticados por ninguém (ou pelo menos por ninguém que tenha o poder de ser ouvido), e não é você quem vai fazer o código, então o waterfall também é para você. Caso contrário recomendo o ágil.
  • Se você planta bugs e requisitos mal-definidos de propósito no seu projeto para depois cobrar o cliente por qualquer mudança solicitada, então o waterfall também servirá para você. Caso contrário recomendo o ágil.
  • Se a sua religião, sua filosofia, seu sentido de viver, ou a sua divindade favorita lhe diz que você deve seguir planos burocráticos e rigidamente definidos simplesmente porque as coisas sempre foram assim, são assim e sempre serão assim e que você tem a obrigação de ser feliz com isso sem nunca pensar em questionar, então recomendo o waterfall. Caso contrário recomendo o ágil.

Para finalizar, respondendo a este comentário:

A propósito, certificações aeronáuticas necessitam de modelos formais de desenvolvimento. É muito mais provável que o software que rode nos aviões da Boeing, por exemplo, sejam desenvolvidos com um processo mais próximo do Waterfall do que de uma metodologia puramente ágil e informal como o Scrum. E lhe pergunto uma coisa: você prefere voar em um avião que tem certificação de software da FAA ou em um avião que foi desenvolvido sem qualquer formalidade com Scrum?

Há um caso de estudo chamado  “Combinando Scrum, AOP, DDD e Metadados – Um Caso de Sucesso na Embraer.” e os palestrantes Roberto Perillo, Tiaslei Vasni e Daniel Feichas. Eis o resumo da palestra:

Esta palestra consiste na apresentação da abordagem da criação de uma aplicação chamada AHEAD (Aircraft HEalth Analisys and Diagnosis), atualmente em andamento na área de Aviação Executiva na Embraer. A arquitetura da aplicação combina Domain-Driven Design, aspectos e metadados, cujo desenvolvimento está sendo gerenciado com SCRUM. Inicialmente, será mostrado um pequeno histórico de projetos na Embraer e porque foi decidida a utilização do SCRUM. Em seguida, serão mostrados alguns erros cometidos pela indústria de software (segundo a experiência dos membros da equipe) e os conceitos importantes para o entendimento da abordagem utilizada no design da aplicação. A seguir, serão apresentados os requisitos funcionais e não funcionais que motivaram a utilização da abordagem e como os elementos foram implementados. Será mostrado também como é o ambiente ALM que gerencia o ciclo de vida da aplicação e como foram organizados os testes (unidade, integração e sistema). Como exemplo, serão apresentadas questões relacionadas à implementação da segurança na aplicação, AJAX reverso por meio de eventos de domínio, interesses transversais e integração com outros sistemas. Na conclusão, serão apresentados os benefícios obtidos com a abordagem, como o ganho de flexibilidade na aplicação e a aceleração da velocidade da equipe no que diz respeito à produtividade.

Waterfall está em todo lugar

Primeiramente, todos os desenvolvedores usam Waterfall. Sempre. O que muda é a escala.

Não podemos burlar a sequência Requisito > Análise > Design > Implementação > Teste > Integração, simplesmente porque é impossível. Como podemos fazer análise sem requisitos, implementação sem saber o que temos que fazer ou teste sem código?

A diferença é que alguns tentam fazer tudo numa sequência, escrevem grandes blocos de código e tentam fazer rodar tudo de uma só vez. Outros, mais como o meu caso, testam o código a cada ou duas ou três linhas modificadas ou acrescentadas.

Então, posso conciliar minhas afirmações fazendo uma diferença entre um Waterfall Completo e um Micro Waterfall. Concordando com o Victor, é simplesmente impossível fazer um Waterfall Completo em um projeto de software porque sempre será necessário revisar erros e mudanças que afetam as etapas anteriores. Mesmo para corrigir um pequeno bug você precisa analisar os requisitos, fazer design de uma solução, implementá-la, testá-la. Por outro lado, o que processos ágeis fazem é diminuir o quanto for possível os time boxes para obter feedback do cliente, criando assim Micro Waterfalls.

Projetos com aparência de Waterfall

Na prática, projetos pode ser “interfaceados* com o cliente com base no modelo Waterfall Completo e micro gerenciados na equipe de desenvolvimento usando Scrum ou qualquer outra metodologia de gerenciamento ágil.

Para alguns clientes, não é interessante obter um produto muito cedo. Pensei no caso de uma mudança de lei com data para entrar em vigor. O que adianta receber o produto antes? Um projeto com um cronograma Waterfall caberia bem nesse caso. Entretanto, nada impede que o desenvolvimento seja feito com princípios ágeis, onde a cada uma ou duas semanas as funcionalidades são integradas numa versão executável, testada usando mocks, apresentada para um cliente (mesmo que não seja o cliente em si, mas um especialista em negócios).

Não podemos ter tudo

Há algum tempo escrevi um artigo sobre o triângulo de ferro. A ideia desta representação é passar a ideia de projetos de software lidam com restrições intrínsecas que não podemos simplesmente ignorar. As comumente citadas são: tempo, recursos, escopo e qualidade.

Metodologias mais tradicionais de desenvolvimento e gerenciamento de software, onde o Waterfall se enquadra muito bem, geralmente tendem a fixar tempo e escopo. O que acontece? Calcula-se o número de recursos necessários para entregar o sistema numa data, as coisas não andam como o planejado e quem sofre é a qualidade.

Processos modernos, que geralmente levam o termo “incremental e iterativo” até o limite, seguem um caminho inverso. Eles geralmente variam o escopo (acrescentando ou tirando user stories da sprint de acordo com a produtividade) para manter o tempo fixo e a qualidade num patamar aceitável.

Considerações finais

Enfim, meu conselho geral seria:

  • Para desenvolvimento de software, nunca use Waterfall no sentido completo do modelo, pois seria completamente inviável.
  • Quando, e somente quando, o cliente ou a situação exigir um cronograma rígido, encapsule o desenvolvimento em um projeto com aparência de Waterfall, mas tendo muita consciência de que, quando fixamos o tempo e o escopo, prejudicamos a qualidade. Não podemos ter tudo.

Quando usar Waterfall?

Quando os requisitos são bem definidos e sem perspectiva de mudança, como a construção de um prédio. Ou seja, muito raramente no caso de software.

Com a ressalva que boas metodologias de desenvolvimento de software costumam ser iterativas e podem definir um modelo semelhante ao waterfall como procedimento de cada iteração, embora o processo como um todo não seja Waterfall.


Quando usar Scrum?

Vou usar as características do Scrum para determinar quando é adequado utilizá-lo.

Dica: Se você vai se casar, pode usar Scrum para organizar o casamento. 🙂

Scrum é acima de tudo Ágil

O Scrum é uma das formas de se implementar metodologias ágeis; isso define a maior parte do que é o Scrum e como tal ele adota as preferências do Manifesto Ágil:

  • Indivíduos e interações em preferência a Processos e ferramentas
  • Software funcionando em preferência a Documentação extensiva
  • Colaboração do cliente em preferência a Negociação de contrato
  • Reagir a mudanças em preferência a Seguir um plano

Isso não quer dizer que os critérios do lado direito serão ignorados, mas sim que os do lado esquerdo são preferidos em relação a eles.

A adoção do Manifesto Ágil sugere um perfil de projeto para o qual o Scrum (e demais implementações de métodos ágeis) se adequa melhor:

  • Quando há expectativa de que os requisitos mudem ao longo do desenvolvimento;
  • Quando o cliente está disponível para fornecer feedback ao processo de desenvolvimento;
  • Quando documentar formalmente o processo de desenvolvimento não é crítico para o projeto;
  • Quando não é necessário que a metodologia em si determine o tipo de documentação gerada por ela.

Scrum tem características próprias

Algumas características específicas do Scrum refinam esse perfil de projeto:

  • Equipes relativamente pequenas, fisicamente próximas e capazes de se auto-organizarem;
  • Prazo mínimo de uma sprint para desenvolver o produto.

Situações em que o Scrum brilha (em comparação a métodos não-ágeis):

  • Por ser iterativo, baseado em sprints e responder rápido a mudanças, o Scrum garante que as mudanças vão ser atendidas da forma mais rápida possível, obedecendo a uma fila de prioridades e entregando o máximo de deliverables que a(s) equipe(s) têm capacidade de entregar dentro desse contexto. Ele mostra seu melhor quando o cliente, além de se preocupar em dispor dessa capacidade de resposta rápida, está ciente da importância de sua própria disponibilidade para fornecer feedback à(s) equipe(s), e deseja ter iterações do produto (entregas parciais) funcionando o mais rápido possível;
  • Quando as entregas não podem sair do prazo. Isso porque as sprints têm duração pré-definida (embora seja possível cancelar entregas).

Leitura complementar: Levantamento de requisitos e SCRU

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.

Últimos posts por Ramos de Souza Janones (exibir todos)

Share this post

scroll to top