Scrum

Introduction to Scrum

Transcript

1. Tiago Silva da Silva Scrum silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva
2. Tiago Silva da Silva Scrum silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva
3. Agenda • Origens • Pilares • Framework Scrum • Papéis • Artefatos • Cerimônias • Desafios
4. Por que utilizar Métodos Ágeis?
7. Origens
8. Origens • Takeuchi, H; Nonaka, I. The new new product development game. Harvard Business Review. P. 137-146, 1986. • Conference on Object Oriented Programming Systems, Languages and Applications, 1995., Austin. Proceedings…Austin: OOPSLA, 1995. • Schwaber, K. Agile project management with Scrum. Redmond: Microsoft, 2004. • Schwaber, K.; Sutherland, J. The Scrum Guide., 2013.
9. Origens • Teorias empíricas de processo, empirismo. • Afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. • Emprega uma abordagem iterativa e incremental.
11. • Transparência • Inspeção • Adaptação Pilares que apóiam o Scrum
12. • Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados Transparência
13. • Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações. Inspeção
14. • Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou material sendo produzido deve ser ajustado. • O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. Adaptação
15. Framework Scrum
16. Framework Scrum • …para apoiar a resolução de problemas complexos em ambientes de alta imprevisibilidade. • Scrum não é o seu processo, mas o framework sobre o qual você empiricamente construirá os seus processos, • você é bem mais habilitado para fazer isso do que outros profissionais que não conhecem a realidade de seu projeto e cultura da sua empresa.
17. Scrum • Papéis • Artefatos • Cerimônias
18. Scrum
19. Scrum Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Product Backlog Vision Release Planning Sprint Planning Retrospective Review Inspection and Adaption Inspection and Adapttion
20. Sprint 24 hours Subset of the PBL Sprint Backlog Product or increment Daily Scrum Product Backlog Release Planning Sprint Planning Retrospective Review Inspection Inspection and Adaption Review if necessary Sprint Zero •  Contracting •  Team forming •  Proof of concepts •  Necessary requirements gathering •  Necessary requirements eliciting Adapt in the next Sprint
21. Papéis
22. Papéis • Product Owner • Team • Scrum Master
23. Papéis • Product Owner • Team • Scrum Master ! • Auto-organizadas • Multifuncionais
24. Product Owner
25. Product Owner • Entende e compartilha a visão do produto • Gerencia e maximiza o ROI • Sabe como priorizar o Product Backlog • Colabora constantemente com o Time e o SM • Planeja releases • Gerencia e poda o Product Backlog
26. Team
27. Team • Auto-organizado • Multidisciplinar • Responsável pela estimativa quanto ao tamanho dos itens do Product Backlog • Está em constante conflito • Compreende o conceito de auto-gerenciamento dentro do contexto técnico de uma Sprint • Ninguém os orienta sobre como transformar o Product Backlog em incrementos de funcionalidades de software pronto.
28. Scrum Master
29. Scrum Master • Remove impedimentos • Verifica se o o Scrum está sendo implementado adequadamente • Facilita as cerimônias • Melhora constantemente suas habilidades de liderança • Líder na questão do processo • Coach o Time e o PO • Para o restante da organização, ele servirá como interface e especialista em Scrum
30. Artefatos
31. Artefatos • Product Backlog • Sprint Backlog • Incremento
32. Product Backlog
33. Product Backlog • DEEP • Detailed appropriately • Estimable • Emergent • Prioritized
34. The Product Backlog Dynamics
35. The Product Backlog Dynamics • Foco na Representação, não na Documentação • Entregável vs. Consumível
36. The Product Backlog Dynamics High priority Low priority At each iteration, the set of higher priority (finer granularity) is selected. At any given moment, items can go up or down in the PBL PBI’s down in the PBL have coarse granularity and must be worked as the Sprints progresses
37. Product Backlog Backlog do Produto: Twitter Login de usuários já cadastrados Cadastrar novo usuário Tweetar Visualizar tweets de quem sigo Visualizar número de seguidores que possuo Visualizar histórico de um tweet Mostrar banner promocional Remover tweet Ver sugestões de usuários a seguir Listar trends Compor e alterar meu perfil de usuário (…)
38. Sprint Backlog
39. Sprint Backlog •  US1: As a client, I need to log into the system in order to edit my data └  T1: Model and design database tables └  T2: Design front-end interface └  T3: Develop communication middleware └  T4: Develop login rules •  US2: As a seller, I want a list of clients to be able to contact them. └  T1: blablabla └  T2: blablabla Sprint Planning Ordered Product Backlog
40. Sprint Backlog Meta da Sprint: usuários poderão estar no twitter Login de usuários já cadastrados Ativar login com usuário Gmail Montar layout do box de login Montar plano de segurança Testar integrado Estruturar log Revisar código Criar comportamento de login Inserir hint explicativo Atualizar documentação técnica (…) Cadastrar novo usuário Criar tabelas no banco de dados Estruturar persistência Definição sobre uso de templates Quando validado, ativar usuário Escrever testes Definir padrões para cadastros Atualizar documentação técnica Validar email cadastrado Testar integrado (…)
41. Incremento • Resultado do que foi produzido durante a sprint • Um dos principais conceitos do Scrum • Vai ao encontro da sua natureza empírica, já que permite ao PO perceber o valor do investimento e também vislumbrar outras possibilidade • Potentially Shippable - Potencialmente Entregável • O cliente pode colocar imediatamente em produção
42. DoD • Definition of Done • Uma funcionalidade somente é considerada pronta se tiver passado por todas as etapas definidas pela Equipe de Desenvolvimento. • Uma funcionalidade que não esteja pronta ao final da Sprint deve retornar ao Product Backlog para que seja incluída em uma próxima Sprint. • Conforme a Equipe amadurece, é esperado que esta DoD se expanda para acomodar mais critérios visando à melhora na qualidade.
43. Cerimônias
44. Cerimônias • Eventos de duração fixa (time-boxed) realizados em intervalos regulares. • Cada um desses eventos é uma oportunidade para Inspeção e Adaptação.
45. Sprint
46. Sprint Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Product Backlog Vision Release Planning Sprint Planning Retrospective Review Inspection and Adaption
47. Sprint • Todo o desenvolvimento em Scrum é feito de forma iterativa e incremental - ciclos completos de desenvolvimento de duração fixa que, ao final, resultem em incrementos potencialmente entregáveis do produto. • Duração de até um mês, o que permite feedbacks constantes. • Sprint Planing, Daily Scrum, Sprint Review e Retrospective.
48. Sprint Planning • O que será entregue no Incremento resultante nesta Sprint? • Como faremos para entregar o Incremento nesta Sprint?
49. Release Planning • Delineamento de entregas para o cliente • Criação do Product Backlog • Análise de Negócios
50. Sprint Planning vs. Release Planning • Sprint Planning acontece para planejar a iteração, logo: • Trabalha com histórias de menor granularidade • Tem um horizonte de planejamento curto • Representa um alto nível de comprometimento • Release Planning acontece para dar respostas ao cliente: • Quando será entregue • Maior granularidade: alto nível de abstração • Grande quantidade de histórias • Geralmente planeja-se 2-3 sprints antecipadamente
51. Daily Scrum Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Product Backlog Vision Release Planning Sprint Planning Retrospective Review Inspection and Adaption
52. Daily Scrum, Daily Meeting • O que fiz desde a última Daily? • O que pretendo fazer até a próxima Daily? • Existe algo me impedindo de concluir alguma tarefa?
53. Sprint Review vs. Retrospective Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Product Backlog Vision Release Planning Sprint Planning Retrospective Review Inspection and Adaption
54. Sprint Review • Entrada é o Produto. • Objetivo é inspecionar o que o Time produziu e colher impressões dos presentes para, caso seja necessário, adaptar o plano para a Sprint seguinte. • PO valida ou não as entregas da Sprint, de acordo com a meta acordada com o Time. • Demonstração • Time responde à perguntas
55. Sprint Retrospective • Entrada é o Processo. • Imediatamente após a Review. • Objetivo é a melhoria do processo • Interação entre os membros do Time • Práticas e ferramentas utilizadas • O que funcionou • O que precisa ser melhorado • Além de identificar problemas, deve-se identificar medidas a serem tomadas para a melhoria do processo já na próxima Sprint.
56. Desafios
57. Desafios • Framework que fornece visibilidade para a equipe e um mecanismo que permite realizar inspeções e adaptações constantes. • Transparência - deixa visíveis os problemas e impedimentos que impactam no PO e na eficiência da equipe. • Não resolve os problemas do desenvolvimento, apenas os deixa visíveis.
58. Desafios • Erro comum: quando se encontra uma prática do framework difícil de aplicar, tenta mudado o próprio Scrum, em vez de mudar a forma como a equipe trabalha. • Equipe com dificuldade de entregar o que foi planejado durante uma Sprint tende a estender seu prazo de duração. • Negando a possibilidade de aprender a melhor estimar e gerenciar seu tempo.
59. Perguntas
60. Perguntas • Sua empresa concorda em mudar o ciclo de vida dos projetos para timboxes de 1-4 semanas? • Sua organização concorda sem problemas em juntar divisões funcionais clássicas como analistas, programadores, testers, arquitetos em um único time? • Sua empresa concorda em abrir mão de hierarquias rígidas tradicionais para uma estrutura mais horizontal? • A liderança concorda em abrir mão do comando e controle, empoderando essa equipe multi-disciplinar a se auto-organizar e auto-gerenciar o trabalho?
61. Perguntas • Escolher um líder-servidor para atuar como ScrumMaster é algo fácil na sua organização ou vai gerar muita discussão? • O papel de Product Owner é facilmente identificável na sua organização? O cliente está “próximo”? • Sua empresa está disposta a uma queda inicial de produtividade devida a curva de aprendizado e a inspeção e adaptação? • Sua empresa está disposta a abrir mão dos atuais mecanismos de controle (custos, prazo, escopo) para adotar a forma ágil de controlar um projeto?
62. Problemas
63. Problemas ! ! • Equipe não dedicada (comprometimento). • Cliente ausente. • Muita interrupção.
64. Problemas • Como fica o planejamento e alinhamento com negócios? • Como a diretoria pode ver? • Por que não precisa de coordenação? • Como mostrar o andamento?
65. Desafios SCRUM+ SCRUM SCRUM+ ...mas essa é a forma do Time B ser mais ágil. SCRUMBUT
66. Tiago Silva da Silva Scrum silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva
67. Conceitos e Técnicas • User Stories • Burndown chart • Acceptance Tests • Story Points
68. User Stories
69. User Stories • Uma descrição informal das necessidades do negócio • São trabalhadas e amadurecem à medida que a análise progride • Uma história pode ser decomposta em duas ou mais histórias • Devem ser testadas e aprovadas • São priorizadas pelo PO de acordo com as necessidades do cliente
70. User Stories Epic blablablabla blabla blablablabla blabla blablablabla blabla Objective Feature Use Case/ User Story Functional requirements Non-functional requirements The relationship between use cases and user stories
71. Burndown
72. Burndown
73. Acceptance Tests
74. Acceptance Tests • Certificam que as stories implementadas correspondem ao que o cliente necessita • Devem ser automatizados, se possível
75. Story Points • Usado para estimar o tamanho de uma Story • Estimativa relativa; 2 story points requerem mais esforço que um story point e, 13 story points requerem muito mais esforço do que um story point • Por que a Sequencia de Fibonacci? • 1 - 3 - 5 - 8 - 13
76. Story Points • Empire State Building, • Teatro Amazonas, • sua casa, • Cristo Redentor, • Torre Eifel
77. Story Points • Empire State Building, • Teatro Amazonas, • sua casa, • Cristo Redentor, • Torre Eifel ! • Estime a altura dos edifícios: • Escolha o menor • Use-o como 1 story point • Estime todos os outros de forma relativa ao primeiro escolhido
78. Referências • Takeuchi, H; Nonaka, I. The new new product development game. Harvard Business Review. P. 137-146, 1986. • Conference on Object Oriented Programming Systems, Languages and Applications, 1995., Austin. Proceedings…Austin: OOPSLA, 1995. • Schwaber, K. Agile project management with Scrum. Redmond: Microsoft, 2004. • Schwaber, K.; Sutherland, J. The Scrum Guide., 2013. • Métodos Ágeis para Desenvolvimento de Software, Organizadores: Rafael Prikladnicki, Renato Willi e Fabiano Milani. Porto Alegre : Bookman., 2014. • Roriz, H. Certified Scrum Master Training (Apostila)., 2012. • Magno, A.. O julgamento do Scrum. Palestra proferida no Agile Brazil 2013.
79. Tiago Silva da Silva Scrum silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva http://www.slideshare.net/silvadasilva http://www.speakerdeck.com/silvadasilva