Metodologias ageis

302 visualizações

Publicada em

apresentação rápida sobre os conceitos gerais de agile e scrum feita em 2009(ou 2010 não lembro bem)

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

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

Nenhuma nota no slide

Metodologias ageis

  1. 1. Metodologias ágeisCharles Fortes @CharlesFortes http://www.100loop.com/author/chalk/
  2. 2. Metas para o treinamentoObjetivos• Dar um olhar sobre Metodologias ágeis usando como base o SCRUM
  3. 3. “Projeto” conforme o Dicionário Aurélio: [Do latim. projectu, lançado para diante.]1. Idéia que se forma de executar ou realizar algo, no futuro; plano, intento, desígnio;2. Empreendimento a ser realizado dentro de determinado esquema;
  4. 4. “Um projeto é uma seqüência bem definida de eventos, com um início e um final identificáveis. O foco de um projeto é obter uma meta identificada*.” (Microsoft Press, p. 4, 1998)*Satisfazer a necessidade (vontade) do cliente e obter lucro
  5. 5. Origem!
  6. 6. A partir da Segunda Guerra Mundial, surgiuoficialmente a disciplina de gestão deprojeto pela necessidade de errarmenos, gastar menos e cumprir prazos
  7. 7. “A maioria das nossas suposições sobrenegócios, tecnologia e organizações têm pelomenos 50 anos. Elas tem sobrevivido aoseu tempo. Como resultado, estamospregando, ensinando, e praticando políticasque estão cada vez mais desalinhadas coma realidade, e são contra produtivas.” Peter Drucker (1909-2005)
  8. 8. 31% são cancelados53% custam o dobro do estimadoApenas 16% são completados noprazo e custo estimados * dados do CHAOS report
  9. 9. Por que?
  10. 10. Falta de envolvimento do usuário Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos *MPCM – Maturity by Project Category Model
  11. 11. Errar é uma ótima maneira aprendizado, mas é preciso parar de apontar culpados e começar a agir
  12. 12. Manifesto Ágil
  13. 13. Indivíduos e interaçãoentre eles mais que processos eferramentas
  14. 14. Software Funcionandomais que documentaçãoabrangente
  15. 15. Colaboração mais quenegociação de contratos
  16. 16. Responder àsmudanças mais que seguirum plano http://www.agilemanifesto.org
  17. 17. Scrum!
  18. 18. Scrum é um processo iterativo e incremental paradesenvolvimento de produtos.
  19. 19. O objetivo é entregar omáximo de valor denegócio* possível nomenor tempo * Foco no ROI – Retorno de investimento
  20. 20. Scrum é também um meio de evidenciar os problemas
  21. 21. Mas Scrum não é a soluçãopara todos os seusproblemas* • Exige trabalho duro e comprometimento • Não tem uma receita de bolo de como fazer, mas sim o que fazer
  22. 22. PDCAPlan, Do, Check, Act(Planejamento, Execução, Verificação, Agir para Melhorar)
  23. 23. Ciclo Scrum Fonte: http://www.mountaingoatsoftware.com/scrum
  24. 24. Papéis eResponsabilidades
  25. 25. Scrum tem poucos papéis(não são cargos!): ProductOwner, Team, Scrum Master
  26. 26. Scrum Master
  27. 27. Trabalhar com o Product OwnerCuidar do timeManter o processo funcionandoDisseminar o ScrumGarantir comunicação
  28. 28. Product Owner
  29. 29. Criar e compartilhar umavisão do projeto
  30. 30. Tomar decisõescontinuamente sobre ositens do product backlog
  31. 31. Escrever e priorizar itensde backlog
  32. 32. Validar software no finalde cada Sprint
  33. 33. Estabelecer e manter o plano de entregas
  34. 34. decisõesTomarpensando no ROI doprojeto responsável pelo lucro
  35. 35. Time
  36. 36. Responsabilidades:• Estimar itens do backlog• Se comprometer a entregar um incrementofuncional de software• Gerenciar o próprio progresso• Auto organizados para entregar o que oPO quer
  37. 37. Times Scrum
  38. 38. Como são compostos:• Multidisciplinares• Auto sustentáveis• Todos os skills e habilidades necessárias paradesenvolver o produto • 7pessoas (mais ou menos 2)
  39. 39. Cerimônias de Scrum:• Sprint Planning 1• Sprint Planning 2• Daily Scrum• Sprint Review•Sprint Retrospective
  40. 40. Todas com timebox
  41. 41. Reunião de Estimativa:• Preparação para o Sprint Planning• Estimar baseado notamanho, nunca em tempo• Atualizar Product Backlog com asestimativas• Importante para o PO criar o releaseplan
  42. 42. Sprint Planning 1: Objetivos da product backlog Sprintcapacidade da equipe Revisa Itens selecionados do Considera backlogcondições do negócio Organiza Aceite do time Tecnologia
  43. 43. Sprint Planning 2:• PO não precisa participar• É um planejamento tático da equipe• Os itens selecionados do Product Backlogsão destrinchados em tarefas• Sprint Backlog
  44. 44. Daily Scrum:• Deve responder as três perguntas: • O que fiz desde a ultima Daily Scrum? • O que espero fazer até a próxima Daily Scrum? • O que está impedindo o progresso?• Impedimentos reportados aqui
  45. 45. Sprint Review:• Deve haver um critério para indicar se estápronto!• Incrementos funcionais sãoapresentados ao Product
  46. 46. Consequências do Review:• Estórias não concluídas voltam para oproduct backlog• Atualizar Product Backlog para removeritens que a equipe implementouinadvertidamente• Scrum Master trabalha para reformular aequipe
  47. 47. • Product Backlog é repriorizado paratomar vantagem dos incrementosapresentados• Decidir se haverá ou não outra Sprint
  48. 48. SprintRetrospectives
  49. 49. O queaprendizado não é
  50. 50. Cometer os mesmoserros e esperar resultadosdiferentes
  51. 51. Aprender é evoluir baseado noerro
  52. 52. Passos para aRetrospectiva
  53. 53. Saídas daRetrospectiva:• Team Backlog (para ajustar o processo)• Backlog de impedimentos (mudanças naempresa)• Os backlogs devem ser ordenados porimportância
  54. 54. Quando asretrospectivas nãofuncionam
  55. 55. O facilitador controlademais a reunião
  56. 56. Falta de objetividade, e perda no foco
  57. 57. Conflito de interesses O formato é muito repetitivo O facilitador não se preparaItens de ação mal formulados
  58. 58. Escrevendo Estórias
  59. 59. IndependentesNegociáveisValor paras
  60. 60. áveis Valor para o clienteEstimáveis
  61. 61. EstimáveisSmallTestáveisIndepeno cliente
  62. 62. PequenosTestáveisIndependeneEstimáveis
  63. 63. TestáveisIndependentesNegociávstimáveis
  64. 64. Estimar em tamanhorelativo é mais simples 1 - 2 - 3 - 5 - 8 - 13
  65. 65. Monitorando
  66. 66. 1900ral1900ral1900ral1900ral IDEAL REAL1900ral1900ral1900ral Inicio 05/jan 12/jan 19/jan 26/jan 02/fev 09/fev Fim Sprint Burndown
  67. 67. Problemas comuns
  68. 68. Product Owner pouco presente Sem Visão Sem release plan Sem product backlog
  69. 69. Quando Product Backlog não émantido Falta estimativa Falta priorização Falta acompanhamento
  70. 70. Se as cerimônias não acontecemFalta planejamentoFalta comprometimento para entregasPO pode aceitar itens que não estãoprontos
  71. 71. Sem retrospectivasFalta de uma maneira de melhorar otrabalho do timeMesmos erros acontecem sempreImpedimentos não são removidos
  72. 72. FerramentasNecessárias
  73. 73. Controlar e Monitorar ProductBacklog SprintBacklog Tarefas Qualidade Integrações Versões
  74. 74. @CharlesFortes br.linkedin.com/in/charlesfortes http://www.100loop.com/author/chalk/http://www.100loop.com/author/chalk/

×