Diferenças entre as Abordagens Preditiva (Waterfall) e Adaptativa (Ágil)

Um projeto pode demandar trabalhos que sejam bem definidos e até certo ponto conhecidos e, em outra medida, trabalhos em que exista um alto fator de incerteza.

Nos projetos de construção civil e projetos de desenvolvimento de automóveis, por exemplo, é possível utilizar com sucesso as lições aprendidas em projetos similares planejados e executados no passado. Estes são projetos, geralmente com baixo grau de incerteza e risco de execução em que a abordagem preditiva tem se mostrado bem-sucedida.

Por outro lado, quando tratamos de projetos com indefinições de escopo e alto grau de incerteza para o qual é necessário desenvolver um trabalho mais exploratório, que envolva a colaboração de especialistas para criar uma solução, a abordagem adaptativa tem se mostrado bem-sucedida.

Waterfall e o planejamento preditivo

A abordagem Waterfall, que é a tradicional do gerenciamento de projetos (também conhecida como orientada a planos, em cascata ou queda dágua) é linear e considera que todas as fases de um projeto ocorrem na forma de um processo em sequência. A abordagem depende de ferramentas previsíveis e experiência prévia. Com o Waterfall, um projeto de software (ou de outro tipo qualquer) segue o mesmo ciclo de vida, que inclui etapas como concepção, início, análise, design, construção, teste e entrega.

As melhores práticas do guia PMBOK do PMI (que mostra o que fazer, mas não como fazer)) e a metodologia PRINCE2 (que mostra o que fazer e também como fazer), são exemplos da abordagens Waterfall bastante conhecidas no campo do gerenciamento de projetos.

Com o Waterfall todo o projeto é planejado antecipadamente e isso requer atenção e cuidado, uma vez que o espaço para mudanças é pequeno. Podemos notar que tanto no guia PMBOK quanto na metodologia PRINCE2 as mudanças são rigidamente controladas. Isso significa que o escopo do projeto que foi planejado deve ser protegido. Dentro da abordagem Waterfall, as mudanças descontroladas do escopo, bastante conhecidas pelo termo “scope creep”, são um fenômeno indesejado, com impactos diretos no custo e na duração do projeto, podendo ser uma das causas de fracasso do mesmo. A abordagem Waterfall assume que existem estágios distintos para o planejamento, execução e encerramento do projeto e considera que todos os requisitos e informações necessários estejam disponíveis com antecedência. Embora haja algum espaço para replanejar durante a execução, replanejar o tempo todo implica em falha no plano inicial e risco para o projeto.

Além de tudo, o Waterfall é uma estratégia de planejamento mais preditiva que utiliza etapas e marcos específicos para controlar o processo do projeto. Uma estratégia de planejamento preditivo pode falhar quando confrontada com alterações significativas nas especificações do projeto ou modificações do cliente, mas também terá mais probabilidade de gerar o resultado esperado se houver um levantamento correto de requisitos e poucas mudanças de escopo, criando um produto final consistente e bem documentado.

Portando, o Waterfall é um processo sequencial dividido em vários estágios, no qual a equipe de desenvolvimento precisa concluir um estágio antes de prosseguir para o próximo estágio de desenvolvimento.  

2 das principais críticas ao método Waterfall

Podemos mencionar duas das principais críticas ao método Waterfall que levaram a busca de outros caminhos, especialmente nos projetos de desenvolvimento de produtos de software. Essas críticas são as seguintes:

(1)     O Waterfall não funciona bem porque os clientes podem não saber exatamente quais são seus requisitos antes de ver o software em funcionamento. Depois do software pronto e funcionando é fácil verificar o que está bom e o que deve ser melhorado. Assim, os clientes podem propor alterações e melhorias. Essas mudanças significam etapas adicionais com redesenho, retrabalho para implementar as mudanças solicitadas pelo cliente e testes adicionais. Isso também leva a custos extras. No desenvolvimento de software esse custo extra de ouvir o cliente é positivo, por ser uma forma inteligente de desenvolver um produto com maior probabilidade de criar valor para o cliente. Mas, ainda assim é um custo extra.

 

(2)     Os desenvolvedores podem não estar cientes das dificuldades futuras ao projetar um novo produto ou recurso de software. Isso leva a fazer estimativas incorretas ou, o que dá no mesmo, imprecisas. Portanto, a equipe de projeto pode elaborar um plano que deveria ser completo, mas não é por não conter todos os elementos/informações/requisitos necessários. E aí vem as seguintes questões: - Como proteger o escopo definido em um plano cujos requisitos não são claramente estabelecidos? Será que esse escopo deve ser mesmo protegido?

Então, por que não trabalhar com um plano menos detalhado (em comparação com o plano completo do Waterfall) no início para compensar o retrabalho para atender as solicitações de mudança do cliente, assumindo que mudar o escopo para atender as demandas do cliente é algo positivo para o projeto de desenvolvimento de software? Vejamos os fundamentos da aborgagem Ágil na sequência desse texto.

O Manifesto Ágil

O Manifesto Ágil (do inglês Agile) divulgado em 2001, trazia 4 valores fundamentais e 12 princípios, que segundo seus criadores, seriam os elementos vitais e orientadores de um projeto. Os fundamentos citados são os seguintes:

