Porque o planejamento tradicional não funciona?

Estimativa e planejamento são passos críticos para o sucesso de qualquer projeto de desenvolvimento de software. No entanto, planejar é uma atividade difícil e os planos geralmente falham. Estimativas feitas no início de um planejamento ou projeto tem pouquíssima exatidão e a probabilidade de termos uma estimativa correta para um planejamento de 1 ano é muito menor que a probabilidade de acertarmos a estimativa para um planejamento de 2 semanas. Esse refinamento na probabilidade do acerto das estimativas é chamado de cone da incerteza (Boehm, 1981).

No entanto, a dificuldade em planejar não é desculpa para não fazê-lo. O planejamento reduz o risco, diminui a incerteza, ajuda na tomada de decisões, estabelece uma maior confiança e dissemina informações. Infelizmente, o planejamento tradicional não vem funcionando. Ao tentar combinar e responder às necessidades do trio escopo\cronograma\recursos, o planejamento tradicional não nos leva a respostas e produtos satisfatórios.

E por que o planejamento tradicional não funciona? Mike Cohn, em seu livro Agile Estimating and Planning, elenca 5 causas para as falhas de planejamento.

1. O planejamento é baseado nas tarefas necessárias e não nos recursos desejados. É vital o time manter o foco nos requisitos solicitados; são eles que agregam valor para o cliente (veja “Você entrega algo de valor para seu cliente?”). Tarefas por si só não agregam valor algum. Além disso, os planejamentos tradicionais, por basearem-se em tarefas, preocupam-se com a dependência entre elas. Assim, atrasos em qualquer tarefa acumulam-se no final do cronograma, pois são repassados pela cadeia de dependência.

2. Executar tarefas simultaneamente agora acaba gerando atrasos no futuro. Com a melhor das intenções, o time pode ver a multitarefa como uma possível solução para atrasos. No entanto, ao trabalhar em duas tarefas ao mesmo tempo, um membro do time provavelmente prorrogará o término das duas. Como outras tarefas dependem das primeiras (lembra do item anterior?), é quase certo que um atraso será embutido na cadeia de dependência, refletindo-se no prazo de entrega final.

3. Não se atende aos requisitos pela prioridade dos mesmos. O pensamento tradicional diz que, se todo trabalho é completado, não importa a ordem em que é feito. Nesse caso, é natural que a seqüência e priorização das tarefas siga a conveniência do time de desenvolvimento e não a importância dos requisitos para o cliente. Como conseqüência, é muito provável que no final do projeto, para manter o cronograma, o time acabe descartando requisitos importantes que não foram corretamente priorizados.

4. O planejamento antecipado sempre contém um certo grau de incerteza que é ignorado. O planejamento tradicional não considera as incertezas presentes em todo projeto de software. Ele assume que a análise inicial será completa e perfeita e que coletará todos os requisitos do produto. Assume também que os usuários não mudarão de idéia, que nenhuma necessidade nova aparecerá durante a execução do projeto e que sabemos exatamente como os requisitos serão  implementados. É claro que isso não é verdade; tudo o que não sabemos no início do projeto é uma incerteza que deve ser considerada no planejamento, e a melhor forma de lidar com as incertezas é através de iterações curtas com feedbacks rápidos e constantes.

5. Estimativas com alto nível de incertezas e baixa probabilidade de acerto acabam se tornando compromissos. Dentro de cada estimativa está embutida uma probabilidade do trabalho ser finalizado no tempo previsto. Uma probabilidade varia de 0 a 100%. Portanto, ao estimar a duração de uma tarefa estamos dizendo que existe uma probabilidade de x % de terminarmos a tarefa em y dias. O problema é que compromissos não podem ser assumidos sobre probabilidades; eles são assumidos sobre uma data.

O planejamento ágil ataca esses problemas focando nos requisitos. A unidade mínima de entrega é um requisito completo; não importa quantas tarefas foram terminadas, se um requisito não está completamente implementado, ele não está entregue. A priorização baseia-se nos requisitos de maior valor para o cliente e não nas tarefas do time de desenvolvimento. O time todo trabalha para entregar um requisito, por isso praticamente não existe multitarefa. O planejamento é incremental; assume-se que no início do projeto sabemos muito pouco sobre o que será feito e sobre como será feito. O time encontrará essas respostas gradativamente, conforme implementa requisito por requisito.

Parece utópico, mas funciona. Qualquer um que desenvolveu software sabe que nunca conseguimos levantar todos os requisitos necessários para um sistema, por maior que seja o esforço. Conheço uma pessoa que trabalha para uma grande empresa indiana que possui a famosa certificação CMM5. Há 2 anos ela realiza levantamento de requisitos para o sistema de um grande banco brasileiro. Dois longos anos de trabalho da equipe; nenhuma linha de código foi escrita, nenhum requisito foi entregue; somente algumas centenas de artefatos obrigatoriamente gerados pela especificação do CMM5. Claro, CMM5 garante qualidade, mesmo que a um custo altíssimo, certo? Mas qual a probabilidade dos requisitos levantados há dois anos ainda serem válidos? Será que ainda representam o que o cliente quer atualmente? Acho pouco provável.

E você, qual sua opinião?

Artigos mais comentados