Scrum
9 gostaram744 visualizações
Este documento fornece um resumo conciso sobre Scrum e suas principais características: [1] Scrum é um framework ágil para gestão e desenvolvimento de projetos que enfatiza a colaboração, adaptabilidade e entrega contínua de valor ao cliente. [2] Nos projetos Scrum, as equipes autorganizáveis ("times Scrum") estimam o trabalho, planejam sprints curtas e entregam software funcionando frequentemente para obter feedback do cliente. [3] Os principais papéis no Scrum são o
Scrum
- 1. Scrum Eric Cavalcanti ecavalcanti@gmail.com @ericoc
- 2. O Problema Chaos Report 18% 2004 53% 29% 19% 2006 46% Fracassados 35% Comprometidos Bem sucedidos 24% 2009 44% 32% !"#$%&'(")&*%+,-."/0$12""
- 3. Principais fatores de insucesso requisitos incompletos falta de envolvimento de usuários mudanças de requisitos e especificações falta de apoio de negócios falta de recursos
- 6. BDUF Big Design Up Front
- 7. Analista de Requisitos, Analista de Negócios, Engenheiro de Requisitos, Engenheiro de Qualidade, Gerente de Configuração, Líder de Projeto... Programadores
- 8. Processo!!
- 10. Ainda mais... Código Complexo. Manutenção difícil. Baixa produtividade. Cronograma sempre atrasado. Insatisfação de todos. Design degradado. Documentação defasada, excessiva e ilegível. Fracasso em grande parte dos projetos.
- 11. Por quê?
- 12. Previsibilidade
- 13. O desenvolvimento de software depende muito mais das pessoas e da comunicação
- 14. “Ao contrário do cenário numa linha de produção em massa, o software não é algo previsível ou imune a mudanças” Larman
- 15. “Desenvolver software é como desenvolver novos produtos” Larman
- 16. “Desenvolver é como criar uma receita, enquanto produzir é seguir a receita” Poppendieck
- 17. “O desenvolvimento é um processo de aprendizado, que envolve tentativa e erros” Larman
- 18. “Como a manufatura previsível, não pode ser comparada ao software, dificilmente as práticas e valores enraizados nesse paradigma trazem algum benefício” Larman
- 19. 64% das funcionalidades desenvolvidas nos softwares não são utilizadas Standish Group
- 20. A Lei de Pareto, também conhecido como princípio 80/20
- 21. 20% do esforço do desenvolvimento 80% dos benefícios
- 22. 20% dos custos 80% dos problemas
- 23. Muitas vezes, pelo fato do cliente só poder pedir uma vez, ele acaba pedindo coisas que não tem certeza que precisa
- 24. Essas funcionalidades fazem parte dos 64% que ele nem repara que estão lá, quando o software é entregue
- 25. 70% dos usuários utilizam as funcionalidades básicas de um software. 20% utilizam as funcionalidades intermediárias. 10% utilizam as funcionalidades avançadas. Microsoft
- 27. É natural que os usuários tenham novas idéias e suas opiniões mudem quando vêem as primeiras versões do software
- 28. Os softwares mais famosos e utilizados no mundo são os mais simples
- 32. “Menos é Mais” A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
- 34. Abordagem Ágil
- 35. Final da década de 90 eXtreme Programming Feature Driven Development Scrum Adaptive Development Crystal Clear Dynamic Systems Development Method
- 36. Mas o que é ser ágil?
- 37. Kent Beck Ron Jeffries Mike Beedle Jon Kern Arie van Brian Marick Bennekum Robert C. Martin Alistair Cockburn Steve Mellor Ward Cunningham Ken Schwaber Martin Fowler Jeff Sutherland James Grenning Manifesto Ágil Dave Thomas Jim Highsmith Andrew Hunt
- 38. Indivíduos e interação entre eles mais que processos e ferramentas
- 39. Software em funcionamento mais que documentação abrangente
- 40. Colaboração com o cliente mais que negociação de contratos
- 41. Responder a mudanças mais que seguir um plano
- 42. Princípios por trás do manifesto ágil
- 43. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor
- 44. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento
- 45. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas
- 46. Entregar software funcionando com frequencia, na escala de semanas até meses, com preferência aos períodos mais curtos
- 47. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto
- 48. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
- 49. O método mais eficiente e eficaz de transmitir informações é através de uma conversa cara a cara.
- 50. Software funcional é a medida primária de progresso.
- 51. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
- 52. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
- 53. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito
- 54. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis
- 55. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo
- 56. Por que adotar abordagens ágeis?
- 57. STATE OF AGILE SURVEY 2010 4.770 participantes 91 países VersionOne
- 58. STATE OF AGILE SURVEY 2010 68% conhecem moderadamente ou extremamente 90% trabalham em organizações que usam práticas de desenvolvimento ágil em um certo grau VersionOne
- 59. STATE OF AGILE SURVEY 2010 40% utilizam abordagem ágil a mais de 2 anos VersionOne
- 60. STATE OF AGILE SURVEY 2010 Scrum e variantes de Scrum são de longe os mais utilizados VersionOne
- 61. STATE OF AGILE SURVEY 2010 As razões mais comuns para a adoção ágil gira em torno de aumento produtividade e tempo de aceleração para o mercado VersionOne
- 62. STATE OF AGILE SURVEY 2010 83% consideram que projetos ágeis foram mais rápidos ou a mesma coisa que projetos não ágeis VersionOne
- 63. STATE OF AGILE SURVEY 2010 87% melhoria significante no gerenciamento de prioridades VersionOne
- 64. O Scrum
- 65. A origem 1995 Jeff Sutherland Ken Schwaber 1986
- 66. “O Scrum não vai dizer exatamente o que fazer, não irá resolver todos os seus problemas, mas com certeza os problemas serão mais facilmente identificados” Ken Schwaber
- 67. Se destaca dos demais métodos ágeis pela ênfase dada ao gerenciamento do projeto
- 68. Práticas de Engenharia de d c lu t in No
- 69. Papéis do Scrum
- 70. Product Product Owner Determina a visão do produto Owner Define as funcionalidades Escolhe as datas de release Dá o feedback Gerencia os stakeholders Aceita ou rejeita os resultados Prioriza de acordo com o ROI
- 71. Pequenos (5 a 9 pessoas) Desenvolve as funcionalidades Auto-organizável Auto-gerenciável Multifuncional Estima o esforço Defina as tarefas O Time Responsável pela qualidade
- 72. Scrum Master Líder Servidor Protege o time Remove impedimentos Guia do Scrum
- 73. Porcos e Galinhas Product Owner Usuários Scrum Master Gerentes Time Marketing
- 74. Como funciona?
- 75. Visão do Produto Uma visão é uma imagem clara que evoca uma atração emocional O Product Owner cria a visão do produto Ele compartilha a visão com o time Ele refina a visão com o time
- 76. Product Box http://innovationgames.com/product-box/
- 77. Elevator Statement Para (público alvo) Que estão insa6sfeito com (as atuais alterna6vas de mercado) Nosso produto é um (nova categoria do produto) Que (problema chave que ele resolve) Diferente (o produto alterna6vo) Nós fornecemos (funcionalidades chaves)
- 78. Vamos criar a visão!
- 79. Product Backlog Contém valor Retardar decisões
- 80. Product Backlog Uma lista de coisas que queremos que sejam entregues
- 81. As funcionalidades são geralmente escritas em estórias de usuários.
- 82. Como um <perfil>, quero <funcionalidade>, para <valor de negócio> Como um agente de viagens, quero reservar lugar, para facilitar o atendimento dos clientes corporativos
- 84. O time estima o trabalho associado a cada estória.
- 85. Problemas com estimativas Pessoal, qual a estimativa para essa estória?
- 86. Planning Poker Opinião de Especialistas Analogia Desagregação Baseado em Fibonacci 1, 2, 3, 5, 8, 13, 20, 40, 100
- 87. Estimando com Planning Poker Pessoal, qual a estimativa para essa estória?
- 89. As estórias são rankeadas em ordem de importância pelo product owner.
- 90. Business Value Game Novos negócios Venda Retenção Eficiência Operacional 100, 200, 300, 500, 800, 1200, 2000, 3000
- 91. O product owner é o dono do backlog do produto.
- 92. Roadmap do Produto Mês 1 Mês 2 Mês 3 Release 1 Release 2
- 93. Plano de Releases Release 1 Release 2 Release 3
- 95. Priorização Business Value / Story Points BV SP BV/SP US3 400 5 80 US1 200 5 40 US2 200 20 10
- 96. Product Backlog
- 97. Sprint Planning capacidade do time, backlog do produto, produto atual, condições de negócio, tecnologia + Objetivo da Sprint = Planning 1 priorizar/selecionar os itens de backlog, discutir os critérios de aceitação, verificar o entendimento Planning 2 + quebrar os items de backlog em tarefas, opcionalmente estimar as tarefas Backlog da Sprint =
- 99. Team Velocity
- 100. Calculando o velocity em uma Sprint BV SP BV/SP US3 400 5 80 US1 200 5 40 US2 200 20 10
- 101. Calculando o velocity em uma Sprint BV SP BV/SP US3 400 5 80 US1 200 5 40 US2 200 20 10 Team Velocity = 10
- 102. Team Velocity 90 80 70 70 70 60 40 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
- 103. Aplicando o velocity no backlog Sprint 1 Sprint 2 Sprint N Itens de risco
- 104. Quebrando os itens de backlog em tarefas Como cliente, gostaria de poder mudar a data da minha reserva Criar as tarefas
- 105. Sprint Backlog
- 106. Executando a Sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Código Testa Análise Código Testa Análise Código Testa Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Análise Análise Código Código Código Testa Testa Testa
- 107. Daily Scrum Meeting • O que você fez ontem? • O que você fará de hoje para amanhã? • Há algum impedimento em seu caminho? 15 minutos
- 108. Taskboard
- 109. Acompanhamento
- 110. Sprint Burndown
- 111. Product Burndown 160 Story Points 120 100 80 1 2 3 4 Sprint
- 112. Sprint Review
- 113. Scrum Retrospective
- 114. Revisando...
- 115. Scrum of Scrums
- 116. Perguntas? Eric Cavalcanti ecavalcanti@gmail.com @ericoc