Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Por que os planos falham?

1,039 views

Published on

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

Published in: Business
  • Be the first to comment

  • Be the first to like this

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 />

×