Scrum

422 visualizações

Publicada em

Scrum

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

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

Nenhuma nota no slide

Scrum

  1. 1. Scrum Tiago Silva da Silva silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva
  2. 2. Scrum Tiago Silva da Silva silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva
  3. 3. Agenda • Origens • Pilares • Framework Scrum • Papéis • Artefatos • Cerimônias • Desafios
  4. 4. Por que utilizar Métodos Ágeis?
  5. 5. Origens
  6. 6. 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.
  7. 7. 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.
  8. 8. Pilares que apóiam o Scrum • Transparência • Inspeção • Adaptação
  9. 9. Transparência • Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados
  10. 10. Inspeção • Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações.
  11. 11. Adaptação • 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.
  12. 12. Framework Scrum
  13. 13. 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.
  14. 14. Scrum • Papéis • Artefatos • Cerimônias
  15. 15. Scrum
  16. 16. Scrum Sprint Inspection and Adapttion 24 hours Sprint Planning Sprint Backlog Tasks Product or increment Daily Scrum Inspection and Adaption Review Retrospective Adapted from Agile Software Development with Scrum by Ken Vision Release Planning Product Backlog Schwaber and Mike Beedle
  17. 17. 24 hours Sprint Subset of the PBL Sprint Backlog Product or increment Daily Scrum Product Backlog Release Planning Sprint Planning Inspection Review Retrospective 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
  18. 18. Papéis
  19. 19. Papéis • Product Owner • Team • Scrum Master
  20. 20. Papéis • Product Owner • Team • Scrum Master ! • Auto-organizadas • Multifuncionais
  21. 21. Product Owner
  22. 22. 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
  23. 23. Team
  24. 24. 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.
  25. 25. Scrum Master
  26. 26. 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
  27. 27. Artefatos
  28. 28. Artefatos • Product Backlog • Sprint Backlog • Incremento
  29. 29. Product Backlog
  30. 30. Product Backlog • DEEP • Detailed appropriately • Estimable • Emergent • Prioritized
  31. 31. The Product Backlog Dynamics
  32. 32. The Product Backlog Dynamics • Foco na Representação, não na Documentação • Entregável vs. Consumível
  33. 33. 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
  34. 34. 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 (…)
  35. 35. Sprint Backlog
  36. 36. 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
  37. 37. 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 (…)
  38. 38. 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
  39. 39. 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.
  40. 40. Cerimônias
  41. 41. 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.
  42. 42. Sprint
  43. 43. Sprint Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Inspection and Adaption Review Vision Adapted from Agile Software Development with Scrum by Ken Product Backlog Schwaber and Mike Beedle Release Planning Sprint Planning Retrospective
  44. 44. 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.
  45. 45. Sprint Planning • O que será entregue no Incremento resultante nesta Sprint? • Como faremos para entregar o Incremento nesta Sprint?
  46. 46. Release Planning • Delineamento de entregas para o cliente • Criação do Product Backlog • Análise de Negócios
  47. 47. 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
  48. 48. Daily Scrum Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Product Backlog Inspection and Adaption Vision Release Planning Sprint Planning Review Retrospective
  49. 49. 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?
  50. 50. Sprint Review vs. Retrospective Sprint 24 hours Sprint Backlog Tasks Product or increment Daily Scrum Product Backlog Inspection and Adaption Vision Release Planning Sprint Planning Review Retrospective
  51. 51. 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
  52. 52. 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.
  53. 53. Desafios
  54. 54. 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.
  55. 55. 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.
  56. 56. Perguntas
  57. 57. 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?
  58. 58. 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?
  59. 59. Problemas
  60. 60. Problemas ! ! • Equipe não dedicada (comprometimento). • Cliente ausente. • Muita interrupção.
  61. 61. 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?
  62. 62. Desafios SCRUM SCRUM+ SCRUM+ ...mas essa é a forma do Time B ser mais ágil. SCRUMBUT
  63. 63. Scrum Tiago Silva da Silva silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva
  64. 64. Conceitos e Técnicas • User Stories • Burndown chart • Acceptance Tests • Story Points
  65. 65. User Stories
  66. 66. 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
  67. 67. 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
  68. 68. Burndown
  69. 69. Burndown
  70. 70. Acceptance Tests
  71. 71. Acceptance Tests • Certificam que as stories implementadas correspondem ao que o cliente necessita • Devem ser automatizados, se possível
  72. 72. 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
  73. 73. Story Points • Empire State Building, • Teatro Amazonas, • sua casa, • Cristo Redentor, • Torre Eifel
  74. 74. 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
  75. 75. 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.
  76. 76. Scrum Tiago Silva da Silva silvadasilva@unifesp.br ! @tiagosdasilva ! silvadasilva@gmail.com ! tiago.silva.da.silva http://www.slideshare.net/silvadasilva http://www.speakerdeck.com/silvadasilva

×