1.
Por que os planosfalham?<br />Guilherme BalenaVersiani<br />ComunIP S/A<br />

2.
2/3 dos projetos excedem significantemente suas estimativas de custo<br />65% das features incluídas nos softwares são usadas raramente ou nunca são usadas<br />Em média, os projetos excedem os cronogramas em 100%<br />LedererandPrasad, 1992<br />Johnson, 2002<br />Standish, 2001<br />

3.
Planeja-se Atividades no lugar de Features<br />Atividades não dizem muita coisa aos clientes.<br />Ao revisar um plano, procura-se por atividades esquecidas no lugar de features que estariam faltando.<br />

4.
As atividades nunca terminam antes<br />“O trabalho se expande de forma a ocupar todo o tempo disponível para ser completado.”Lei de Parkinson (1993)<br />Quando um gráfico de Gantt mostra que uma atividade vai levar 5 dias, isso dá permissão implícita ao desenvolvedor para levar justamente este tempo para completá-la.<br />É da natureza do ser humano preencher qualquer tempo extra com outro trabalho que nós (mas talvez não outros) valorizamos.<br />

5.
Atrasos sempre se propagam<br /><ul><li>Para antecipar os testes, é necessário que todas as seguintes condições sejam satisfeitas:

6.
A inclusão de tabelas no banco de dados termine antes.

7.
A codificação da interface de usuário termine antes.

8.
Otester esteja disponível antes.

9.
Por outro lado, se qualquer um dos seguintes eventos ocorrem, haverá um atraso:

10.
A codificação da interface de usuário atrasa.

11.
A adição de tabelas no banco de dados atrasa.

12.
O tester não está disponível.</li></li></ul><li>Atividades não são independentes<br />Se o desenvolvimento de uma parte da aplicação levar 50% de tempo a mais, existe uma grande chance do desenvolvimento de outras partes similares também atrasar 50%.<br />

13.
Multitarefa causa queda de produtividade<br />

14.
Multitarefa causa atraso<br />10<br />10<br />10<br />20<br />20<br />20<br />

15.
As features não são desenvolvidas com base em suas prioridades<br />

16.
Incertezas são ignoradas<br />Assume-se que a análise inicial de requisitos fornece uma perfeita especificação do produto; os usuários não vão mudar de idéia, refinar suas opiniões, nem irão surgir com novas necessidades até o final do plano.<br />Ignoramos que desconhecemos todas as atividades necessárias no decurso do projeto. São feitas estimativas precisas (“duas semanas”) para um trabalho incerto.<br />

17.
Estimativas se tornam compromissos<br />Segundo Phillip Armour (2002), uma estimativa é uma probabilidade, e compromissos não podem ser feitos baseados nessas probabilidades. Compromissos devem ser feitos por datas. A equipe deve receber uma chance de avaliar os fatores do negócio e os riscos antes de aceitar um compromisso.<br />