Por que “quase” todo mundo vai ter que sair do Waterfall?

Essa foi a conclusão que chegamos, depois de uma longa conversa que eu tive com os amigos gerentes de projetos: quase todo mundo vai ter que sair do waterfall.

Na verdade queria ter colocado todos, mas para quem é da PNL e conhece um pouco do metamodelo de linguagem, sabe que a palavra “todos” refere-se a uma generalização, sendo um quantificador universal, ou seja, temos que ter cautela em usarmos. Mas deixando de lado a PNL, vamos as possíveis respostas para esta pergunta.

Em 1986, Takeuchi e Nonaka escreveram que o desenvolvimento de novos produtos estava mudando e que na nova fase a ênfase era em velocidade e flexibilidade. Eles ainda completam e dizem que ao invés de trabalhar com métodos antigos, devemos criar interação com a equipe para alcançar o objetivo como uma unidade.

A competição não deve ser encarada apenas em relação a diferenciação dos produtos e a redução de custos, mas o que estava sendo buscado era diminuir o tempo que levava entre a hipótese e a validação, e o tempo de desenvolvimento.

WATERFALL

Pensando didaticamente vamos falar um pouco do waterfall, ou o famoso cascata. O projeto neste caso segue fases bem definidas, onde precisamos acabar uma para começar a outra. No modelo tradicional a saída de uma fase é o input da fase seguinte. A teoria diz que devemos planejar o projeto todo de uma vez, fazer o levantamento e o detalhamento de todos os requisitos do projeto no início e montar um extenso cronograma com atividades sucessoras e predecessoras bem definidas.

O maior risco de conduzir o seu projeto desta forma é chegar no final dele e entregar um produto obsoleto, e mesmo com a extensa descrição dos requisitos no início, você pode entregar o que o cliente não quer mais, pois o que foi detalhado é bem diferente das expectativas de hoje. Neste caso você só entrega valor no final do projeto.

Outro ponto são os ajustes periódicos, tanto no time, quanto no processo de desenvolvimento do produto. Melhorar continuamente é papel de todos em uma equipe de projeto. As reuniões para que sejam analisadas a melhor forma de se trabalhar são fundamentais para o bom andamento e motivação da equipe.

SCRUM

Os frameworks ágeis adotam a mudança como um diferencial competitivo. Nos modelos tradicionais onde seguir o plano é o objetivo, no mindset ágil o objetivo é entregar valor mais cedo, e neste cenário, as mudanças mesmos que tardias são bem vindas quando falamos de maximizar o ROI dos clientes.

O Scrum é o framework escolhido por duas a cada três pessoas* que adotam metodologias ágeis aderentes ao Manifesto Ágil e estabelece justamente o oposto do método tradicional, onde o produto é desenvolvido em sprints, de forma iterativa e incremental.

Um processo iterativo é aquele que faz progresso através de tentativas sucessivas de refinamento. A cada iteração seu produto ou serviço é melhorado. Um processo incremental é aquele em que o produto é construído e entregue por pedaços. Cada pedaço ou incremento representa uma parte completa do seu produto.

Sendo assim, os dois gráficos abaixo são verdadeiros, o primeiro representa a diminuição drástica do risco e de estarmos fazendo a coisa errada. Os ciclos curtos de feedbacks, dão maior segurança a equipe, tranquilidade ao cliente e minimiza resultados indesejados. O segundo porque entregamos o que gera mais valor primeiro, e nosso cliente começa a usar o produto o quanto antes. O retorno sobre o investimento acontece logo no início do projeto.

Procurei escrever de forma bem simples para explicar as principais diferenças. E antes de terminar vou justificar o porquê da palavra “quase” no título do artigo. Nas discussões waterfall x agile me deparo frequentemente com a pergunta: “mas e aquele cara que está construindo uma plataforma de petróleo, dá pra usar ágil”, eu respondo que é possível usar nos times, mas este é um cenário previsível e o modelo tradicional se encaixa bem. Em dezembro de 2014 a Petrobras operava 45** plataformas flutuantes e se você foi ou ainda é um destes gerentes, pode continuar no waterfall!

* (VersionOne, 2016).

** https://www.conversaafiada.com.br/economia/2015/01/15/petrobras-tem-o-maior-numero-de-plataformas-no-mundo

Sobre o autor

Rodrigo Zambon

Sólida experiência em Metodologias Ágeis e Engenharia de Software, com mais de 15 anos atuando como professor de Scrum e Kanban. No Governo do Estado do Espírito Santo, gerenciou uma variedade de projetos, tanto na área de TI, como em outros setores. Sou cientista de dados formado pela USP e atualmente estou profundamente envolvido na área de dados, desempenhando o papel de DPO (Data Protection Officer) no Governo.