Estimativas Ágeis com Planning Poker

Palestra apresentada em 2012 no Encontro JavaBahia + LinguÁgil, realizado pela Faculdade IBES de Salvador.

Visando facilitar o entendimento dos slides, também estão inclusas as minhas anotações sobre o que é falado durante a palestra.

A palestra pode ser assistida na íntegra em: http://youtu.be/MjjAp4Gum7E

Transcript

1. Rafael Miranda @rafaelmbr Estimativas Ágeis com Planning Poker
2. Atenção: imagens fortes serão exibidas, que apresentam situações pelas quais não passamos
3. Atrasos no cronograma
4. Relatórios de acompanhamento justificando os atrasos no cronograma
5. Replanejamentos Constantes do cronograma
6. Corte da etapa de testes do cronograma
7. Criação de um “Pulmão” (ou buffer) no cronograma, que só faz diminuir
8. Cronogramas cheios de gordura, numa sucessão de “margens de segurança” Ou o inverso: sucessão de cortes de prazo, e que chega no final...
9. ... e um chefe fala: “Cronograma se cumpre!!!”
10. Qual a palavra comum nas situações anteriores?
11. Cronograma!
12. Cultura da Precisão O problema não é a ferramenta cronograma em si. Ela é até uma ferramenta interessante. O problema é o que a forma como a utilizamos reflete: cultura da PRECISÃO, muito comum na mentalidade tradicional e consequentemente nas empresas e projetos tradicionais.
13. Lider Chefe Gerente Cliente • Líder quer saber EXATAMENTE quando o desenvolvedor terminará a atividade X • Chefe quer saber EXATAMENTE quando o módulo XPTO será terminado • Gerente quer saber EXATAMENTE quando será a entrega do SIS-XPTO para homologação • Cliente quer saber EXTAMENTE quando poderá começar a usar o SIS-XPTO em produção
14. # FA I L A questão é que, em projetos de SW, toda resposta dada para as perguntas acima, na GRANDE maioria das vezes, estará errada! Você sabe disso! Todos sabemos, todos VIVEMOS isto...
15. ...mas não queremos aceitar, e tentamos racionalizar argumentos para tentar nos convencer do contrário!
16. Estimativa Cálculo aproximado, avaliação; conjectura aproximação, arbítrio, avaliação, consideração Cálculo aproximado implica em: possibilidade de ERRO
17. Precisão Acurácia http://www.infoq.com/br/articles/precisao-acuracia-agile Nos projetos ágeis, o foco das estimativas não é a PRECISÃO (precision), e sim a ACURÁCIA (accuracy).
18. Cálculo Aproximado !! Estimativa Intervalo de Confiança O intervalo de confiança é muito conhecido em estatística, e se assemelha ao intervalo das estimativas PERT, em que a estimativa consiste de uma valor do melhor caso, outro esperado e outro de pior caso
19. Menos preciso Mais preciso Precisão Maior precisão = menor intervalo de confiança
20. Estimado Realizado Acurácia Acurácia é a diferença entre o estimado e o realizado
21. Menos “acurado” Mais “acurado” Acurácia Maior acurácia = Menor diferença entre estimado e realizado (independentemente do intervalo de confiança) Se falo que “estimo entregar em Julho” e entrego, minha precisão é baixa, mas minha acurácia é alta
22. Projetos ágeis trabalham com margem e gordura ZERO, pois não existe a cultura da PRECISÃO, e sim a da ACURÁCIA, e todas as partes interessadas precisam estar cientes disto, e principalmente, ENTENDER e ACREDITAR nisto. Todas as partes interessadas precisam mudar a sua cultura!
23. Ao invés de buscar uma estimativa precisa: “vou acertar no centro do alvo” (e que provavelmente não acertarei ou darei sorte de acertar uma vez)
24. Os projetos ágeis buscam uma estimativa acurada e um pouco menos precisa: “vou acertar na região amarela do alvo” (e que provavelmente acertarei várias vezes)
25. Os projetos ágeis, reconhecendo REALMENTE as INCERTEZAS dos projetos, tentam EMPIRICAMENTE encontrar um nível de precisão aceitável, que viabilize a máxima acurácia...
26. ... empiricamente, assim como um pintor mistura as tintas para pintar sua obra!
27. ? ? Mas que incertezas são estas?
28. O cumprimento de estimativas em projetos de SW são influenciados por inúmeras VARIÁVEIS: Competência Técnica - Mudanças de Prioridades - Sentimentos e Interesses - Novas Necessidades - Realocação de Pessoas - ...
29. E todas as infinitas outras variáveis... Implementar software é algo complexo!
31. +400% de Variação -400% de Variação O Cone da Incerteza Na medida em que avançamos no projeto, estas variáveis vão sendo estabilizadas, e a incerteza vai sendo diminuída.
32. A gestão de projetos tradicional tenta antecipar o máximo de informações possíveis sobre o escopo para obter estimativas mais precisas.
33. Nos projetos tradicionais existe o COMPROMISSO com escopo + prazo + custo muito cedo (nas fases do cone de maior incerteza e variabilidade das estimativas), implicando nos problemas sobre os quais falamos no início, além de inúmeros outros que conhecemos (stress da equipe, horas-extras, redução de qualidade do produto, conflitos entre partes interessadas, etc)
34. Uma questão alarmante é que o método tradicional (que tenta evitar mudanças) proporciona uma estimativa de entrega do produto SOLICITADO inicialmente, que provavelmente não é o produto que deve realmente ser IMPLEMENTADO. Ou seja, ele dá uma ESTIMATIVA ERRADA para construção do PRODUTO ERRADO.
35. A gestão ágil utiliza uma abordagem diferente, empírica, que monta uma estratégia global, mas planeja passo a passo, adaptando-se ao que encontrar pela frente
36. Esforço mínimo suficiente para acurácia aceitável Nos projetos ágeis, ao invés de investir o máximo de tempo nas estimativas para se tentar uma grande acurácia, investe-se o menor tempo que gere a melhor relação esforço x acurácia http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
37. Mas isto requer uma mudança cultural grande, através da qual todos devemos re-pensar nossos comportamentos e atitudes. Re-pensar em como as coisas funcionam e como eles deveriam funcionar, visando o objetivo maior de ter sucesso nos projetos
38. ? ? Mas será que isto funciona realmente? E como fica a estimativa do projeto inteiro? Até o final?
39. Deadline Você acha que faz sentido trabalhar diariamente num projeto que faz alusão à morte?
40. Pois na prática é isto que temos. Todo mundo chega MORTO no final do projeto Projetos ágeis buscam um ritmo sustentável, e a forma de estimar e planejar reforça isto
41. Deve-se avaliar se é REALMENTE necessário estimar tudo o que se tem visibilidade e firmar compromissos de longo prazo. Para se ter ESTIMATIVAS (cálculo aproximado) de duração do projeto...
42. Funcionalidades Estimar o tamanho Derivar a duração Definição de datas Velocidade Funcionalidades Funcionalidades Funcionalidades http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415 Duração = Tamanho / Velocidade O quanto “a frente” você precisar, maior a quantidade de funcionalidades a estimar o tamanho. É importante balancear a quantidade de estimativas “a frente” são REALMENTE necessárias, para evitar desperdícios, pois as coisas mudam...
43. Vamos exemplificar: o seu trabalho é levar todo este monte de terra para o outro lado da rua...
44. 5 m 3 m 2 m = 30 m3 Você então ESTIMA (aproximadamente) o tamanho do seu trabalho...
45. • 1 m3 • 30 “viagens” • 5 min / viagem • 30 x 5 = 150 min 2,5 hs 30 m3 Com base nas suas ferramentas (carrinho que comporta 1 m3), você deriva a quantidade de viagens (perceba que “viagem” é uma unidade de medida abstrata). E depois estima a duração de cada viagem e deriva a duração total
46. 2,5 hrs 30 m3
47. 2,5 hrs 30 m3
48. Deadline Mas cuidado com estas datas... definir previamente datas fechadas *E* escopo fechado... Lembre-se que as INCERTEZAS são muitas!
49. ? ? ? ? Mas como então eu faço para estimar o tamanho do que vou implementar?
50. Planning Poker Técnica de estimativa criada em 2002 por James Grenning* e se popularizado por Mike Cohn em 2005 *Signatário do Manifesto Ágil
51. Uma técnica de estimativa baseada em consenso. Baseada no método Dephi de previsão, criado na década de 50 -> Especialistas anônimos
52. Pode utilizar qualquer unidade de medida que se queira: Fibonacci, Tribonacci, Tamanho de Camisas, etc
53. Mas deve utilizar a medida de forma relativa entre os itens estimados. “A última garrafa é X vezes maior do que a primeira”
54. 1 - 1 - 2 - 3 - 5 - 8 - 13 - 21 - 34 - ... Normalmente utiliza uma medida baseada na Sequência de Fibonacci Proporção áurea
55. 13 8 21 21 13 34 8 5 13 Deixa explícita a maior incerteza de estimativas maiores, por meio de um maior intervalo de confiança Pode-se entender de forma geral, que tenho 25% - 50% - 25% de chances de acertar
56. Não são exatamente as teorias sobre as quais falamos agora a pouco, porém, aplicadas?
57. Altera a Sequência de Fibonacci para deixar mais explícita a incerteza de estimativas de elementos maiores Cria cartas “coringa” como Zero, 1/2, ? e Café
58. Sim... mas este negócio de poker trás quais vantagens sobre a maneira que já faço estimativas? Ele é melhor mesmo?
59. http://en.wikipedia.org/wiki/Planning_poker Reduz a “ancoragem”: influência de outras pessoas sobre o seu julgamento
60. Permite que todos argumentem sobre suas estimativas e discutam sobre o elemento a ser estimado
61. Evita que no evento predomine a opinião dos que têm o “dom da oratória”
62. Ou que o evento seja “dominado” pelos que falam mais alto
63. Permite uma maior integração e sinergia entre o time, pois todos participam JUNTOS da estimativa, além de que TODOS tiveram “voto” na estimativa
64. Viabiliza uma maior descoberta e conhecimento do negócio do sistema, pois são realizadas discussões e explicações pelo Cliente
65. Viabiliza a antecipação do design do sistema, pois soluções são discutidas visando a maior segurança para estimar
66. Permite que riscos sejam antecipados... demonstrando que algo tem tudo para DAR M#$%ˆ!
67. Molokken-Ostvold, K. Haugen, N.C. (13 April 2007). "Combining Estimates with Planning Poker--An Empirical Study". IEEE Pode gerar resultados menos otimistas e mais precisos do que pela discussão aberta ou estimativa individualizada ou mecanizada
68. A dinâmica do evento cria um ciclo contínuo de interação entre o Time e o Cliente, em que a IMPORTÂNCIA, o ESCOPO e a COMPLEXIDADE vão sendo discutidos
69. É importante que seja a SUA estimativa e não a dos outros. Deve-se encarar como se SOMENTE VOCÊ estivesse estimando. Desta forma, VOCÊ precisará de todas as informações possíveis para ter mais segurança para estimar. Mas lembre-se, a estimativa é RELATIVA
70. Os elementos a serem estimados vão sendo quebradas em elementos menores para facilitar a estimativa e reduzir as incertezas
71. ? ? ? ? Mas como é a mecânica do evento?
72. Necessário: itens do a serem estimados. Preferencialmente, uma pequena parte do total
73. Necessário: cartas
74. Opcional: Facilitador
75. 1. Início 2. Definir menor estória 3. Visão geral primeiro item (PO) 4. Esclarecimentos (Time + PO) 5. Escolha individual de carta 6. Virada simultânea das cartas 4.1. Possíveis quebras 7. Maior e menor valores são explicados 8. Repetir até consenso
76. Importante: manter um tempo limite para cada rodada Lembre-se: investir a menor quantidade de tempo necessária...
77. Maior Menor Média Maioria Experimente algumas rodadas. Se não hegarem ao consenso, escolham uma alternativa e sigam adiante
78. Muito importante: paradas programadas para o café e banheiro
79. O MAIS IMPORTANTE: Tem que ser D-I-V-E-R-T-I-D-O !!!
80. “O menor caminho para exceder as expectativas raramente passa por atender as expectativas” Ward Cunningham
81. Obrigado! Rafael Miranda @rafaelmbr