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
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
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
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
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
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
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
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
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
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
% 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
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
e verificar, pois existem diversos “pontos de controle”bem definidos, documentos aprovados, entradas/ saídas padronizadas. terça-feira, 16 de abril de 13
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
“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
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
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
orafaelmira
mercari_inc
lemonadegt
jtes
loglass2019
tokyo_metropolitan_gov_digital_hr
dmm
botexpress
xendou
akippa
openwork
beerandtech_recruiter
daichihayashi
lara
zakiyama
irinanazarova
jponch
marcelosomers
jnunemaker
jlugia
quramy
productmarketing
denniskardys
colly
honnibal
![“66% dos projetos ultrapassam significativamente os custos estimados” [1] “Somente](https://files.speakerdeck.com/presentations/8ec86be088f20130ebfb22000a8d82a0/slide_10.jpg){kind=link}
![“Melhores estimativas são dadas por quem fará a tarefa” [7]](https://files.speakerdeck.com/presentations/8ec86be088f20130ebfb22000a8d82a0/slide_77.jpg){kind=link}
![[1] Albert Lederer e Jayesh Prasad - Nine Management Guidelines](https://files.speakerdeck.com/presentations/8ec86be088f20130ebfb22000a8d82a0/slide_89.jpg){kind=link}