Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Por que projetos tradicionais não funcionam

Por que projetos tradicionais não funcionam

Palestra que apresentei em 2012 dentro do SERPRO - Serviço Federal de Processamento de Dados

Rafael Miranda

June 01, 2012
Tweet

More Decks by Rafael Miranda

Other Decks in Business

Transcript

  1. Por que projetos tradicionais não funcionam Rafael Miranda @rafaelmbr tão

    bem quanto os ágeis! terça-feira, 16 de abril de 13
  2. “Utiliza um processo preditivo, e é estruturado em passos sequenciais

    e bem definidos de produção” http://bit.ly/KN9G5V - http://bit.ly/KjD7Qi Projeto tradicional: terça-feira, 16 de abril de 13
  3. Cascata, cascata com sobreposição e, infelizmente, RUP como é usado

    no dia-a-dia pela maioria dos projetos terça-feira, 16 de abril de 13
  4. Fazer iterações de requisitos, depois de projeto, depois de implementação,

    etc não é iterativo terça-feira, 16 de abril de 13
  5. “Utiliza um processo preditivo, e é estruturado em passos sequenciais

    e bem definidos de produção” http://bit.ly/KN9G5V - http://bit.ly/KjD7Qi Orientado a um plano terça-feira, 16 de abril de 13
  6. Planos são importantes. Guiam inúmeras decisões importantes para o início,

    desenvolvimento e conclusão de projetos e lançamento de produtos. Estimativas de custo e prazo são fundamentais para a tomada de decisões. terça-feira, 16 de abril de 13
  7. Porém, planejar e estimar é extremamente difícil. Por mais que

    fiquemos bons nisto, continua sendo difícil terça-feira, 16 de abril de 13
  8. Existem muitas incertezas num projeto de software: entendimento dos requisitos,

    prioridades, pessoas, conhecimento técnico... terça-feira, 16 de abril de 13
  9. “66% dos projetos ultrapassam significativamente os custos estimados” [1] “Somente

    37% dos projetos entre 2002 e 2010 tiveram sucesso” [4] “33% dos clientes estão altamente desapontados com os prazos e qualidade” [5] “50% dos projetos é concluído no dobro do prazo estimado” [2] “64% das funcionalidades implementadas nunca ou raramente são usadas” [3] terça-feira, 16 de abril de 13
  10. The CHAOS Manifesto - 2011 Projetos tradicionais de 2002 a

    2010 Sucesso 14% Contestado 57% Fracasso 29% Estatisticamente, se você está num projeto tradicional, suas chances de sucesso são incrivelmente baixas terça-feira, 16 de abril de 13
  11. Ferramentas, tecnologias, linguagens, frameworks: novos problemas sempre surgirão. O time

    pode não dominar algo (é possível dominar?) ou a tecnologia aplicada às regras de negócio do sistema, podem gerar situações desconhecidas terça-feira, 16 de abril de 13
  12. Pessoas vistas como recursos, que se comportam de maneira previsível,

    com habilidades/competências conhecidas: Não somos robôs! terça-feira, 16 de abril de 13
  13. Na manufatura, você investe muito tempo no projeto, no planejamento.

    Porém, este investimento se paga pois o plano é reutilizado milhares de vezes para cada produto idêntico que é fabricado terça-feira, 16 de abril de 13
  14. Na construção civil, temos elementos estáveis, conhecidos: - Leis de

    Newton - Materiais conhecidos - Peças padronizadas - Padrões de construção terça-feira, 16 de abril de 13
  15. No desenvolvimento de software este nível de estabilidade não existe!

    (pelo menos para a grande maioria dos projetos) terça-feira, 16 de abril de 13
  16. The Stacey Graph Plotando para a maioria dos projetos de

    desenvolvimento de software terça-feira, 16 de abril de 13
  17. “Problema ou contexto Complexo é aquele em que a quantidade

    de coisas que não sabemos é maior do que a quantidade de coisas que sabemos” http://amzn.to/IBrWQI terça-feira, 16 de abril de 13
  18. 14% Apenas 14% de sucesso não seria aceitável numa indústria

    de carros, mas é na de software? Isto demonstra um mercado doente... terça-feira, 16 de abril de 13
  19. Valor para o Cliente ? Cumprimento de atividades é medida

    de progresso. Que valor uma atividade como “Camada de negócio criada” tem para o cliente? terça-feira, 16 de abril de 13
  20. O cliente está pagando por software e não por cumprimento

    de atividades terça-feira, 16 de abril de 13
  21. C. Northcote Parkinson (1909 - 1993) Parkinson's Law: The Pursuit

    of Progress (1957) terça-feira, 16 de abril de 13
  22. Dificilmente uma atividade terminará antes do tempo estimado A duração

    estabelecida num cronograma gera um sentimento implícito de permissão de usar o tempo estimado terça-feira, 16 de abril de 13
  23. Atraso é repassado Como existe uma rede interconectada da atividades,

    o atraso de uma, reflete em todas terça-feira, 16 de abril de 13
  24. Criar modelo de dados Implementar camada de negócio Realizar testes

    Implementar camada de apresentação Exemplo prático terça-feira, 16 de abril de 13
  25. Para testar no prazo Criar modelo de dados Implementar camada

    de negócio Realizar testes Implementar camada de apresentação E E E TODAS as condições precisam ser satisfeitas para testarmos dentro do prazo terça-feira, 16 de abril de 13
  26. Para testar atrasado Criar modelo de dados Implementar camada de

    negócio Realizar testes Implementar camada de apresentação OU OU OU As chances de atrasar são muito maiores! Somando com a lei de parkinson... terça-feira, 16 de abril de 13
  27. Implementar camada de apresentação A Implementar camada de apresentação B

    Implementar camada de apresentação C Implementar camada de apresentação D Atividades semelhantes Outro exemplo, todas com estimativas semelhantes, pois são atividades semelhantes terça-feira, 16 de abril de 13
  28. Implementar camada de apresentação A Implementar camada de apresentação B

    Implementar camada de apresentação C Implementar camada de apresentação D Atividades semelhantes ! Quando não cumprimos o estimado, normalmente falamos: “Vamos compensar o atraso com o aprendizado que tivemos na primeira atividade” terça-feira, 16 de abril de 13
  29. Ou seja: vc aceita o desafio, pois uma incerteza se

    mostrou para vc terça-feira, 16 de abril de 13
  30. Implementar camada de apresentação A Implementar camada de apresentação B

    Implementar camada de apresentação C Implementar camada de apresentação D ! Atividades semelhantes A única coisa que podemos afirmar quando uma atividade atrasa, é que atividades semelhantes provavelmente também atrasarão! terça-feira, 16 de abril de 13
  31. 0% 23% 45% 68% 90% 1 2 3 4 5

    % de Tempo Alocado Número de Tarefas Alocadas Produtividade x Tarefas Simultâneas Produtividade cai ao fazermos várias atividades simultaneamente. Para piorar, usamos multitarefa justamente quando estamos atrasados no cronograma, piorando a situação terça-feira, 16 de abril de 13
  32. Alocação 100% A quantidade de trabalho em andamento é maior,

    mas o trabalho total leva mais tempo. Além disto, nos planejamentos persegue-se a alocação máxima das pessoas terça-feira, 16 de abril de 13
  33. Alocar 100% do tempo disponível é o mesmo que alocar

    100% de uma via terça-feira, 16 de abril de 13
  34. 6 Plano não prioriza o Cliente O plano parte da

    premissa que tudo será concluído, logo, a ordem de implementação das tarefas é a que melhor convém ao plano, e não ao cliente terça-feira, 16 de abril de 13
  35. http://en.wikipedia.org/wiki/Penrose_triangle Fixar escopo, custo e prazo raramente funciona na prática.

    Assim como o triângulo de Penrose, pode ser teorizado, mas não implementado no mundo real terça-feira, 16 de abril de 13
  36. 7% 13% 16% 19% 45% Sempre Geralmente Algumas vezes Raramente

    Nunca Índice de uso de funcionalidades Jim Johnson. The Standish Group International Inc. 2002 terça-feira, 16 de abril de 13
  37. http://sunnyday.mit.edu/16.355/armour.pdf Ten Unmyths of Project Estimation Reconsidering some commonly accepted

    project management practices Phillip Armour terça-feira, 16 de abril de 13
  38. Estimativa é uma probabilidade. Psicologicamente falando, só existe compromisso com

    elementos concretos. Logo, firmar compromissos com estimativas não faz sentido! terça-feira, 16 de abril de 13
  39. +400% de Variação -400% de Variação Cone da Incerteza Compromissos

    são firmados no início do projeto, momento em que as chances de erro são incrivelmente altas terça-feira, 16 de abril de 13
  40. Tenta-se antecipar o máximo de requisitos para se investir o

    máximo nas estimativas terça-feira, 16 de abril de 13
  41. 20% esforço 80% acurácia Não adianta investir tanto tempo nas

    estimativas, pois elas não ficam muito melhores com o passar do tempo terça-feira, 16 de abril de 13
  42. Alto investimento em planejamento (já que é um processo orientado

    a um plano), mas mudanças irão ocorrer terça-feira, 16 de abril de 13
  43. Alterações no plano implicam nos temidos replanejamentos: uma sequeência enorme

    de alterações em documentos e cronograma. terça-feira, 16 de abril de 13
  44. Gerando inclusive a rejeição dos gestores e do próprio time

    de desenvolvimento: dá tanto trabalho replanejar, que rejeitamos mudanças! terça-feira, 16 de abril de 13
  45. Ou então, investimos TANTO nisto, ficamos tão imersos nos detalhes

    e na nossa capacidade de antecipar TODOS os riscos, que acreditamos que temos um plano que não precisa ser mudado terça-feira, 16 de abril de 13
  46. Um processo Cascata, em tese, é mais fácil de controlar

    e verificar, pois existem diversos “pontos de controle”bem definidos, documentos aprovados, entradas/ saídas padronizadas. terça-feira, 16 de abril de 13
  47. 14% Porém, é como lidar o debug num sistema em

    produção. É mais fácil diagnosticar um problema, mas o sistema não roda por causa das ferramentas de diagnóstico. Logo, não adianta. terça-feira, 16 de abril de 13
  48. “Melhores estimativas são dadas por quem fará a tarefa” [7]

    “Tirar a média de estimativas individuais produz melhores resultados” [6] “Discussões em grupo geram melhores estimativas” [8] “Estimamos melhor de forma comparativa/relativa do que absoluta [10, 11] e comparando elementos de mesma ordem de grandeza” [12, 13] “Estimativas compartilhadas são melhores” [9] “Dialogar e justificar as estimativa aumenta sua acurácia [14] e compensa falta de informações” [15] terça-feira, 16 de abril de 13
  49. “Trabalhadores são incapazes de entender o que estão fazendo” Frederick

    Taylor http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor Inúmeros autores discordam disto, principalmente para o trabalho do conhecimento, que é o que fazemos, hoje, ao desenvolver software terça-feira, 16 de abril de 13
  50. Steve Denning W. Edwards Deming (1900 - 1993) Jurgen Appelo

    Henry Mintzberg Gary Hamel Peter Drucker (1909 - 2005) terça-feira, 16 de abril de 13
  51. Nós temos responsabiliadde como cidadãos de mudar este cenário, usar

    melhores processos e técnicas, abrirmos nossa cabeça para buscarmos alternativas diferentes terça-feira, 16 de abril de 13
  52. Se não pararmos de pensar da forma tradicional, como sempre

    fizemos, em um futuro próximo, poderemos não ter mais onde agir de forma tradicional terça-feira, 16 de abril de 13
  53. [1] Albert Lederer e Jayesh Prasad - Nine Management Guidelines

    for Better Cost Estimating - ACM, 1992) [2] Standish Group - Extreme Chaos, 2001 [3] Jim Johnson - Third Internacional Conference on Extreme Programming, 2002 [4] Standish Group - CHAOS Report, 2011 [5] Forrestere Report - Corporate Software Development Fails to Satisfy on Speed or Quality, 2005 [6] Martin Hoest and Claes Wohlin - An Experimental Study of Individual Subjective Effort Estimations and Combinations of the Estimates - International Conference on Software Engineering - 1998 [7] Maagne Jorgensen - A Review of Studies on Expert Estimation of Software Development Effort - Journal of Systems and Software - 2004 [8] Magne Jorgensen and Kjetil Molokken - Combination of Software Development Effort Prediciton Intervals: Why, Whem and How? - IEEE - 2002 [9] Albert Lederer e Jayesh Prasad - Nine Management Guidelines for Better Cost Estimating - ACM - 1992 [10] Albert Lederer e Jayesh Prasad - A Causal Model for Software Cost Estimating Erros - IEEE - 1998 [11] Vicinanza, Mukhopadhyay e Prietula - Software Effort Estimation: An Exploratory Study of Expert Performance - ISR - 1991 [12] Eduardo Miranda, Improving Subjctive Estimates Using Paired Comparisons - IEEE - 2001 [13] Thomas Saaty, Multicriteria Decision Making: The Analytic Hierarchy Process - RWS Publication. Journal of Experimental Social Psychology - 1996 [14] Hagafors e Brehmer - Does Having to Justify One's Decisions Change the Nature of the Decision Processo? - Organizacional Behavior and Human Performance - 1983 [15] Lyle Brenner, Derek Koehler and Amos Tversky - On the Evaluation of One-sided Evidence - Journal of Behavioral Decision Making - 1996 terça-feira, 16 de abril de 13