• Like
  • Save
Por que os planos falham?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Por que os planos falham?

  • 756 views
Published

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

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

Published in Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
756
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Por que os planosfalham?
    Guilherme BalenaVersiani
    ComunIP S/A
  • 2. 2/3 dos projetos excedem significantemente suas estimativas de custo
    65% das features incluídas nos softwares são usadas raramente ou nunca são usadas
    Em média, os projetos excedem os cronogramas em 100%
    LedererandPrasad, 1992
    Johnson, 2002
    Standish, 2001
  • 3. Planeja-se Atividades no lugar de Features
    Atividades não dizem muita coisa aos clientes.
    Ao revisar um plano, procura-se por atividades esquecidas no lugar de features que estariam faltando.
  • 4. As atividades nunca terminam antes
    “O trabalho se expande de forma a ocupar todo o tempo disponível para ser completado.”Lei de Parkinson (1993)
    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.
    É da natureza do ser humano preencher qualquer tempo extra com outro trabalho que nós (mas talvez não outros) valorizamos.
  • 5. Atrasos sempre se propagam
    • 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.
  • Atividades não são independentes
    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%.
  • 13. Multitarefa causa queda de produtividade
  • 14. Multitarefa causa atraso
    10
    10
    10
    20
    20
    20
  • 15. As features não são desenvolvidas com base em suas prioridades
  • 16. Incertezas são ignoradas
    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.
    Ignoramos que desconhecemos todas as atividades necessárias no decurso do projeto. São feitas estimativas precisas (“duas semanas”) para um trabalho incerto.
  • 17. Estimativas se tornam compromissos
    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.