Scrum Sprint Planning

Dar a equipe informação suficiente pra trabalhar. Dar ao Product Owner confiança na equipe.

Transcript

1. Planejamento  de   Sprint   Dar  a  equipe  informação  suficiente  para  trabalhar;   Dar  ao  Product  Owner  confiança  na  equipe;  
2. Resultado  concreto   •  Obje=vo  claro  do  Sprint.   •  Equipe  comprome=da  com  a  meta.   •  Sprint  Backlog.   •  Data  de  apresentação  do  Sprint.  
3. P.O.  deve  participar?   “Pessoal,  eu  já  listei  o  que  eu  quero.  Eu  não  tenho  tempo  para   estar  na  sua  reunião  de  planejamento”  
4. P.O.  deve  participar?   16 | SCRUM E XP DIRETO DAS TRINCHEIRAS Escopo e importância são definidos pelo product owner. Es definida pela equipe. Durante uma reunião de planejamento estas três variáveis são refinadas continuamente por diálogo entre equipe e product owner. Normalmente, o product owner inicia a reunião resumindo se Essas  três  variáveis  precisam  ser  refinadas  con=nuamente  por   diálogo  “cara-­‐a-­‐cara”  entre  a  equipe  e  o  P.O.  
5. P.O.  deve  participar?  Sim!   Pode  ocorrer:     •  Mudança  de  es=ma=vas  pela  equipe   •  Mudança  de  importância/prioridade  das  estórias  
6. P.O  =  O  cara!   “Fundamental  para  o  desenvolvimento  ágil”  
7. Objetivo  do  Sprint   “Por  que  nós  estamos  fazendo  este  sprint?  Porque   não  saímos  de  férias  ao  invés  de  fazê-­‐lo?”  
8. Tamanho  do  Sprint?   Sprints  curtos  (1  a  3  semanas)?     Ou     Sprints  longos  (1  mês  a  2  meses)?  
9. Tamanho  do  Sprint?   •  Sprints  curtos:   Ciclo  curto  de  feedback  =  entregas  mais  freqüentes  =  feedback   mais  freqüente  do  cliente  =  menos  tempo  perdido,  indo  na   direção  errada  =  aprender  e  melhorar  rápido,  etc.   •  Sprints  longos:   A  equipe  tem  mais  tempo  para  ganhar  ritmo,  ela  tem  mais   espaço  para  se  recuperar  dos  problemas,  e  conseguir  a=ngir  o   obje=vo  do  sprint,  você  tem  menos  overhead  em  termos  de   reuniões  de  planejamento,  apresentações,  etc.  
10. Tamanho  do  Sprint?   “No  geral,  product  owners  gostam  de  sprints   curtos  e  desenvolvedores  preferem  os  longos.   Então  o  tamanho  do  sprint  representa  um   compromisso”  
11. Qualidade  Externa  vs.  Interna   •  Externa:   O  que  é  percebido  pelos  usuários  do  sistema.  Ex:  “Interface”.   •  Interna:   Questões  que  normalmente  não  são  visíveis  ao  usuário,  mas   que  têm  profundos  efeitos  na  manutenibilidade  do  sistema.   Ex:  “Cobertura  de  testes”.  
12. Negociação  de  estórias     Alta  qualidade  INTERNA   +   Baixa  qualidade  EXTERNA  
13. Negociação  de  estórias     Baixa  qualidade  INTERNA   +   Alta  qualidade  EXTERNA   ?  
14. Negociação  de  estórias     Baixa  qualidade  INTERNA   +   Alta  qualidade  EXTERNA   “É  diecil  construir  algo  legal  a  par=r  de  fundações  podres”  
15. Estórias  técnicas   •  Não  fazem  parte  das  entregas.   •  Não  estão  relacionadas  diretamente  com  nenhuma  estória   específica.   •  Não  agregam  valor  para  o  product  owner.   Exemplo:     •  Instalar  um  servidor  de  build.   •  Escrever  um  resumo  do  projeto  do  sistema.   •  Refazer  a  camada  DAO.   •  Fazer  o  upgrade  de  um  framework.  
16. Quais  estórias  faremos?   Decidindo quais estórias incluir no spr Uma das principais atividades da reunião de planejamento do sprin decidir quais estórias incluir no sprint. Mais especificamente, qu estórias do product backlog copiar para o sprint backlog. Observe a figura acima. Cada retângulo representa uma estória, orden
17. Técnica  de  estimativa   •  Ins=nto  /  Sen=mentos  /  Percepções.   •  Cálculo  de  velocidade  baseado  no  tempo  de  ontem,  e  cálculo   de  velocidade  baseada  no  homens-­‐dia  disponíveis  e  fator  de   foco.  
18. Velocidade  Estimada  x  Real   item é medido com base na sua estimativa inicial. A figura abaixo mostra um exemplo de velocidade estimada no um sprint e a velocidade real no final do sprint. Cada retângul estória, e o número dentro dele é a estimativa inicial dela. Note que a velocidade real é baseada na estimativa inicial de cada Quaisquer modificações na estimativa de tempo da estória durante devem ser ignoradas.
19. Estimativas,  como  calcular?   Dias  disponíveis   Bruno   15   Caio   15   Diego   15   Ricardo   15   Total   60   homens-­‐dia  
20. Estimativas,  como  calcular?   “Fator  de  foco”  
21. Estimativas,  como  calcular?   28 | SCRUM E XP DIRETO DAS TRINCHEIRAS O fator de foco é uma estimativa de como a equipe é focada. Um fator de foco baixo, pode significar que a equipe espera ter muitas interferências ou percebe que suas próprias estimativas de tempo são otimistas. A melhor maneira para determinar um fator de foco razoável é considerar o último sprint (ou melhor ainda, a média de alguns sprints anteriores).
22. Estimativas,  como  calcular?   O fator de foco é uma estimativa de como a equipe é focada. U foco baixo, pode significar que a equipe espera ter muitas inte ou percebe que suas próprias estimativas de tempo são otimistas A melhor maneira para determinar um fator de foco razoável é o último sprint (ou melhor ainda, a média de alguns sprints anter A velocidade atual é a soma das estimativas iniciais de todas que foram finalizadas no último sprint. Vamos supor que o último sprint terminou 18 pontos p utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trab
23. Estimativas,  como  calcular?   que foram finalizadas no último sprint. Vamos supor que o último sprint terminou 18 pontos por estória utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trabalhando 3 semanas, resultando em um total de 45 homens-dia. E agora nós estamos tentando calcular nossa velocidade estimada para o próximo sprint. Para complicar as coisas, um cara novo, o Dave, está se juntando à equipe para esse sprint. Levando em consideração as folgas e as obstruções nós temos 50 homem-dias para o próximo sprint. Portanto, nossa velocidade estimada para o próximo sprint é de 20 pontos por estória. O que significa que a equipe deveria adicionar estórias ao sprint até atingir uma soma de aproximadamente 20.
24. Estimar  pode  ser  um  problema   •  Normalmente  nós  não  sabemos  exatamente  quem  vai   implementar  quais  partes  de  quais  estórias.   •  Envolvem  diversas  pessoas  e  diversos  Kpos  de  experKse   (design  de  interface  de  usuário,  codificação,  teste,  etc).   •  Discrepâncias  onde  duas  pessoas  da  equipe  têm  esKmaKvas   bastante  diferentes  para  a  mesma  estória.  
25. Planning  Poker  
26. Planning  Poker  
27. Planning  Poker  
28. Planning  Poker  
29. Planning  Poker   “Proporcionar  uma  visão  comum  do  trabalho   envolvido  na  estória”  
30. Planning  Poker   Existem  algumas  cartas  especiais:     •  0  =  “esta  estória  já  está  feita”  ou  “esta  estória  é  tão  pequena  que   leva  somente  alguns  minutos  de  trabalho”;   •  ?  =  “Eu  não  faço  idéia  alguma”;   •  Xícara  de  café  =  “Estou  cansado  demais  para  pensar.  Vamos  fazer   uma  pequena  pausa”.  
31. Hum,  o  que  já  vimos?   •  P.O.  é  o  cara.   •  Entender  e  negociar  as  estórias.   •  Es=mar  as  estórias.  
32. Organizando  o  Sprint  Backlog?   Parece bom? Bem, não é. Normalmente é um saco. E o que é pior, a equipe normalmente não avisa que é um saco até eles chegarem no fim da reunião e perceberem que ainda não conseguiram passar para lista de estórias! Uma solução que funciona muito melhor é criar cartões e colocá-los na parede (ou numa mesa grande). Esta é uma interface de usuário superior comparada a computador & projetor porque:  Pessoas ficam em pé e caminham => elas ficam acordadas e alerta por mais tempo.
33. Organizando  o  Sprint  Backlog?   COMO PLANEJAMOS SPRINT | 33
34. Término  do  Sprint  Planning   Só  será  um  sucesso  se:     •  Todos  sairem  da  reunião  com  um  sorriso  no  rosto.   •  Todos  acordarem  no  dia  seguinte  com  um  sorriso  no  rosto.   •  Todos  fizerem  a  primeira  reunião  diária  com  um  sorriso  no   rosto.  
35. DeQinição  de  pronto   “Uma  estória  está  completa  quando  todo  o  código   está  no  repositório?  Ou  está  completa  apenas   quando  foi  feito  deploy  em  um  ambiente  de  teste   e  a  estória  foi  verificada  por  uma  equipe  de  testes   de  integração?”  
36. XP  –  Programação  em  par   (  -­‐    )  “15%  mais  lento  do  que  uma  pessoa  sozinha”   (  +  )  “Qualidade  do  solware”  e  “Disseminação  do   conhecimento”     Esses  15%  de  perda,  são  calibrado  com  15%  de  ganho  em:     •  Menos  bugs.   •  Melhor  manutenção.  
37. Agenda  da  reunião   •  P.O.  repassa  objeKvo  do  Sprint.   •  P.O.  sumariza  o  Product  Backlog  para  a  equipe.   •  Os  itens  priorizados  são  esclarecidos  pelo  P.O.   •  Uma  data  de  apresentação  do  Sprint  é  escolhida.   •  Equipe  esKma  as  estórias,  quebrando  em  tarefas  se   necessario.  Pode-­‐se  usar  o  “Como  demostrar…”  para   esclarecer  melhor.   •  Equipe  escolhe  e  calcula  cada  estórias  para  entrar  no  Sprint.   •  Todos  criam  a  definição  de  pronto  (DoD).   •  Todos  fecham  o  escopo  e  escolhem  o  local  da  reunião  diária.