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:
- A fração do planejamento é maior que o normal;
- A metade do cronograma dedicada ao processo de debug é bem maior que o normal;
- À 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?
- 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;
- 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;
- 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;
- 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.
Capitalismo Parasitário revoluciona a Gerência de Projetos - Esqueçam o PMI agora vamos de FANQ
ResponderExcluirhttp://reflexeseconmicas.blogspot.com/2011/04/capitalismo-parasitario-revoluciona.html
Capitalismo Parasitário revoluciona a Gerência de Projetos - Esqueçam o PMI agora vamos de FANQ
ResponderExcluirhttp://reflexeseconmicas.blogspot.com/2011/04/capitalismo-parasitario-revoluciona.html