Por que os planosfalham?<br />Guilherme BalenaVersiani<br />ComunIP S/A<br />
2/3 dos projetos excedem significantemente suas estimativas de custo<br />65% das features incluídas nos softwares são usa...
Planeja-se Atividades no lugar de Features<br />Atividades não dizem muita coisa aos clientes.<br />Ao revisar um plano, p...
As atividades nunca terminam antes<br />“O trabalho se expande de forma a ocupar todo o tempo disponível para ser completa...
Atrasos sempre se propagam<br /><ul><li>Para antecipar os testes, é necessário que todas as seguintes condições sejam sati...
A inclusão de tabelas no banco de dados termine antes.
A codificação da interface de usuário termine antes.
Otester esteja disponível antes.
Por outro lado, se qualquer um dos seguintes eventos ocorrem, haverá um atraso:
A codificação da interface de usuário atrasa.
A adição de tabelas no banco de dados atrasa.
Upcoming SlideShare
Loading in...5
×

Por que os planos falham?

804

Published on

Por que os planos falham? São apresentadas as razões mais comuns em desenvolvimento de software.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
804
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Por que os planos falham?

  1. 1. Por que os planosfalham?<br />Guilherme BalenaVersiani<br />ComunIP S/A<br />
  2. 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. 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. 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. 5. Atrasos sempre se propagam<br /><ul><li>Para antecipar os testes, é necessário que todas as seguintes condições sejam satisfeitas:
  6. 6. A inclusão de tabelas no banco de dados termine antes.
  7. 7. A codificação da interface de usuário termine antes.
  8. 8. Otester esteja disponível antes.
  9. 9. Por outro lado, se qualquer um dos seguintes eventos ocorrem, haverá um atraso:
  10. 10. A codificação da interface de usuário atrasa.
  11. 11. A adição de tabelas no banco de dados atrasa.
  12. 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. 13. Multitarefa causa queda de produtividade<br />
  14. 14. Multitarefa causa atraso<br />10<br />10<br />10<br />20<br />20<br />20<br />
  15. 15. As features não são desenvolvidas com base em suas prioridades<br />
  16. 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. 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 />

×