• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Por que os planos falham?
 

Por que os planos falham?

on

  • 1,215 views

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.

Statistics

Views

Total Views
1,215
Views on SlideShare
1,214
Embed Views
1

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Por que os planos falham? Por que os planos falham? Presentation Transcript

    • Por que os planosfalham?
      Guilherme BalenaVersiani
      ComunIP S/A
    • 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
    • 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.
    • 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.
    • Atrasos sempre se propagam
      • Para antecipar os testes, é necessário que todas as seguintes condições sejam satisfeitas:
      • 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.
      • 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%.
    • Multitarefa causa queda de produtividade
    • Multitarefa causa atraso
      10
      10
      10
      20
      20
      20
    • As features não são desenvolvidas com base em suas prioridades
    • 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.
    • 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.