AgileTourBH 2014 - Isabella Fonseca - Metodologias ágeis e MPS.BR – Aplicação prática

424 visualizações

Publicada em

AgileTourBH 2014 - Isabella Fonseca - Metodologias ágeis e MPS.BR – Aplicação prática

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
424
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
20
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

AgileTourBH 2014 - Isabella Fonseca - Metodologias ágeis e MPS.BR – Aplicação prática

  1. 1. Metodologias  ágeis  e  MPS.BR  –  Aplicação  Prá9ca     Isabella  Fonseca   isabella.afonseca@gmail.com  
  2. 2. Apresentação   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   2   Isabella  Fonseca  É  Certified  Scrum  Master  (CSM)  com  9   anos  de  prática  de  Scrum,  tendo  sido  líder  no  SEPG  que   conduziu  a  Powerlogic  à  certificação  MPS.BR  Nível  F  em   junho/2007  e  MPS.BR  Nível  C  em  março/2010   incorporando  grande  nível  de  abrangência  do  Scrum,  XP   e  Lean  Principles.     É  também  PMP-­‐ACP.  Atuou  como  Scrum  Master  e   Product  Owner  participando  de  mais  de  150  Sprints   (iterações  de  desenvolvimento  ágeis)  rodados  e   aperfeiçoados  ao  longo  dos  últimos  anos.     Formada  em  Ciência  da  Computação  pela  PUC-­‐MG  com   especialização  em  Redes  de  Telecomunicações  pela   UFMG.  É  consultora  de  processos  de  desenvolvimento  de   Software  e  Serviços  na  área  de  Qualidade  da  FUMSOFT.  
  3. 3. •  Processo  de  Desenvolvimento  de  Software  da  Powerlogic   (PDS_P&D_v19)   •  Craig  Larman:  Agile  and  Iterative  Development:  A  Manager’s  Guide,   Addison-­‐Wesley  2003   •  Artigo:  “Por  que  SCRUM?”,  ESM,  4ª.  ed.  (Agosto  2008)  escrito  por   Fonseca,  I.  e  Campos,  A.   •  Artigo:  “Ideal  Day  e  Priorização?”,  ESM,  6ª.  ed.  (Outubro  2008)   escrito  por  Fonseca,  I.,  Alves,  M.  e  Alves,  F.   •  Mary  and  Tom  Poppendieck:  Lean  Software  development,  Addison   Wesley  2003   •  Ken  Schwaber  and  Mike  Beedle:  Agile  Software  Development  with   SCRUM,  Prentice  Hall  2001   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   3   Bibliografia  
  4. 4. Bibliografia   •  Ken  Schwaber:  Agile  Project  Management  with  SCRUM,  Microsoft   Press  2004   •  Takeuchi  &  Nonaka,  “The  New  New  Product  Development  Game”,   Harvard  Business  Review,  Jan/Feb  1986     •  Cohn,  “Agile  Estimating  and  Planning”,  Prentice  Hall,  2006     •  Alistair  Cockburn:  Agile  Software  Development,  Cockburn  Highsmith   Series  Editors,  2000   •  http://www.rallydev.com/sites/default/files/5%20levels%20of %20agile%20planning-­‐Portuguese-­‐Final.pdf   •  http://scrumex.com.br/blog/?p=907   •  http://www.cesar.edu.br/docs/paulocaju.pdf   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   4  
  5. 5. Mo#vações  para  busca  de  um  modelo   híbrido   Isabella  Fonseca    
  6. 6. TEORIA  DAS  RESTRIÇÕES   “Usando  esse  processo   podemos  enfocar  nossos   esforços  nos  poucos  pontos   de  um  sistema  que   determinam  seu   desempenho  (nas  suas   restrições),  e  assim   podemos  melhorar   significativamente  no  curto   prazo.”   Eliyahu  Goldratt  –  A  Meta     Escopo   Prazo  Preço   Projeto  Urgente   Escopo   Prazo  Preço   Projeto  Crí9co   Escopo   Prazo  Preço   Sem  Orçamento   Motivações  para  busca  de  um  modelo  híbrido     Fonte:  Processo  de   Desenvolvimento  de  Software   da  Powerlogic  (PDS_P&D_v19)  
  7. 7. Motivações  para  busca  de  um  modelo  híbrido     Fonte:  Craig  Larman  –  Agile  &  Iterative  Development   CONE  DA   INCERTEZA  -­‐   Planos   evolucionários   trazem  maior   possibilidade  de   acerto.    
  8. 8. TEORIA  DO  CAOS  –     Trata  do  funcionamento   de  sistemas  complexos  e   dinâmicos.     Processos  Preditivos  não   são  adequados  para  este   tipo  de  desenvolvimento   de  produtos.     Não  garantem  sua   previsibilidade!!     Ser  ágil  é  ser  capaz  de   responder  ou  impor   mudanças  estratégicas.     Motivações  para  busca  de  um  modelo  híbrido    
  9. 9. PLANNING  CONSTANTE!   Múl9plos  PDCAs:    Plan  -­‐  Do  –  Check  –  Act   O  ciclo  de  Deming  tem  por  princípio   tornar  mais  claros  e  ágeis  os  processos   envolvidos  na  execução  -­‐>  Melhoria   ConVnua   Motivações  para  busca  de  um  modelo  híbrido    
  10. 10. Motivações  para  busca  de  um  modelo  híbrido   As  atividades  de  planejamento  para  projetos  de   desenvolvimento  devem  se  basear  em  cinco   níveis:   –  Visão  do  Produto     –  Roadmap  do  Produto     –  Planejamento  do  Release   –  Planejamento  da  Iteração     –  Planejamento  Diário   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   10   Fonte: http://www.rallydev.com/sites/default/files/5%20levels%20of %20agile%20planning-­‐Portuguese-­‐Final.pdf  
  11. 11. 02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   11   Fonte:  http://www.rallydev.com/sites/default/files/5%20levels%20of%20agile %20planning-­‐Portuguese-­‐Final.pdf   Motivações  para  busca  de  um  modelo  híbrido  
  12. 12. Motivações  para  busca  de  um  modelo  híbrido     Fonte:  Alistar  Cockburn  -­‐  Agile  Software  Development  
  13. 13. Através  da  evolução,  entedimento  e  aplicação  de   modelos  de  qualidade,  a    fundamentação  básica  do   CMMI  já  vem  sendo  interpretada  de  forma  mais   “ágil”  por  consultores  e  certificadores,  conscientes   das  burocracias  desnecessárias  advindas  de   aplicação  de  “fórmulas”  não  contextualizadas.         Motivações  para  busca  de  um  modelo  híbrido    
  14. 14. Motivações  para  busca  de  um  modelo  híbrido     Fonte:  The  Ra9onal  Unified  Process  Made  Easy:  A  Prac99oner's  Guide  to  the  RUP  
  15. 15. Motivações  para  busca  de  um  modelo  híbrido     Fonte:  The  Ra9onal  Unified  Process  Made  Easy:  A  Prac99oner's  Guide  to  the  RUP  
  16. 16. “O  caráter  sensato  “de  ênfase”  (e  não  ruptura)  do  Manifesto  da  Agilidade   tem  sido  ignorado  em  algumas  posturas  radicais  que,  precipitadas,   chegam  a  confundir  agilidade  com  mera  informalidade.”     Paulo  Alvim   Motivações  para  busca  de  um  modelo  híbrido     hZp://www.agilemanifesto.org  
  17. 17. Práticas  de  métodos  ágeis  podem  ser  mapeadas  às   áreas-­‐chaves  de  processos  do  MPS.BR  ou  CMMI  levando   às  organizações  a  implementarem  as  atividades   necessárias  a  implantação  do  modelo  e  ainda  continuar   com  as  vantagens  e  leveza  dos  métodos  ágeis.     Estes  modelos  dizem  o  que  fazer,  mas  não  dizem  como   fazer.  Metodologias  ágeis  são  um  conjunto  de  melhores   práticas  que  contém  informações  específicas  de  “como   fazer”.   Motivações  para  busca  de  um  modelo  híbrido  
  18. 18. Em Otimização Gerenciado Quantitativamente Definido Largamente Definido Parcialmente Definido Gerenciado Parcialmente Gerenciado A B C D E F G 2 3 4 5 PROGRAMA  DE  MELHORIA  DE  PROCESSO  DE  SW-­‐BRASILEIRO   INICIATIVA  SOFTEX/  APOIO  BID   •         Avaliações  realizadas:  596  Software  e  7  Serviços  =  TOTAL  603   •        Instituições  Implementadoras  (II):  19   •        Instituições  Organizadoras  de  Grupos  de  Empresas  (IOGES):  São  17   instituições  e  72  projetos.   •        Instituições  Avaliadoras:  13   •        Cursos  realizados:  277   •        Provas  realizadas:  60   •        Participantes  de  cursos  oficiais  MPS  presenciais:  5974   •        Participantes  de  cursos  oficiais  MPS  EAD:  117   •        Aprovados  em  provas  oficiais  MPS:  1416   Dados  de  Outubro/2014  
  19. 19. Exemplo  de  um  modelo  híbrido   Fonte:  hZp://www.powerlogic.com.br  
  20. 20. Visão  Prá#ca   Isabella  Fonseca    
  21. 21. PreGame   Game   PostGame   Monitoramento   Produto   Release  1   Release  N-­‐1   Release  N   Product     Backlog   Release   Backlog   Alta  Gestão   Clientes   Suporte,  Comercial,  etc   Priorização   GPR   GCO   VA L   GRI   GRE   DRE   PCP   GRU   GPP   MED   Release   Planning  1   Release  Review   Release  Retrospective   GPR  GRU   GRH   GRI  GRE   VAL   GRE   GRI   MED   ITP   GQ A   AMP   Scrum   Team   GRH   GRH   Release   Backlog   PreSprint   (N-­‐1))   Sprint   (N)   PostSpri nt  (N+1)   GRE   DRE   VAL   ITP   MED   GQA   GCO   VER   Sprint  Planning  1   Sprint  Planning  2   Sprint  Review   Sprint   Retrospec9ve   Daily  Scrum   Rees9mate  Mee9ng   Follow  Up  Mee9ng   Abnormal  Termina9on  Sprint  Mee9ng   Sprint   Scrum   Team   1   2   3   4   VAL   VER   Selected   Backlog   Sprint   Backlog  
  22. 22. Produto   Release  1   Release  N-­‐1   Release  N   Product     Backlog   Release   Backlog   Alta  Gestão   Clientes   Suporte,  Comercial,  etc   Priorização   GPR   GCO   VAL   GRI   GRE   DRE   PCP   GRU   GPP   MED   1  
  23. 23. PreGame   Game   PostGame   Release   Monitoramento   Release  Planning  2   GCO   Release  Planning  1   Release  Review   Release  Retrospec#ve   GPR  GRU   GRH   GRI  GRE   VAL   GRE   GRI   MED   ITP   GQA   AMP   Scrum   Team   GRH   GRH   Release   Backlog   2   VAL   VER  
  24. 24. Game   PreSprint  (N-­‐1))   Sprint   (N)   PostSprint   (N+1)   GRE   DRE   Scrum   Team   Auditor  (GQA)  e  GCO   QC  Externo   VAL   ITP   MED   GQA   GCO   VER   3  
  25. 25. Sprint   Sprint  Planning  1   Sprint  Planning  2   Sprint  Review   Sprint  Retrospec9ve   Daily  Scrum   Rees9mate  Mee9ng   Follow  Up  Mee9ng   Abnormal  Termina9on  Sprint  Mee9ng   ITP  PCP   GCO   GQA   DRE   GRU  DFP   DRU   GRI   AMP   MED  VER   VAL  GRE   Selected   Backlog   Sprint   Backlog   4  
  26. 26. DESAFIO  1:   GPR    (Gerência  de  Projetos):  Como   gerenciar  com  base  em  “planejamento   conYnuo”  (planning)  em  lugar  de  um   grande  plano  inicial?    
  27. 27. Fonte:  hZp://www.powerlogic.com.br   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   27   Planning  constante!   GPR1   GPR3   GPR5   GPR10   GPR,  GRI,  AMP  GPR,  GRI   GPR1  -­‐  O  escopo  do   projeto  é  definido.     GPR3  -­‐  O  ciclo  de  vida  do   projeto  é  definido.     GPR5  –  O  cronograma  do   projeto,  incluindo  marcos   e  pontos  de  controle,  é   man9do.     GPR10  -­‐  Um  plano  geral  é   estabelecido.       GPR2  -­‐  .o  tamanho.  é     dimensionado.   GPR4  -­‐O  esforço  para  a   execução  são  es9mados  .   GPR11  -­‐  A  viabilidade  de   a9ngir  as  metas  é     avaliada.   GPR12  -­‐  O  Plano  do   Projeto  é  revisado  com   todos.   GPR17  -­‐  Revisões  são   realizadas  em  marcos  do   projeto.     AMP  –  Avaliação  e   Melhoria  de  Processo     GPR  7     e  GRH   GPR7  -­‐  Os  recursos   humanos  para  o  projeto   são  planejados   considerando  o  perfil  e   o  conhecimento   necessários  para   executá-­‐lo  .     GRH  –  Gerência  de   Recursos  Humanos   GPR13  -­‐  O  escopo,  as   es9ma9vas,  o   cronograma  do  projeto   são  monitorados  .   GPR14  -­‐  Os  recursos   materiais  e  humanos   são  monitorados.   GPR15  -­‐  Os  riscos  são   monitorados  em  relação   ao  planejado  .   GPR18  -­‐  Registros  de   problemas.   GPR19  -­‐  Ações  para   corrigir  desvios  em   relação  ao  planejado  são   estabelecidas,   implementadas  e   acompanhadas  até  a  sua   conclusão       GPR13,   14,15,  18   e  19.   GPR,  GRI,  AMP  
  28. 28. Boas  Práticas  –  Uso  do  Release  Goal   ▫  Breve  declaração  que  informa  o  foco  do  trabalho   durante  uma  Release  dado  pelo  Product  Owner   ▫  Orienta  o  time  no  monitoramento  e  andamento  dos   trabalhos  e  entrega  de  maior  retorno  de  valor   ▫  Deve  estar  coerente  aos  itens  de  backlog  da  release  –   Release  Backlog   ▫  Cria  alinhamento  entre  PO,  SM  e  Time  e  comunica  aos   envolvidos  em  que  o  time  está  trabalhando.     02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   28  
  29. 29. Boas  Práticas  –  Plano  de  Capacitação   Fonte:  hZp://www.powerlogic.com.br  
  30. 30. Boas  Práticas:  Real  Sprint  Review   ▫ Realizada  após  cada  Sprint,  com  duração   de  entre  2  a  4    horas  e  participação  do   PO.     ▫ Equipe  apresenta  os  resultados  obtidos   durante  o  Sprint.     ▫ O  Sprint  Goal  é  verificado!   ▫   Informal  -­‐>  sem  slides!!!   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   30  
  31. 31. Boas  Práticas:  Real  Retrospective   Meeting   ▫  Reunião  com  duração  de  1-­‐2  horas.   Levantamento  das  lições  aprendidas.     ▫  Timeline  pode  ser  relembrado  em  grupo.   ▫  2  perguntas:     ▫  "O  que  foi  bem?"  (WWW-­‐What  Went  Well?)  e     ▫  "O  que  pode  ser  melhorado?  (WCBI  -­‐  What  Can  Be   Improved?).   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   31  
  32. 32. Boas  Práticas:  Daily  Scrum  –   viabilidade  diária   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   32   Para  manter  o  controle  sobre  o  andamento  do  projeto,  sugere-­‐se   fortemente  inves9r  15  minutos  diários  para  atualizar  o  status  do  “o  que  foi   feito  ontem“  e  reafirmar  o  compromisso  com  o  trabalho  de  hoje  e  da   iteração.  Problemas  devem  ser  levantados  e  suas  soluções  devem  ser   definidas.  A  viabilidade  é  con9nuamente  avaliada.   Nome%do%Release:% Nome%da%Iteração:% O%que%foi%feito%hoje%(tarefas)?% O%que%será%feito%amanhã%(tarefas)?% Que%impedimentos%ocorreram?% Riscos:% Viabilidade%comprometida?% !
  33. 33. Boas  Práticas:  Estado  'pronto'  (ready)   •  Acordo  sobre  entregáveis  quando  uma   funcionalidade  está  “pronta”.   •  Diz  respeito  ao  estado  estável  e   conhecido  necessário  para  que  o  time   possa  iniciar  seus  trabalhos.     •  É  a  partir  desse  estado  que  o  time   pode  se  auto-­‐organizar  e  exercitar  sua   multidisciplinaridade.    
  34. 34. Boas  práticas:  Acompanhamento  via   Kanban   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   34   Fonte:  Livro  Scrum  e  XP  direto  das  trincheiras    
  35. 35. Boas  práticas:  Uso  do  BurnDown   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   35   Fonte:  hZp://www.powerlogic.com.br   Fonte:  hZp://www.powerlogic.com.br   Fonte:  hZp://www.powerlogic.com.br   Fonte:  hZp://www.powerlogic.com.br  
  36. 36. Boas  Práticas:  Levantamento  e  atuação   diante  dos  impedimentos   ▫  Entendimento  de  impedimentos:  eventos   que  impeçam  o  progresso  do  9me  dentro  do   Sprint.   ▫  Problemas  pessoais   ▫  Interrupções  externas  –  a9vidades  de   outro  projeto,  reuniões,  atendimento,   etc.   ▫  Devem  ser  tratados  até  sua  conclusão.   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   36  
  37. 37. Desafio  2:   GRE  (Gerência  de  Requisitos):  Como   es#mar  requisitos  que  são  parcialmente   conhecidos  no  início  do  projeto?  
  38. 38. GRE  –  Gerência  de  Requisitos     •  Priorização  dos  itens  do  backlog   •  Quebra  de  itens  do  Product  Backlog  em   Atividades     •  Refinamento  de  itens  do    de  Product  Backlog,   com  refinamento  em  três  fases  (Release   Backlog  -­‐>  Select  Backlog  -­‐>  Sprint  Backlog)     •  Uso  de  Ideal  Day,  Story  Point,  EmpresaPoint,   etc.   •  Uso  de  Planning  Poker    
  39. 39. Boas  Práticas:  Priorização  itens  do  Product  Backlog   Pontos  a  serem  levados  em  consideração:   -­‐   80%  do  valor  de  um  sorware  vem  de  20%  das  funcionalidades   -­‐   Cerca  de  60%  das  funcionalidades  entregues  em  projetos  de  sucesso  são     raramente  ou  nunca  u9lizadas.   Fonte:  hZp://www.sorhouse.se/   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   39  
  40. 40. •  Um  gráfico  de  quatro  quadrantes  de  itens  do  escopo  que   foram  classificados  em  função  seu  BV  e  sua  facilidade  de   implementação.  Itens  que  se  concentram  no  quadrante   superior  direito  são  os  que  devem  ser  priorizados  e,   seguramente,  são  os  que  mais  representam  a  maximização   do  resultado.     Fonte:  hZp://www.powerlogic.com.br   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   40   Boas  Práticas:  Priorização  itens  do  Product  Backlog  
  41. 41. Plano  Ágil   Sprint  1   48  SP  -­‐  400  BV   Sprint  2   52  SP  -­‐  250  BV     Sprint  3   55  SP  -­‐  150  BV   Sprint  4   40  SP  -­‐  100  BV   Sprint  5   50  SP  -­‐  100  BV   Plano  de  Projeto  (Release  Plan):  Total  de  245  SP  e  1.000  BV   Gaste    60%  do   tempo  elicitando   os  20%  de  itens  no   "topo  da  pilha"   Gaste  outros  30%   estimando  os  20%   próximos   Gaste  10%  para  o  restante   20%   20%   60%   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   41   Boas  Práticas:  Priorização  itens  do  Product  Backlog  
  42. 42. Boas  Práticas:  Refinamento  e  Quebra    
  43. 43. Boas  práticas  –  Quebra  e  Agrupamento   Fonte:  hZp://www.powerlogic.com.br  
  44. 44. Estimativas  Ágeis       •  A  estimativa  empírica  é  uma  maneira  sensata  de   se  prever  o  tamanho  de  requisitos  acompanhada   por:     –  Realimentação  iterativa  da  "velocidade",  a  partir  de  dados   históricos  coletados  para  a  mesma  equipe.     –  Realização  de  consenso  entre  especialistas,  com  técnicas  de   comunicação  e  convergência  como  a  do  Planning  Poker.     –  Utilização  da  técnica  de  PERT  (Program  Evaluation  and  Review   Technique).     –  Utilização  de  balanceamento  como  a  técnica  Cocomo   (COnstructive  COst  MOdel).   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   44  
  45. 45. Boas  práticas  –  Uso  do  Planning  Poker     •  Planning  Poker   – Envolvimento  de  todo  o  Time   – Evita  influência  nas  opiniões   – Aprendizado  nos  requisitos  até  que  haja   consenso   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   45  
  46. 46. Estimativas  Ágeis  –  Velocidade  da  equipe   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   46  
  47. 47. Desafio  3:   GPR  e  GCO  (Gerência  de  Projetos  e   Configuração):  Como  aceitar  mudanças   estratégicas  e  controlá-­‐las?  
  48. 48. SM  –  Solicitação  de  Mudança       •  Solicitação  de  Mudança  “leve”:  Mudanças  ao   final  do  Sprint  ou  dentro  de  um  Sprint  que   não  afetem  o  “Sprint  Goal”  não  requerem   “Solicitação  de  Mudança”.  Somente  são   requeridas  em  situações  críticas  (Ex.:  “não   vamos  cumprir  o  Goal”)  ou  para  mudanças  de   configuração     02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   48  
  49. 49. Desafio  5:   MED  (Medição):  O  que  são  bons  indicadores   em  um  processo  ágil?  
  50. 50. Boas  práticas:  Sistema  de  Avaliação  e  Controle   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   50   A  avaliação  e  o  controle  de  um  Plano  de  Tecnologia  permite  reduzir  a  diferença   entre  o  desempenho  esperado  e  o  desempenho  real,  garan9ndo  sua  eficácia.  Por   isso,  devem  ser  realizados  antes,  durante  e  após  a  implementação  do  Plano.     ! Desvio'de'esforço'ou'custo'no'projeto' ! Gráfico'de'BurnDown'! ! ! !
  51. 51. Indicador  que  mede  o  progresso  do  trabalho  refle9ndo  diariamente  seu   trabalho.  Sua  curva  indica  se  o  Scrum  Team  está  se  adaptando  para  o  plano   definido  e  comprome9do  por  todos  -­‐  Sprint  Goal  e  conseguindo  trabalhar  de   forma  realmente  itera9va  ou  sofrendo  impedimentos  em  excesso.   Boas  práticas:  Sistema  de  Avaliação  e  Controle  
  52. 52. Também  é  interessante  armazenar  o  histórico  de  sucesso  de  alcance  de  goals  a   cada  Sprint.  Para  isso,  sugere-­‐se  criar  um  indicador  simples  de  resultado  por   iteração  a  fim  de  manter  a  equipe  focada  em  melhorar  seu  desempenho.  Além   disso,  de  forma  lúdica,  pode-­‐se  criar  mecanismos  de  premiação  em  caso  de   alcances  sucessivos.   Fonte:  hZp://www.powerlogic.com.br/   Boas  práticas:  Sistema  de  Avaliação  e  Controle  
  53. 53. É  de  extrema  importância  medir  a  efe9vidade  em  relação  à  liberação  de  máximo   valor  de  negócio  a  cada  entrega  efetuada.  Dessa  forma,  deve-­‐se  medir  se  o  PO   está  priorizando  corretamente  as  demandas  de  trabalho  nas  liberações  ao  longo   do  tempo.   Fonte:  hZp://www.powerlogic.com.br/   Boas  práticas:  Sistema  de  Avaliação  e  Controle  
  54. 54. Outro  indicador  também  importante  é  se  obter  o  quão  eficaz  está  sendo  o   dimensionamento  em  tamanho  dos  requisitos.  Dado  os  itens  de  selected  backlog   do  sprint,  comparar  tamanhos  previstos  x  realizados  após  a  reunião  de  Release   Review.   Fonte:  hZp://www.powerlogic.com.br/   Boas  práticas:  Sistema  de  Avaliação  e  Controle  
  55. 55. Dashboard  que   acompanha   diariamente  a   evolução  de   entregas  de  BV  e  de   esforço  restante.   Fonte:  Revista  Visão  Ágil  –  Gestão   Ágil  de  Projetos  com  Scrum  e  FDD  –   Manoel  Pimentel  Medeiros   Exemplo  de  Medição  –  Sprint  Dashboard  
  56. 56. Desafio  6:   VER,  VAL  (Verificação,  Validação)    e  GQA   (Qualidade):  Como  averiguar  a  qualidade  de   produto  e  processo?  
  57. 57. VER  –  Verificação  e  ITP  –  Integração  de  Produto   Fonte:  hZp://www.powerlogic.com.br/  -­‐  SONAR  
  58. 58. GQA  (Garantia  da  Qualidade)  e  VAL  (Validação)   •  GQA:  Atividades  de  auditoria  de  produtos  e   sub-­‐produtos  via  checklists     •  VAL:  Atividades  de  aceitações  finais  de  um   produto  já  verificado,  normalmente   realizadas  pelo  cliente  (PO)  e  usuários  finais   (programas  de  validação).   02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   58  
  59. 59. Fonte:  hZp://www.powerlogic.com.br  
  60. 60. E  por  fim...   q Por  tudo  isso,  o  Scrum  (e  outros  modelos  e  metodologias   ágeis)  não  é  milagreiro.  Quem  contribui,  em  muito,  para  o   sucesso  de  um  projeto,  são  as  pessoas  envolvidas:  sejam   desenvolvedores,  gerentes,  o  corpo  diretor  ou  clientes.   Todos  devem  estar  cientes  do  porquê  utilizar  as  técnicas   citadas  neste  curso:  pair  programming,  peer  review,   comunicação  tácita,  compartilhamento  de  código,   entrega  de  maior  valor  de  negócio,  planejamento   contínuo,  etc.     q Estas  são  somente  algumas  práticas  que  você  pode   aplicar  para  complementar  seu  dia-­‐a-­‐dia  no   gerenciamento  de  projetos.     02/12/14   TOTUM  Consultoria  -­‐   isabella.afonseca@gmail.com   60  
  61. 61. Metodologias  ágeis  e  MPS.BR  –  Aplicação  Prá9ca     Isabella  Fonseca   isabella.afonseca@gmail.com  

×