Um dos motivos das empresas migraram para métodos ágeis é para se tornarem aptas a gerenciar mudanças. As necessidades de clientes geralmente mudam ao longo do caminho, o que exige da equipe de desenvolvimento adaptabilidade para gerenciar o produto. Métodos ágeis ajudam as equipes a entregar produtos que satisfaçam as necessidades dos clientes; produtos que não contenham funcionalidades desnecessárias (e que não serão utilizadas). O processo de desenvolvimento de software enxuto utiliza o termo desperdício: tudo que não cria valor para o cliente é considerado desperdício. Como a transição do método cascata para um processo de desenvolvimento ágil ajuda as empresas a reduzir o desperdício?
Ron Lichty escreveu um post sobre as mais convincentes razões para as empresas mudarem do método cascata para um método ágil. O principal motivo, segundo Ron Lichty, é o desperdício:
Mas o que realmente me conquistou − o que me converteu a um entusiasta de métodos ágeis e totalmente desencantando do método cascata − é o desperdício. Desperdício de recursos, de tempo de desenvolvimento e de esforço.
Lichty descreve como questiona os desenvolvedores e seus gerentes de qual o percentual de uma especificação de requisitos de 400 páginas que eles trabalharam e que realmente foi entregue. A resposta que ele recebe é a seguinte:
(...) a resposta raramente excede 45% − geralmente está entre 15 e 25% − chegando até mesmo a 10% dos requisitos funcionais entregues.
Lichty fala sobre a maior diferença entre os métodos ágeis e cascata é como as decisões são tomadas do que será entregue, o que possui impacto no valor do que é entregue:
Um das coisas que eu adoro nos métodos ágeis é que o topo do backlog é ordenado a cada sprint pelos donos do produto colaborando com os líderes de desenvolvimento para garantir que as equipes sempre trabalhem nos itens de maior valor.
A resposta em um cenário utilizando o método cascata, por outro lado, quase nunca é valor. As respostas que recebo incluem, "a coisa mais simples para codificar", "o que era mais interessante para nós" (o que era mais brilhante!), "o se destacou na nossa cabeça da leitura dos requisitos" ou "o que era mais legal". Priorização em uma especificação de 400 páginas é quase que universalmente feita por desenvolvedores e não por donos de produtos.
No site a mentalidade enxuta, Mary e Tom Poppendieck descrevem os princípios do desenvolvimento de software enxuto. Um dos princípios é "eliminar o desperdício":
Os três maiores desperdícios no desenvolvimento de software são:
Construindo a coisa errada
"Não existe nada tão inútil quanto fazer eficientemente aquilo que não deve ser feito." − Peter Drucker
Construindo a coisa de maneira errada
Parece que não há tempo suficiente para construir a coisa da maneira correta, então certamente não existe tempo para NÃO construí-la da maneira certa.
Uma mentalidade de pacotes e filas
Trabalho com progresso esconde defeito, se torna obsoleto, causa alternância entre tarefas e atrasa a realização de valor.
Mike Cudemo escreveu um post sobre agilidade vs cascata - qual o grande negócio? Ele começa explicando a diferença de como os métodos cascata e ágil controlam requisitos:
O processo cascata tenta "congelar os requisitos" depois que os diagramas são desenhados. Como é possível imaginar esta não é a realidade. Quanto mais tarde um problema no levantamento de requisitos for detectado (...), mais caro custa a correção. Em alguns casos chega a ser impossível de corrigir. (...) O método ágil não tenta "pregar e congelar os requisitos" tudo de uma única vez. Ele assume que os requisitos vão evoluir e mudar assim que o cliente começar a visualizar os próprios requisitos.
Mike Cudemo fornece a sua visão de como as iterações no desenvolvimento de software ágil oferecem possibilidades de guiar os resultados:
O método ágil tenta focar no levantamento de requisitos, desenho, codificação e testes de maneira iterativa e em pequenas fases de desenvolvimento. Essencialmente, o método ágil é uma série de pequenos métodos em cascata. Usuários finais e pessoas de negócio conseguem visualizar e experimentar o sistema durante seu desenvolvimento. Correções durante o desenvolvimento se tornam mais aparentes e fáceis de serem trabalhadas.
Projetos cascata estão gastando o orçamento de TI, como Mike conclui:
Diversos CFOs se encontram em um complexo ato de julgamento de corte de custos operacionais e investimentos em tecnologia. Os CFOs estão forçando os CIOs a apresentarem planos para alavancar os investimento existentes, mas também desenvolver a capacidade de rapidamente responder ao crescimento econômico e mudanças competitivas. Falhas em projetos não e uma opção, mas de acordo com as estatísticas, iniciativas em cascata gastam 60% do orçamento de TI das empresas.
No artigo agilidade é mais barato certo? Kenny Grant descreve como a iniciativa ágil pode ajudar as equipes a identificarem o desperdício e lidar com isso. O desenvolvimento de software ágil por si só não é mais barato que o desenvolvimento de software em cascata, como Kenny Grant explica. O que faz o método ágil mais barato é a maneira com que ele lida com mudanças de escopo e ajustes no projeto:
Comparar o método cascata com o método ágil é como comparar maças com laranjas. Isso porque seguir os princípios e processos ágeis iriam, em minha opinião, quase sempre gerar um produto diferente do que se a mesma necessidade de negócio fosse abordada com um projeto utilizando a metodologia em cascata. (...) quase sempre existem algumas partes do escopo e que podem ser considerados desperdício ou seu valor não vale o custo da entrega. O método ágil foca implacavelmente no valor de negócio e a ideia de somente o trabalho necessário identifica o desperdício − ou requisitos com pequeno retorno sobre o investimento (ROI) − e dá a equipe a oportunidade de mudar ou deixar o percurso.
Levando em consideração que as necessidades de negócio e requisitos vão mudar durante o projeto, Kenny Grant reforça a pergunta "Agilidade é mais barato?":
"Para uma necessidade de negócio específica, seguir os princípios e processos ágeis permite desenvolver produtos que atendem as necessidades de negócio (nada mais, nada menos) de maneira mais barata do que seguindo a metodologia cascata?" Nesse caso a resposta é "Sim, absolutamente".