Transferir como PDF, PPTX
Carregado porEric Cavalcanti
Scrum
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
Mais conteúdo relacionado
Scrum
- 1. Scrum Eric Cavalcanti [email protected] @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
- 4.
- 5.
- 6. BDUF Big DesignUp 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.
- 9.
- 10. Ainda mais... Código Complexo. Manutençãodifí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.
- 12.
- 13. O desenvolvimento desoftware depende muito mais das pessoas e da comunicação
- 14. “Ao contrário docená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 é comocriar uma receita, enquanto produzir é seguir a receita” Poppendieck
- 17. “O desenvolvimento éum processo de aprendizado, que envolve tentativa e erros” Larman
- 18. “Como a manufaturaprevisí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 desenvolvidasnos softwares não são utilizadas Standish Group
- 20. A Lei dePareto, também conhecido como princípio 80/20
- 21. 20% do esforçodo desenvolvimento 80% dos benefícios
- 22. 20% dos custos 80%dos problemas
- 23. Muitas vezes, pelofato do cliente só poder pedir uma vez, ele acaba pedindo coisas que não tem certeza que precisa
- 24. Essas funcionalidades fazem partedos 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
- 26.
- 27. É natural queos usuários tenham novas idéias e suas opiniões mudem quando vêem as primeiras versões do software
- 28. Os softwares maisfamosos 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.
- 35. Final da décadade 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çãoentre eles mais que processos e ferramentas
- 39. Software em funcionamento maisque documentação abrangente
- 40. Colaboração com ocliente mais que negociação de contratos
- 41. Responder a mudançasmais que seguir um plano
- 42. Princípios por trásdo 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 derequisitos, mesmo no fim do desenvolvimento
- 45. Processos ágeis seadequam 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 aoredor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
- 49. O método maiseficiente e eficaz de transmitir informações é através de uma conversa cara a cara.
- 50. Software funcional é a medidaprimária de progresso.
- 51. Processos ágeis promovemum 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 artede maximizar a quantidade de trabalho que não precisou ser feito
- 54. As melhores arquiteturas, requisitose 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.
- 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.
- 65. A origem 1995 Jeff Sutherland Ken Schwaber 1986
- 66. “O Scrum nãovai 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 dosdemais métodos ágeis pela ênfase dada ao gerenciamento do projeto
- 68. Práticas de Engenharia de d c lu t in No
- 69.
- 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 a9 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 Protegeo time Remove impedimentos Guia do Scrum
- 73. Porcos e Galinhas Product Owner Usuários Scrum Master Gerentes Time Marketing
- 74.
- 75. Visão do Produto Umavisã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 avisão!
- 79. Product Backlog Contém valor Retardar decisões
- 80. Product Backlog Umalista de coisas que queremos que sejam entregues
- 81. As funcionalidades são geralmenteescritas 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
- 83.
- 84. O time estimao trabalho associado a cada estória.
- 85. Problemas com estimativas Pessoal, qual a estimativa para essa estória?
- 86. Planning Poker Opinião deEspecialistas Analogia Desagregação Baseado em Fibonacci 1, 2, 3, 5, 8, 13, 20, 40, 100
- 87. Estimando com PlanningPoker Pessoal, qual a estimativa para essa estória?
- 88.
- 89. As estórias sãorankeadas em ordem de importância pelo product owner.
- 90. Business Value Game Novosnegó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
- 94.
- 95. Priorização Business Value / Story Points BV SP BV/SP US3 400 5 80 US1 200 5 40 US2 200 20 10
- 96.
- 97. Sprint Planning capacidade dotime, 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 =
- 98.
- 99.
- 100. Calculando o velocityem uma Sprint BV SP BV/SP US3 400 5 80 US1 200 5 40 US2 200 20 10
- 101. Calculando o velocityem 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 velocityno backlog Sprint 1 Sprint 2 Sprint N Itens de risco
- 104. Quebrando os itensde backlog em tarefas Como cliente, gostaria de poder mudar a data da minha reserva Criar as tarefas
- 105.
- 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.
- 109.
- 110.
- 111. Product Burndown 160 Story Points 120 100 80 1 2 3 4 Sprint
- 112.
- 113.
- 114.
- 115.
- 116. Perguntas? Eric Cavalcanti [email protected] @ericoc