Prazo e Escopo: O Mito - III

Chegamos ao último artigo dessa série, sobre o capítulo dois, do livro atemporal de Frederick P. Brooks. Neste artigo trataremos as questões de Teste de Sistema, Estimativa Covarde e o Desastre do Cronograma Regenerativo. Devido a característica contínua dos tópicos, esse artigo sairá do modelo enxuto que venho adotando nos últimos meses. Então, paciência.


Teste de Sistema
Neste tópico Brooks afirma, baseado em sua experiência, que esta é a tarefa mais afetada quando erramos na definição do cronograma do projeto. Devido ao nosso otimismo, sempre acreditamos que a quantidade de bugs será pequena - ou zero. Entretanto, a realidade se mostra diferente.

Em alguns anos de experiência, Brooks cunhou uma forma de dividir o tempo de suas tarefas, durante o processo de desenvolvimento. Segundo ele informa, esta divisão foi um sucesso. Segue:

1/3 Planejamento;
1/6 Codificação;
1/4 Teste de componentes e testes de sistema inicial;
1/4 Teste de sistema.

Este cronograma difere, do que era adotado na época, em três pontos:

1. A fração do planejamento é maior que o normal;
2. A metade do cronograma dedicada ao processo de debug é bem maior que o normal;
3. À fração mais fácil de estimar, a codificação, é dado um sexto do cronograma.

Poucos analistas atribuem metade do cronograma para os testes mas, de fato, usam este tempo para este propósito. Muitos analistas estão cumprindo o cronograma, até chegar neste ponto.

A falha na definição de tempo suficiente para os testes é desastrosa, pois ninguém sabe que está fora do cronograma, até chegar próximo a data de entrega. Estar atrasado e sem avisos, é algo perturbador para clientes e gestores.

Além do mais, atrasos nesse ponto resulta em grandes problemas financeiros e motivacionais. O projeto está com o seu time completo e o custo-por-dia está no máximo. Normalmente, o software é para suportar outros setores da empresa e os custos secundários do atraso são muito altos, pois estamos próximos da data de entrega da aplicação.

Dessa forma, é de grande importância que dediquemos tempo suficiente do cronograma para os testes de sistemas.

Tenho lido esse livro consultando Extreme Programming Explained: Embrace Change, que possui a primeira edição datada de 2000, portanto, um ano anterior ao manifesto ágil e cinco anos posterior à última edição do livro de Brooks. Meu objetivo é encontrar soluções modernas para os problemas apontados por Brooks. Dentre as várias práticas da XP, existe uma que trata dos testes:

Os desenvolvedores escrevem testes de unidade continuamente, os quais devem executar sem falhas, para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as funções estão terminadas.

Dessa forma, temos boa parte do cronograma, no processo da XP, destinado aos testes.

Também temos o TDD (Beck 2003; Astels 2003) que, por hora, ficaremos apenas com uma boa definição:

is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.

Estimativa Covarde

O problema da estimativa covarde nasce com a urgência imposta para a conclusão do sistema. Vamos a mais uma citação de Brooks:

The urgency of patron may govern the schedule completion of the task, but it cannot govern the actual completion.

A mensagem é simples: engenharia de software não suporta milagres. O desespero em ver o software pronto pode encurtar o cronograma, entretanto, não fará com que o software esteja, de fato, pronto naquele prazo. Isto é, o cronograma irá apontar para uma situação falsa, complicada (e as vezes impossível) de atingir.

Vamos concluir este tópico com mais uma citação de Brooks:

Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.

O Desastre do Cronograma Regenerativo
O que fazer quando um projeto está fora do cronograma? Adicionar pessoas, naturalmente. Essa solução pode ajudar... ou não, como mostraremos a seguir.

Vamos utilizar, obviamente, o exemplo de Brooks no livro. Suponhamos que uma tarefa esteja estimada em doze homem-mês e atribuída a três pessoas por quatro meses, e existem marcos de medição A, B, C, D, que estão posicionados no fim de cada mês.

Agora, vamos supor que o primeiro marco não tenha sido atingido antes do segundo mês. Quais as alternativas do gerente de projetos?

1. Assumir que a tarefa deverá ser completada a tempo. Assumir que apenas a primeira parte da tarefa foi mal estimada. Então, faltam nove homem-mês de esforço e dois meses, então 4 1/2 pessoas serão necessárias, adicione duas às três pessoas já existentes;
2. Assumir que a tarefa deverá ser completada a tempo. Assumir que toda estimativa foi abaixo da realidade. Assim, faltam dezoito homem-mês de esforço e dois meses, então serão necessárias nove pessoas. Adicione seis pessoas às três já existentes;
3. Refazer o cronograma. Brooks cita uma advertência de P. Fagg, um eng. de hardware experiente, "Take no small slips". Isto é, aloque tempo suficiente no novo cronograma, para ter certeza que o trabalho pode ser completado cuidadosa e minuciosamente, assim não será necessário refazer o cronograma outra vez;
4. Reduza a tarefa. Na prática, isso tende a acontecer de qualquer forma, uma vez que a equipe descubra o escorregão no cronograma. Onde o custo secundário do atraso é muito alto, esta é a única ação viável. A redução da tarefa pode se dar por um design apressado e testes incompletos.

Nos dois primeiros casos, insistir que a tarefa, inalterada, seja completada em quatro meses é desastroso. Vamos considerar os efeitos regenerativos, por exemplo, da primeira alternativa. As duas pessoas, embora competentes e rapidamente recrutadas, necessitará de treinamento na tarefa, dado por uma das pessoas experientes alocadas desde o início. Se este treinamento necessitar de um mês, três homem-mês necessitarão atuar em algo que não é a tarefa original. Além disso, a tarefa, outrora dividida entre três pessoas, deverá ser dividida novamente entre cinco. Assim, ao final do terceiro mês, faltam sete homem-mês de esforço, e teremos cinco pessoas treinadas e um mês disponível. O projeto está tão atrasado quanto se não houvesse acrescentado ninguém.

Observe que no final do terceiro mês, a situação não é boa, independente de "todo o esforço" gerencial (as aspas foram por minha conta). A tentação de repetir o ciclo é grande, adicionando ainda mais pessoas. É aí que reside a loucura.

Na segunda opção, é assumido que todo o cronograma foi otimista, supondo-se necessário adicionar seis pessoas à tarefa original. Como Brooks, vou deixar o cálculo do efeito sobre o treinamento, redivisão e testes para o leitor. É simples e leva apenas alguns minutos.

Sem dúvida, o desastre regenerativo renderá um produto de baixa qualidade e pior, atrasado.

Dessa forma, Brooks estabeleceu sua lei:

Adding manpower to a late software project makes it later.

Então, isto desmistifica a questão do homem-mês. O número de meses de um projeto depende de suas restrições sequenciais. O número máximo de pessoas depende da quantidade de subtarefas independentes. A partir destas duas quantidades, é possível derivar o cronograma usando menos pessoas e mais meses (o único risco é o produto ficar obsoleto). Não podemos, entretanto, ter um cronograma viável usando mais pessoas e menos meses. Projetos de software falharam mais por falta de tempo que por todas as outras causas combinadas. Segue a frase de Brooks:

More software projects have gone awry for lack of calendar time than for all other causes combined.

Alguma dúvida que este livro ainda é timeless? Não era timeless apenas em 1995 (vinte anos após a primeira edição), quando Brooks revisou e lançou outra edição (incluindo seu artigo de 1986 - "No Silver Bullet") mas, incrivelmente, ainda é em 2010, onde metodologias modernas engatinham para resolver os problemas apontados no livro.