---

Precisou planejar o projeto inteiro antes de compreendê-lo? A resposta pode surpreender você!

Sem Scrum, nossas equipes haviam desenvolvido e entregue produtos de software e hardware completamente errados, que não atendiam às exigências dos clientes.

Houve momentos em nossa vida profissional em que empresas terceirizadas impunham como deveríamos desenvolver nossos produtos ou serviços de software.

Capability Maturity Model (CMM), ISO 9001:2008 e outros modelos derivados tentavam ajudar nossas empresas a desenvolver o software correto da maneira correta.

O sucesso que alcançavam não é o assunto deste livro. Seu foco é o processo Scrum e os méritos do framework Scrum, em vez de criticar procedimentos quase extintos.

Porém, preciso acrescentar que esses modelos de melhoria de processos anteriores ao framework Scrum de engenharia de software recomendavam uma abordagem por fases. Indicavam uma abordagem de engenharia de software em etapas, que chamávamos de Modelo Cascata de engenharia de software.

No Modelo Cascata, cada projeto de software deveria começar pela análise de requisitos, na qual buscávamos compreender o que o cliente precisava e desejava.

Depois, projetávamos esses requisitos, implementávamos, testávamos (verificávamos) e fazíamos sua manutenção nos ambientes de produção. Por fim, chegávamos ao final do ciclo de vida da engenharia de software.

Mas a realidade não acontecia assim!

Metodologia Cascata versus framework Scrum

Fases do modelo clássico de desenvolvimento de software em cascata

Os efeitos negativos de atrasos imprevistos numa fase do Modelo Cascata de engenharia de software inevitavelmente atingiam as fases seguintes.

Estudos mostraram que, em mais de 80% dos projetos de software investigados que fracassaram, o uso da Metodologia Cascata foi um dos fatores críticos do fracasso. Mas por quê?

Como mostra o lado esquerdo, a Metodologia Cascata utiliza uma sequência rígida de fases. Uma fase precisa terminar antes de a seguinte começar. Voltar atrás é, na maioria dos casos, difícil, caro, frustrante para a equipe e demorado.

O cronograma é planejado no início do projeto. Um produto em condições de lançamento só é entregue no final desse cronograma. Se uma fase atrasa, todas as seguintes também atrasam.

Para evitar isso, gerentes de projetos que usam a Metodologia Cascata costumam tentar prever todas as possibilidades antecipadamente. Assim, já nas fases iniciais, procuram definir todos os requisitos com o maior detalhamento e completude possíveis. Porém, definir requisitos no início de um projeto costuma ser complicado, e muitos deles mudam, ou deveriam mudar, ao longo do projeto.

Estudos mostraram que, em projetos maiores e mais complexos, cerca de 60% dos requisitos iniciais mudam durante sua execução. Outros são implementados conforme definidos, mas alguns não são realmente necessários ao cliente. Essas implementações consomem tempo e dinheiro que poderiam ser mais bem empregados em funcionalidades com maior valor agregado para os clientes.

A divisão em fases obriga os gerentes a estimar cada fase separadamente. O problema é que, em geral, elas não são separadas: trabalham juntas e em paralelo.

Por exemplo, nenhuma pessoa sensata pode supor que o desenvolvimento termine antes de os testes começarem. No entanto, era exatamente assim que, infelizmente, a Metodologia Cascata funcionava.

A Metodologia Cascata pode ser utilizada no desenvolvimento de projetos de software pequenos e simples. Mas, para projetos maiores e mais complexos, essa abordagem é altamente arriscada, se não insensata. Costuma ser mais cara e é sempre menos eficiente que o framework Scrum de desenvolvimento e entrega de software.

Assim era a vida antes do framework Scrum. Enviar nosso software de uma equipe para outra, sem a orientação de profissionais com competências em Scrum, tornava nosso trabalho burocrático, complexo e improdutivo.

Por fim, não era apenas o produto que sofria: o moral dos funcionários e seu compromisso com a missão da organização também eram profundamente abalados.