·         Pessoas e interação entre elas mais que processos e ferramentas;

·         Software em funcionamento mais que documentação abrangente;

·         Colaboração com o cliente mais que negociação de contratos;

·         Responder a mudanças mais que seguir um plano

Mais detalhes sobre o Manifesto Ágil acesse Agile Alliance.org

O termo “mais que” não significa que os processos e ferramentas, a documentação, a negociação de contratos e o plano do projeto desaparecem. Significa que são menos importantes do que o que é tratado na interação entre as pessoas. Significa que o software funcionando é mais relevante que elaborar uma documentação completa e abrangente, embora continue sendo importante documentar o projeto, mesmo que com menos detalhe. Significa que o mais importante é colaborar com o cliente, ao invés de se apegar a negociação do contrato, embora continue existindo um contrato formal com as regras de relacionamento técnico/comercial entre cliente e fornecedor. Que responder a mudanças é mais importante que seguir um plano, embora ainda seja necessário planejar o trabalho e medir seu progresso.

O Manifesto Ágil foi o resultado de uma reunião de profissionais de desenvolvimento de software dos EUA que estavam debatendo diferentes questões relacionadas ao desenvolvimento de software. Portanto, tudo nasceu relacionado ao caso particular do desenvolvimento de software. Assim sendo, o Ágil é um modelo de desenvolvimento de software que incentiva a iteração contínua de desenvolvimento e teste em todo o ciclo de vida do projeto de desenvolvimento de software.

Enquanto o sistema tradicional Waterfall se concentra no planejamento, onde fatores como escopo, custo e tempo tem grande importância, a abordagem Ágil focaliza o trabalho em equipe, a colaboração com o cliente e a flexibilidade. A equipe Ágil deve estar pronta e ser capaz de responder as mudanças solicitadas pelos clientes. Agora vem a parte mais desafiadora da abordagem Ágil: as empresas esperam que um projeto gerenciado com a abordagem Ágil seja feito com a qualidade esperada pelo cliente (satisfazendo o cliente e agregando valor para o mesmo), em menor tempo (trabalho mais rápido e com eficiência) e com menor custo. Portanto, está presente o foco no cliente, sem abrir mão do aumento da eficiência e da redução de custos, que, mesmo que não se diga claramente, continuam tendo grande importância do ponto de vista do resultado prático do projeto para a organização.

Ágil para o planejamento adaptativo

De forma geral, os projetos de alta incerteza têm altas taxas de mudança, complexidade e risco. Essas características podem apresentar problemas para abordagens preditivas tradicionais que visam determinar a maior parte dos requisitos antecipadamente e controlar as alterações por meio de um processo de solicitação de mudança.

A abordagem Ágil encontrou um modo de lidar com as mudanças através de um processo que divide o trabalho do projeto em  ciclos curtos. Explorando e avaliando esses ciclos curtos foi possível adaptar o projeto mais rapidamente as mudanças.

São exemplos de métodos ágeis de gerenciamento de projetos os seguintes: Scrum, XP (Extreme Programming), DSDM (Dynamic Systems Development Method), FDD (Feature Driven Development), Crystal e RUP (Rational Unified Process).

O gerenciamento de projetos na abordagem Ágil é iterativo e visa incorporar constantemente o feedback do usuário e, a cada rodada de um ciclo curto, são feitos lançamentos de produto (software) ou de partes do produto (software) que está sendo desenvolvido. Em outras palavras, cada saída de um ciclo curto é o resultado do trabalho da equipe que cria um produto para o cliente.

As diferenças entre o Waterfall e Ágil

A tabela a seguir resume algumas das diferenças entre o Scrum (método Ágil mais utilizado) e os modelos tradicionais de gerenciamento de projetos.

Lembrando que a tabela comparativa acima se aplica aos projetos de desenvolvimento de software. Em projetos de construção civil ou mesmo em projetos de desenvolvimento de um automóvel, não se utiliza a tecnologia orientada à objeto. Além disso, os desenvolvedores não são ilhas isoladas dentro de equipes, eles (e elas) precisam coorperar. Finalmente, uma construção (seja ela qual for) e um automóvel (seja ele de que tipo for) não são constituídos de partes de código escrito em alguma linguagem. Afinal, nem todo o problema é prego e, portanto, nem toda solução é martelo, embora existam aqueles que insistem em bater nessa tecla. Como dito por Abraham Maslow, “para quem só sabe usar martelo, todo problema é um prego”.

Este é um dos senões dos textos que enaltecem o Ágil, iniciando com uma descrição das abordagens de gestão mais tradicionais (para qualquer tipo de projeto), e na sua parte final apresentando uma tabela comparativa mais aderente a projetos de desenvolvimento de software, embora deixe a falsa impressão de estar fazendo uma comparação geral e válida para qualquer tipo de projeto.

É relevante lembrar que – como profissionais de gestão - não devemos nos comportar como seguidores cegos de uma seita ou de torcedores fanáticos de um clube de futebol, sendo necessário sempre manter o espírito crítico. O profissional de gerenciamento de projetos deve conhecer o máximo possível de técnicas e métodos de gestão para poder aplicar o que for melhor para a organização em que estiver trabalhando, e assim aumentar a probabilidade de sucesso do projeto. Bem, é isso aí, até a próxima.