A metodologia Ágil é mais eficiente do que a Cascata?

Um dos Scrum Masters que frequentemente acompanhamos nos liga regularmente por causa de problemas com os quais está lidando. Ele brincou que deveríamos atender o telefone dizendo "Hotline Agile, como podemos ajudar?". Achamos que era uma ótima ideia e por isso estamos começando uma série de posts de blog chamada Hotline Agile. Aqui você encontra nossas respostas às perguntas que recebemos sobre Agile ou Scrum. Esperamos que você também possa aprender algo com isso.

Recentemente me pediram um conselho sobre uma discussão que alguém teve com um colega. Era sobre se Agile e Scrum podem funcionar em qualquer cenário onde software é desenvolvido. O colega afirmou que não.

O Cenário

Vamos supor que um produto de software precisa ser construído que permita aos usuários fazer avaliações enquanto leem um e-book. Deve haver pelo menos dois tipos diferentes dessas avaliações.

Com Agile ou Scrum, tentaríamos entregar um produto funcional e valioso o mais cedo possível – então o objetivo é entregar apenas uma das opções de avaliação, que já pode ser usada pelos usuários desde cedo. Isso seria a v1.0. Alguns Sprints depois, tentaríamos implementar a segunda opção de avaliação como v2.0.

No modelo Cascata, levaríamos o tempo necessário para entregar ambas as avaliações na primeira versão.

O colega argumentou neste caso que Cascata faria mais sentido, porque senão o risco seria muito alto de ter que refatorar todo o código para suportar a segunda opção de avaliação v2.0. Com Cascata, ambos os tipos de avaliação seriam desenvolvidos juntos. Embora levasse mais tempo para entregar a primeira versão funcional, haveria menos retrabalho.

Ele acredita que o método Cascata economiza tempo e é mais eficiente, porque há menos refatoração quando se começa a desenvolver com requisitos atuais e futuros ao mesmo tempo. Com Agile, nosso foco está no "agora" e em apenas um único tipo de avaliação.

O que você acha? Como você lidaria com um grupo de desenvolvedores que pensam que com Agile terão que refazer muito depois, porque "não podiam planejar muito à frente"?

O que acreditamos

Existem três pontos principais que precisam ser compreendidos para responder a esta pergunta:

• Primeiro: Agile e Cascata têm cada um sua área de aplicação. Agile é voltado para sistemas complicados/complexos, por exemplo, quando existe um certo grau de incerteza nos requisitos e/ou na tecnologia. Cascata é mais adequado para projetos simples, por exemplo, quando há um bom entendimento dos requisitos e da tecnologia e essas coisas não mudam. Usamos a Matriz de Stacey para esclarecer quando usar qual abordagem. A questão é que Cascata falha completamente em um ambiente complexo, enquanto Agile em um ambiente simples envolve mais esforço, mas ainda assim funciona. Nosso exemplo favorito é a organização de uma conferência. Você pode usar Agile, mesmo que pareça esforço desnecessário.

• Segundo: Agile NÃO é mais eficiente que Cascata. É mais eficaz. Isso significa que talvez você precise de mais horas-pessoa para entregar algo com Agile, mas o produto provavelmente pode ser lançado no mercado mais cedo (porque deve haver um release no final de cada Sprint e não apenas no final do projeto). Além disso, o custo total de propriedade provavelmente é menor (porque qualidade e design são melhores e o conhecimento é compartilhado, tornando a manutenção mais fácil).

• Terceiro: Agile não se trata de desenvolver algo específico mais rápido. Trata-se da arte de maximizar a quantidade de trabalho não realizado. O estudo do Chaos afirma que 65 % de um software nunca ou raramente é usado. Com Agile, tentamos identificar e desenvolver os outros 35 % que têm maior probabilidade de serem usados; depois paramos. Então, mesmo que demore um pouco mais para desenvolver os primeiros 35 %, economizamos o desenvolvimento dos outros 65 % que ninguém vai usar.

Como isso funciona com o nosso exemplo? Bem, primeiro de tudo, não se completaria toda a primeira avaliação para depois fazer a segunda. Seria identificada a parte mais valiosa da avaliação. Isso pode ser um determinado tipo de pergunta (por exemplo, uma pergunta de múltipla escolha). Então, seria incluída apenas uma pergunta na avaliação, deixando os usuários testarem e descobrindo se funciona. Poderia até ser entregue a primeira opção de avaliação apenas com perguntas de múltipla escolha. Depois, seria incluído o próximo tipo de pergunta mais importante. Ou se decide que está bom o suficiente e começa-se um novo projeto.
Se o escopo das avaliações estiver realmente definido, além disso se souber que realmente funciona para os usuários, e não houver incerteza em relação à tecnologia, Waterfall pode ser a melhor escolha para este projeto. Agile também funcionaria, só não necessariamente economizaria tempo. Pela minha experiência, posso dizer que a maioria das pessoas pensa conhecer e ter entendido todos os requisitos – mas isso normalmente não é verdade. O esforço adicional com Agile geralmente vale a pena.

Este texto foi originalmente publicado no Blog da Growing Agile e foi traduzido por nós para o alemão.