Scrum, O tutorial definitivo

33,479 views

Published on

Este tutorial descreve o Scrum em detalhes, apresentando seus artefatos, papéis, eventos, e regras seguindo o Guia do Scrum.
Também é mostrado um estudo de caso baseado nas práticas do Scrum.

Published in: Technology, Business
12 Comments
97 Likes
Statistics
Notes
No Downloads
Views
Total views
33,479
On SlideShare
0
From Embeds
0
Number of Embeds
11,106
Actions
Shares
0
Downloads
1,280
Comments
12
Likes
97
Embeds 0
No embeds

No notes for slide

Scrum, O tutorial definitivo

  1. 1. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013Rildo Santos (@rildosan)rildo.santos@etecnologia.com.brskype: rildo.f.santoshttp://rildosan.com/(11) 99123-5358(11) 99962-4260www.etcnologia.com.brO TutorialDefinitivoversão 4 | Jun 2013
  2. 2. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 2Programa: “Menos Papel, Mais Árvores ®”Qual é o mundo que queremos ?O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremoster e qual tipo que deixaremos de herança para as próximas gerações.Nossa missão: É buscar pelo equilíbrio do homem, da tecnologia e do meio ambiente.Para cumprir esta missão é necessário: conscientizar, comprometer e AGIR.O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo deestimular o consumo sustentável de papel dentro das organizações.Quer participar ?- Reduza o uso de papel (e de madeira) o máximo possível.- Só imprima se for extremamente necessário.- Evite comprar produtos com excesso de embalagem.- Ao imprimir ou escrever, utilize os dois lados do papel.- Use papel reciclado.
  3. 3. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 3Objetivo:Objetivo:O Scrum é um Método Ágil para execução de qualquer projeto ou trabalho.O Objetivo deste Tutorial é prover conhecimento, apresentar e discutir o SCRUM e suaspráticas aplicadas a projetos de desenvolvimento de software.Pré-requisito:Não há.
  4. 4. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 41 – Desafios do desenvolvimento de Software2 – Sobre o SCRUM3 – Entendendo SCRUM4 – Estudo de CasoConteúdo:
  5. 5. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 5Facilitador: Rildo F. Santos (@rildosan)Coach , Instrutor, Consultor e Palestrante de Métodos Ágeis, Gestão de Negócios, Inovação , Processos eTecnologia .Minha Experiência:Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia deSoftware. Sou formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre emEngenharia de Software pela Universidade Mackenzie.Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).Conheço Métodos Ágeis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado aServiço), Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.Tenho conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos eGRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;Experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Fluência nos principais frameworkse padrões: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999;Participei de diversos projetos nos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, SegurançaPública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java CertifiedInstrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;Sou membro do IIBA-International Institute of Business Analysis (Canada)Onde estou:Twitter: @rildosanBlog: http://rildosan.blogspot.com/Comunidade: http://etecnologia.ning.com
  6. 6. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 61 – Desafios do desenvolvimento de Software2 – Sobre o SCRUM3 – Entendendo SCRUM4 – Estudo de CasoConteúdo:
  7. 7. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 7Objetivo:Parte 1 - Desafios do desenvolvimento de SoftwareObjetivo:Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software.Pré-requisito:Não há.
  8. 8. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 8Desafios do Desenvolvimentode Software
  9. 9. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 9Quanto tempo vai levar ?O tempo é outro grande desafio, é raro(posso até afirmar que não existe) um clienteque diga: “Demore o tempo que for necessário,pois, não temos pressa nenhuma”.Geralmente o cliente quer o software funcionandoPara ontem...Quanto custará ?Todo cliente quer saber quanto custaráo software...O primeiro desafio é conseguir responder qual é ocusto do software e em quanto tempo o cliente vai ter osoftware funcionando.1º. Desafio: Responder ao cliente
  10. 10. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 102º. Desafio: Falha na Comunicação das equipes de TI
  11. 11. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 113º. Desafio: Entender as necessidades dos clientesQuando não se entende as necessidades dos clientes, não se pode entregar valor ao cliente.
  12. 12. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 124º. Desafio: Compreender por que os projetos falham:37% das falhas estãorelacionadas comrequisitosCraig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional(2004)12Informaçãoerrada13%Requisitosincompletos12%Mudança deRequisitos12%Falta deconhecimentotécnico7%Falta decompetência6%Outros50%
  13. 13. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 135º. Desafio: Identificar o que é “necessidade” e o que é “desejo”Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional(2004)13Sempre7% Freqüentemente13%As vezes16%Raramente19%Nunca45%Contudo, amaioria dasfuncionalidadesnunca sãousadas pelosusuáriosUso de funcionalidades do Software
  14. 14. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 14Como aumentar a produtividade da equipede desenvolvimento de software ?6º. Desafio: Aumentar produtividade da equipe de desenvolvimento:Satisfação dos Clientes
  15. 15. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 15Qual é a solução ?Contratar mais desenvolvedores...Mas, será que a contrataçãode novas pessoas garanteo aumento de produtividade ?A falta de produtividade pode afetar o negócioThe Mythical Man Month by Frederick Brooks, 1975*.Quando um projeto está atrasado, contratar novas pessoas para ajudar no projeto pode servir apenaspara atrasá-lo ainda mais.Pois, as novas pessoas precisam primeiro entender o que é projeto, objetivos, escopo,funcionalidades e etc, para depois começar a produzir, ou seja, temos que considerar o tempo queserá gasto com explicações, orientações, comunicação e treinamento das novas pessoas, devemosconsiderar o esforço da gestão de projetos que aumentaráAo calcular o tempo que será necessário para desenvolver um software, temos que adicionar umtempo extra, pois os desenvolvedores precisam de "tempo para pensar“, “tempo para pesquisar” alémdo "tempo para desenvolver""Adicionar novas pessoas a um projeto de software atrasado só adiará a sua entrega." –A Lei de Brooks
  16. 16. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 167º. Desafio: Escolher framework certo para desenvolver software ?CascataRUPSCRUM,Lean,Kanban,XP...
  17. 17. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 178º. Desafio: Como reter os bons profissionais ?Quantas vezes já montamos boas equipe, mas de repente as pessoas começam asair...a trocar de emprego.A retenção de bons profissionais é grande desafio da atualidade, pessoas trocammuito mais de emprego do que a 10 anos atrás.Insegurança, chefes tiranos, a falta de respeito, falta de reconhecimento e de e ambiente“estressante” são as algumas das causas que fazem os profissionais de trocarem deemprego. A maioria das pessoas mudam de emprego por problema com o seu chefe e nãopor motivo de salário.
  18. 18. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 18Por que precisamos dos Métodos Ágeis ?Para enfrentar estes desafios:Utilização de métodos ágeis,como SCRUM, pode amenizarestes problemas.Problemas clássicos (ou tradicionais):Stakeholders (Clientes):- Têm dificuldades em externar suas necessidades- Geralmente fazem mudanças de requisitos- Precisam do software funcionando paraontemDesenvolvedores:- Não sabem ou não querem elicitar requisitos- Dificilmente conseguem atender todas asdemandas de negócio- Tem dificuldade em comunicar e entenderos clientes
  19. 19. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 19Cliente x Desenvolvedores:Clientes:- Alguns clientes têm dificuldades em externarsuas necessidades ou desejos de forma clara e objetiva(Não sabem o que querem)- Geralmente fazem mudanças de requisitos durante odesenvolvimento ou quando o software é entregue.- Sempre precisam do software funcionando para ontem- Não têm tempo e nem paciência para falar com osdesenvolvedores.Desenvolvedores:- Não sabem ou não querem conversar com o cliente- Dificilmente conseguem atender o negócio e todas suasdemandas- Têm dificuldade em se comunicar e entender os clientes
  20. 20. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 20Como enfrentar estes desafios: “O SCRUM é sua sogra”O SCRUM pode ser uma forma para enfrentar estes desafios, O SCRUM não vaiaumentar a produtividade da equipe, não vai fazer você entregar software mais cedo,nem melhorar a qualidade do software e nem otimizar os custos do projeto dedesenvolvimento.O “SCRUM é como sua SOGRA” ele vai apontar os principais problemas, falhas e pontoscríticos (riscos) do projeto de desenvolvimento, aquilo que realmente precisa sermelhorado, mas se as pessoas envolvidas com o projeto não tomarem nenhuma ação (oumelhor: tomarem atitudes) os problemas continuaram a existir e levaram a maioria dosprojetos para a “marcha da morte”.O Scrum vai deixar todos os problemas aparentes.
  21. 21. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 211 – Desafios do desenvolvimento de Software2 – Sobre o SCRUM3 – Entendendo SCRUM4 – Estudo de CasoConteúdo:
  22. 22. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 22Objetivo:Parte 2 – Sobre SCRUM:Objetivo:Apresentar Manifesto Ágil e o SCRUM, as principais características e práticas.Pré-requisito:Não há.
  23. 23. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 23Sobre o SCRUMParte 2
  24. 24. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201324As Raízes do Scrum:Artigo: “The New, NewProduct Development Gamede Nonaka e Takeushi naHardvard Bussines ReviewTimeBoxesSmallTalkEngineering ToolsDesenvolvimentoiterativo eincrementalSprintBacklogProduto2-4 Semanas24 horasProdutoBacklogReuniãodiária
  25. 25. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 25O que é TimeBox ?É duração fixa (imutável).É um conceito diz que a quantidade de tempo é imutável, ou seja, tem duraçãofixa - a quantidade de dias não poderá aumentar. Assim, evita-se atrasos no prazode entrega e facilita o planejamento.No Scrum as cerimônias e/ou eventos com duração fixa (Time-Boxes) são:- Reunião de Planejamento da Release,- Sprint (iteração),- Reunião de Planejamento da Sprint,- Revisão da Sprint.- Retrospectiva da Sprint.- Reunião Diária.Exemplos de Timebox:A Sprint (que é uma iteração) que deve ser realizada de 2 a 4 semanas, no qual aequipe de desenvolvedores deverá produzir um entregável de valor para o cliente(mais frente discutiremos melhor isto).A entrega de valor é a meta da Sprint, a duração da Sprint deverá ser combinadacom o cliente, antes do começo da execução da Sprint.Se foi acertado que a Sprint tem a duração de 4 semanas, logo esta duraçãoserá fixa (não mudará).Durante a Sprint são realizadas as Reuniões Diárias, uma reunião diária tem aduração fixa de 15 minutos.Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprintsde um mês, essa é uma reunião com duração fixa de quatro horas.Após a Revisão da Sprint e antes da próxima Reunião de Planejamentoda Sprint, a Equipe Scrum tem a Reunião de Retrospectiva da Sprint.essa reunião, te duração fixa de três horas.
  26. 26. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 26Abordagem Iterativo e Incremental:Devido a complexidade, tamanho, mudanças de requisitos,urgência e necessidade de demonstrar valor mais rápido, ficaquase inconcebível desenvolver software utilizando o modelocascata, ou seja, desenvolver todo o software em uma únicavez.Desenvolvimento Iterativo e incremental é uma estratégia deplanejamento (que segue a linha dividir para conquistar) ,onde o software é construído em partes, ou seja, em ciclos(iterações), a cada iteração é feito um novo incremento (umaparte do software funcional) até completar o software.IncrementalEntrega 1 Entrega 2 Entrega 3Iterativo
  27. 27. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201327O qual é propósito do SCRUM ?Scrum vem sendo utilizado para o desenvolvimento deprodutos complexos desde o início dos anos 90.Scrum não é um “processo “ ou uma “técnica “ para odesenvolvimento de produtos.Ao invés disso, é um framework dentro do qual você podeempregar diversos processos e técnicas. O papel do Scrum éfazer transparecer a eficácia relativa das suas práticas dedesenvolvimento para que você possa melhorá-las, enquantoprovê um framework dentro do qual produtos complexospodem ser desenvolvidos.Por ser um framework, o SCRUM não é uma ferramenta, nemmetodologia, nem processo e nem uma solução completa para odesenvolvimento de software, ele é um framework (uma estrutura),ou seja um “guia de referência” , isto significa que o “Scrum nãovai lhe dizer como fazer as coisas! “Por ser um framework, ele pode ser utilizado com as práticas deengenharia de software e/ou metodologia de desenvolvimento que jáexistem dentro da organização.O SCRUM pode ser utilizado para desenvolver qualquer produto enão só software.
  28. 28. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201328Qual é a teoria do SCRUM ?A TEORIA DO SCRUM:Scrum, que é fundamentado na teoria de controle de processos empíricos*, emprega umaabordagem iterativa e incremental para otimizar a previsibilidade e controlar riscosProcesso Definido:São processos que se conhece todas as variáveis, têm poucas ou nenhumamudança ao logo do processo, são repetitivos e são previsíveis.Geralmente existe uma documentação aplicada a execução do processo.Exemplo: Linha de produção*Processos Empíricos:São aqueles processos que não se conhece todas as variáveis, têmmudanças ao logo do processo, não são repetitivos e são imprevisíveis.Geralmente baseado na experiência e no conhecimento de quem executa oprocesso.Exemplo: Desenvolvimento de Software.Quando desenvolvemos um software as vezes não conhecemos todos osrequisitos, e os requisitos que são conhecidos mudam com certa frequênciae geralmente todas as estimavas são feitas baseada no conhecimento daspessoas, isto quer dizer, que o mesmo trabalho feito por equipes diferentesa duração pode variar, pois, a equipe mais experiente deve realizar otrabalho mais rápido do que a equipe menos experiente. Isso porque odesenvolvimento de software é um problema complexo, que se comporta deforma imprevisível.O que são processos empíricos ?Antes de responder a pergunta, precisamos saber que existem dois tipos de processos:
  29. 29. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201329Os pilares do SCRUM:Três pilares sustentam qualquer implementação de controle de processos empíricos.
  30. 30. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201330Os pilares do SCRUM:Três pilares sustentam qualquer implementação de controle de processos empíricos.O primeiro pilar:A transparência garante que aspectosdo processo que afetam o resultadodevem ser visíveis para aqueles quegerenciam os resultados.Esses aspectos não apenas devem sertransparentes, mas também o que estásendo visto deve ser conhecido.Isto é, quando alguém que inspecionaum processo acredita que algo está“pronto”, isso deve ser equivalente àdefinição de “pronto” utilizada.O segundo pilar:Os diversos aspectos do processo devem ser inspecionados com uma frequência suficientepara que variações inaceitáveis no processo possam ser detectadas. A frequência dainspeção deve levar em consideração que qualquer processo é modificado pelo próprioato da inspeção. O problema acontece quando a frequência de inspeção necessáriaexcede a tolerância do processo à inspeção. Os outros fatores são a habilidade e aaplicação das pessoas em inspecionar os resultados do trabalho.
  31. 31. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201331Os pilares do SCRUM:Três pilares sustentam qualquer implementação de controle de processos empíricos.O terceiro pilar:Se o “inspetor” determinar, a partir dainspeção, que um ou mais aspectos doprocesso estão fora dos limites aceitáveis eque o produto resultante será inaceitável, eledeverá ajustar o processo ou o materialsendo processado. Esse ajuste deve serfeito o mais rápido possível para minimizardesvios posteriores.Existem três pontos para inspeção eadaptação em Scrum. A Reunião Diária (2) éutilizada para inspecionar o progresso emdireção à Meta da Sprint e para realizaradaptações que otimizem o valor do próximodia de trabalho. Além disso, as reuniões deRevisão da Sprint (3) e de Planejamento daSprint (1) são utilizadas para inspecionar oprogresso em direção à Meta da Release epara fazer as adaptações que otimizem ovalor da próxima Sprint.E a Retrospectiva da Sprint (4) é utilizadapara revisar a Sprint passada e estabelecerque adaptações tornarão a próxima Sprintmais eficiente, produtiva, recompensadora egratificante.21 34
  32. 32. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 32O Manifesto Ágil:Fonte: http://agilemanifesto.org/iso/ptbr/O SCRUM é um Metodo Ágil
  33. 33. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 33Princípios por trás do Manifesto Ágil:Nós seguimos estes princípios: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software comvalor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência àmenor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimentoé através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constanteindefinidamente. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade -- a arte de maximizar a quantidade de trabalho não realizado -- é essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seucomportamento de acordo.
  34. 34. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 34Como Ser Ágil ?Como ser ágil ?1 - Para “ser ágil” é preciso colocar em prática os valores e os princípios do Manifesto Ágil.Exemplo:Se uma organização implementou o SCRUM e aparentemente tudo ocorre bem...mas, se equipe nãoestá conseguindo entregar “software funcionando” ao cliente a quatro meses, podemos afirmar queexiste uma equipe ágil ?Vejamos o que diz o Manifesto Ágil:“Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferênciaà menor escala de tempo.”Podemos concluir que a equipe não é ágil, pois além da implementação do SCRUM, que é ummétodo ágil, ela também deverá levar em conta os valores e princípios do Manifesto Ágil, ou seja,entregar software funcionando com certa regularidade.
  35. 35. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 35Como Ser Ágil ?Como ser ágil ?2 – Além de implementar o SCRUM para Gestão de Projetos de desenvolvimento de softwaretambém adote práticas de Engenharia de Software Ágil, tais como XP e FDD.
  36. 36. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 36Engenharia de Software 100% “Ágil:O SCRUM é utilizado para Gestão de Projetos. Já para as práticas deEngenharia de Software podemos utilizar o FDD para os requisitos desoftware e arquitetura e as Práticas do XP para o desenvolvimento desoftware (codificação, testes e refactoring).Como Ser Ágil ?
  37. 37. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 37Método de Gestão de Projetos Tradicionais.- Não tem auto gestão.- Não são auto-organizadas.- São fortemente hierarquizada. Com liderançabaseada no “comando-controle”.- Equipe formada por especialistas.Equipe: Tradicional x Colaborativaauto GestãoTradicionalA auto gestão: Requer alto comprometimento daequipe, que é a chave para a produtividade. Equipemotivada produz mais e melhor.O Comando-controle: Pode levar ao baixocomprometimento e desmotivação é sinônimo debaixa produtividade e produtos de baixa qualidade.Existem alguns tipos de equipe, vamos comparar o formato Tradicional e de auto Gestão:Como ser ágil ?3 – Para trabalhar como o SCRUM é preciso trabalhar em equipe:Método Ágil- ter auto gestão,- ser Auto organizada;- ser Interdisciplinar- não ter Hierarquia formal,- ter responsabilidade.
  38. 38. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 38As Características da Equipe:Interdisciplinares e Sem hierarquia formal:Equipes também são interdisciplinares: os membros da equipe devem ter todo o conhecimento ehabilidades necessárias para entregar a meta da Sprint.Membros da equipe geralmente possuem conhecimentos especializados, tais como: programação,testes, controle de qualidade, análise de negócios, arquitetura, desenho de interface de usuário emodelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto é, ahabilidade de trabalhar um item do Product Backlog (ou um requisito) e transformá-lo em um produto(software funcionando) tendem a ser mais significativas do que aqueles que eles não dividem.As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem aequipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se deantigas. Na equipe não há hierarquia nem títulos, todos são iguais e não há exceções a essa regra. Asequipes também não devem ter sub-equipe dedicados a áreas particulares como testes, banco dedados ou análise de negócios.Como ser ágil ?3 – Para trabalhar como o SCRUM é preciso trabalhar em equipe:Auto Gestão e Auto-organização:A equipe possui a auto gestão e é auto-organizada. Não deve haverinterferência externa, nem o ScrumMaster ou Product Owner - pode dizercomo a equipe deve se organizar ou fazer inferência na forma de trabalho daequipe. A equipe deve ser capaz de se auto-organizar para dividir e fazertrabalho.Equipe de desenvolvedores é muito parecida com um equipe de Volley Ball,onde todos tem um único objetivo e são interdisciplinares no jogo.Responsabilidade:A equipe de desenvolvedores é responsável transformar os itens do Product Backlog emfuncionalidades potencialmente entregáveis a cada Sprint.
  39. 39. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 39Reforçando: “Não existe a Bala de Prata”SCRUM não é a Bala de Prata:O SCRUM não é a solução completa para osproblemas de produtividade, complexidade,custo, prazo e qualidade do processo dedesenvolvimento de software.“Não existe solução mágica para problemas complexos”Contudo, você pode utilizar o SCRUM para:- SCRUM é ideal para desenvolvimento de software complexos onde os requisitos mudam rapidamente;- SCRUM é método ágil para gerenciar e controlar desenvolvimento de trabalho;- SCRUM possibilita que você utilize as praticas de engenharia existentes e que já são conhecidas;- SCRUM é baseado na abordagem interativa e incremental;- Equipe de desenvolvedores (ou time) deve ter auto gestão;- SCRUM é o caminho para detectar e causa raiz e a remoção de qualquer coisa que esteja impedindo odesenvolvimento e/ou entrega de software/produtos;- SCRUM é o caminho para maximizar a produtividade;- SCRUM vai dá transparência ao processo de desenvolvimento de software.Veja Lei F. Brooks, Não existe bala de prata
  40. 40. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 40Algumas empresas que estão usando SCRUM:Quais empresas estão utilizando oSCRUM?Algumas empresas brasileiras
  41. 41. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 201341ExercícioLeia o texto e complete a lacuna (no último paragrafo):O processo de captação de talentos no futebol:Baseado no texto do Fabrício Moreira*Um dos aspectos mais importantes dos grandes clubes de futebol está relacionado à captação detalentos para compor suas categorias de base, e posteriormente formar esses atletas para ingressaremno profissional. Para entendermos melhor os caminhos atualmente traçados por esses candidatos afuturos atletas de futebol precisamos analisar as formas que costumam chegar esses garotos até osclubes brasileiros e iniciar os seus treinamentos junto às equipes de base.Considerando que hoje esse processo de detecção difere em muito daqueles praticados anteriormente,e que cada vez mais, tem se tornado precoce e competitivo, em que a concorrência chega a serabsurda. Se pudéssemos ter acesso aos números de garotos avaliados anualmente nos grandes clubesem relação aos selecionados, chegaríamos certamente a esta conclusão.O objetivo deste texto é relatar os diversos mecanismos de captação de talentos em prática nos grandesclubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e doissecundários. Podemos destacar alguns dos principais: as avaliações “peneiras”; campeonatos e jogosamistosos; indicações; escolas licenciadas “franquias” e os observadores técnicos. Entre assecundárias, destacamos: as clínicas de futebol e o intercâmbio internacional.As chamadas “peneiras” são um dos mecanismos mais conhecidos e utilizados no meio do futebol.Porém, é um processo ___________________, baseado na observação dos treinadores em uma únicasituação (muitas vezes apenas de jogo e de curta duração). Neste caso, muitos clubes pré-selecionamalguns garotos para continuarem os testes por pelo menos uma semana no clube, ou mais um dia, nomínimo.http://www.universidadedofutebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO+DE+CAPTACAO+DE+TALENTOS+NO+FUTEBOL.aspx?p=1
  42. 42. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 421 – Desafios do desenvolvimento de Software2 – Sobre o SCRUM3 – Entendendo SCRUM4 – Estudo de CasoConteúdo:
  43. 43. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 43Objetivo:Parte 3 – Entendendo SCRUMObjetivo:Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum.Pré-requisito:Não há.
  44. 44. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 44Entendendo o SCRUMParte 3
  45. 45. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013Framework Scrum:ArtefatosSprintBacklogProdutoPlanejamentoda SprintReuniãodiária2-4 Semanas24 horasRevisãoda SprintRetrospectivada SprintVisãoReuniõesProductBacklogLegenda:• Product Owner (PO)• ScrumMaster (SM)• Equipe Scrum• Product Backlog• Sprint Backlog• Sprint BurndownPapéisEventos (Reuniões)ArtefatosScrum é um framework para desenvolver e manter produtos complexos. Um framework dentro do qualpessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamenteentregam produtos com o mais alto valor possível. Scrum é: Leve, Simples de entender e Extremamentedifícil de dominar Planejamento da Sprint Diária Revisão da Sprint Retrospectiva da SprintO framework Scrum consiste nas equipes do Scrum associadas a papéis, eventos, artefatos e regras.Cada componente dentro do framework serve a um propósito específico e é essencial para o uso esucesso do Scrum.45
  46. 46. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 46Framework Scrum: Eventos de Duração Fixa:Regras
  47. 47. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 47As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e osartefatos do Scrum. As regras são descritas ao longo desta apresentação.Alguns exemplos de Regras:- Somente os membros da equipe de desenvolvimento podem falar durante uma Reunião Diária.- Equipe deve possuir auto-gestão.;- Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog.- Uma pessoa não pode desempenhar o papel de PO e de Scrum Master no mesmo projeto.- Somente o PO pode cancelar uma Sprint.Framework Scrum: Regras
  48. 48. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 48Framework Scrum: Papéis e EquipePapéis e Equipe
  49. 49. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 49Papéis SCRUM:Product Owner (PO), que é responsável por maximizar o valor dotrabalho que a equipe faz, PO também é responsável por:- Definir a Visão do Produto- Elaborar , Priorizar e manter o Product Backlog- Definir ROI;- Representar o cliente- Aceitar ou rejeitar os entregáveisA equipe (ou time), é responsável pelo desenvolvimento do produto, éformada por desenvolvedores que devem ter as habilidades necessáriaspara transformar os itens do Product Backlog em Produto.A Equipe ainda é responsável por:- Fazer estimativa;- Definir as tarefas;- Garantir a qualidade do produto;- Apresentar o produto ao clienteO ScrumMaster, que é responsável por garantirque o processo (as práticas do SCRUM) sejacompreendido e seguido. É responsável ainda por:- Remover impedimentos;- Proteger a equipe;- Ajudar o PO (quando necessário);- Ser o facilitador da equipe.Equipe Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada equipe possui três papéis:
  50. 50. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 50A Equipe SCRUM: ScrumMaster (SM) e Product Owner (PO):O ScrumMaster é responsável por garantir que o Equipe Scrum esteja aderindoaos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda a EquipeScrum e a organização a adotarem o Scrum.O ScrumMaster educa a Equipe Scrum treinando-o e levando-o a ser mais produtivoe a desenvolver produtos de maior qualidade. O ScrumMaster ajuda a EquipeScrum a entender e usar auto-gerenciamento e interdisciplinaridade.O ScrumMaster também auxiliar a equipe a fazer o seu melhor em um ambienteorganizacional que pode ainda não ser otimizado para o desenvolvimento deprodutos complexos.Quando o ScrumMaster ajuda a realizar essas mudanças, isso é chamado de“remoção de impedimentos”. No entanto, o ScrumMaster não gerencia a EquipeScrum; a Equipe Scrum é auto-organizável.O Product Owner (PO) é a única pessoa responsável pelo gerenciamento doProduct Backlog e por garantir o valor do trabalho realizado pela Equipe.O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos.Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em quese irá trabalhar.O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitêsque aconselhem ou influenciem , mas somente o PO poderá mudar a prioridade deum item do PB. Empresas que adotam Scrum podem perceber que isso influenciaseus métodos para definir prioridades e requisitos ao longo do tempo.Para que o PO obtenha sucesso, todos na organização precisam respeitar suasdecisões. Somente o PO pode definir a prioridade dos itens que a equipe irátrabalhar.As decisões do Product Owner são visíveis no conteúdo e na priorização do ProductBacklog. Essa visibilidade requer que o Product Owner faça seu melhor,o que faz o papel de “Product Owner “ exigente e recompensador ao mesmotempo.
  51. 51. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 51A Equipe SCRUM: A EquipeA Equipe (time) de desenvolvedores transformam o Product Backlog em incrementosde funcionalidades potencialmente entregáveis em cada Sprint.A equipe deve ser formada por pessoas “comprometidas” em atingir as metas dasSprints .A equipe deve ser interdisciplinar: os membros da equipe devem ter todo oconhecimento e habilidades necessárias para entregar a meta da Sprint.Membros da equipe geralmente possuem conhecimentos especializados, tais como:programação, testes, controle de qualidade, análise de negócios, arquitetura,desenho de interface de usuário e modelagem de dados. No entanto, oconhecimento que os membros devem compartilhar - isto é, a habilidade detrabalhar um item do Product Backlog (ou um requisito) e transformá-lo em umproduto (software funcionando) tendem a ser mais significativas do que aqueles queeles não dividem.As pessoas que se recusam a programar porque são arquitetas ou designers nãose adaptam bem a equipe. Todos devem contribuir, mesmo que isso exijaaprender novas habilidades ou lembrar-se de antigas. Na equipe não há hierarquianem títulos, todos são iguais e não há exceções a essa regra. As equipes tambémnão devem ter sub-equipe dedicados a áreas particulares como testes, banco dedados ou análise de negócios.A equipe possui a auto gestão e é auto-organizada. Não deve haver interferênciaexterna, nem o ScrumMaster ou Product Owner – ninguém pode dizer como a equipedeve se organizar ou fazer inferência na forma de trabalho da equipe. A equipe deveser capaz de se auto-organizar para dividir e fazer trabalho. A equipe deve ser auto-suficiente, cada membro da equipe aplica sua especialidade a todos os problemas.A sinergia que resulta disso melhora a eficiência e eficácia geral da equipe comoum todo.
  52. 52. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 52Equipe: Comprometimento e Tamanho:Product OnwerEquipe SCRUM MasterComprometidosEnvolvidosStakeholders(clientes e usuários finais)O tamanho ótimo para uma equipe é de 7 pessoas, mais ou menos duas pessoas. Quando hámenos do que cinco membros em uma equipe, há menor interação e, como resultado, há menorganho de produtividade. Mais do que isso, a equipe poderá encontrar limitações de conhecimentodurante partes da Sprint e não ser capaz de entregar uma parte “pronta” do produto. Se há mais doque 9 membros, há simplesmente a necessidade de muita coordenação. Equipe grandes gerammuita complexidade para que um processo empírico consiga gerenciar. Contudo, temos encontradoalgumas equipes bem-sucedidas que excederam os limites superior e inferior dessa faixa de tamanhos.O PO e o ScrumMaster não estão incluídos nessa conta, a menos que também sejam porcos. Acomposição da equipe pode mudar ao final da Sprint. Toda vez que a equipe muda, a produtividadeganha através da auto-organização é reduzida. Deve-se tomar cuidado ao mudar a composição daequipe.
  53. 53. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 53Framework Scrum: Eventos de Duração Fixa:Eventos
  54. 54. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 54Eventos com duração fixa (time-boxes) :Os eventos com duração fixa são utilizados para criar para criar regularidade, os seguintes eventostêm a duração fixa:- Reunião de Planejamento da Release- Reunião de Planejamento da Sprint,- Sprint,- Reunião Diária,- Revisão da Sprint- Retrospectiva da Sprint.Eventos:Visão GeralReuniãoDiáriaProduct BacklogProdutoSprint BacklogSprintA Sprint:Parte central, ou o coração do Scrum, é a Sprint, que é uma iteração de um mês ou menos, deduração consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmomodelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que épotencialmente entregável. Cada Sprint começa imediatamente após a anterior.
  55. 55. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 55REUNIÃO DE PLANEJAMENTO DA RELEASEO propósito do planejamento da release é o de estabelecer um plano e metas que a equipe Scrum e oresto da organização possam entender e comunicar. O planejamento da release responde àsquestões:- “Como podemos transformar a visão em um produto vencedor da melhor maneirapossível?- “Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobreInvestimento (ROI) desejados?”O Plano da Release, que é o artefato resultante dessa reunião, estabelece a meta da release, asmaiores prioridades do Product Backlog, os principais riscos e as características gerais efuncionalidades que estarão contidas na release. Ele estabelece também uma data de entrega ecusto prováveis que devem se manter se nada mudar. A organização pode então inspecionar oprogresso e fazer mudanças nesse plano da release a cada Sprint.O planejamento da release é opcional. Contudo, se a equipe Scrum iniciar o trabalho sem essareunião, a ausência de seu artefato aparecerá como um impedimento que deverá ser resolvido.O trabalho para resolver o impedimento se tornará um item do Product Backlog.Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint criaum incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vãoadicionando incrementos ao produto. Cada incremento é um “pedaço” potencialmente entregável doproduto completo. Quando já tiverem sido criados incrementos suficientes para que o produto tenhavalor e uso para seus investidores, o produto é entregue.Muitas organizações já possuem um processo de planejamento de release, e na maior partedesses processos o planejamento é feito no início do trabalho da release e não é modificado como passar do tempo.Framework Scrum: Eventos de Duração Fixa:
  56. 56. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 56REUNIÃO DE PLANEJAMENTO DA RELEASE (continuação)No planejamento de release do Scrum, são definidos uma meta geral e resultados prováveis. Esseplanejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumavautilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realizaplanejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamentode Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cadaReunião Diária. De forma geral, os esforços para uma release com Scrum provavelmente consomemligeiramente mais esforço do que os esforços para um planejamento de release tradicional.O planejamento da release requer estimar e priorizar o Product Backlog para a release. Hádiversas técnicas para fazê-lo que estão fora do alcance do Scrum, mas que apesar disso são úteisquando usadas com ele.Framework Scrum: Eventos de Duração Fixa:Artefato resultante dessa reunião: Plano de Release1 2 3 4 5 6Plano de Release do ProdutoSprint #Release #1 Release #2 Release #3Release BurnDownVisão doPlanejamentoRelease #ProductBacklogVisão do Produto
  57. 57. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 57Framework Scrum: Eventos de Duração Fixa:SprintBacklogProdutoPlanejamentoda SprintReuniãodiária24 horasRevisãoda SprintRetrospectivada SprintVisão ProdutoBacklogSprint2-4 Semanas
  58. 58. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 58Framework Scrum: Eventos de Duração Fixa:REUNIÃO DE PLANEJAMENTO DA SPRINTA Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. É fixada em oitohoras de duração para uma Sprint de um mês. Para Sprints mais curtas, aloca-se para essareunião aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeiraparte, um evento com duração fixa de 4 horas, é o momento no qual é decidido “o quê” será feitona Sprint. A segunda parte, também é um evento com duração fixa de 4 horas, é o momento noqual a equipe entende “como” desenvolverá essa funcionalidade em um incremento do produtodurante a Sprint.Na 1º a equipe Scrum trata da questão: “o quê?”.O Product Owner apresenta a equipe o que é mais prioritário no Product Backlog.Eles trabalham em conjunto para definir qual funcionalidade deverá ser desenvolvida durante apróxima Sprint. As entradas para essa reunião são o Product Back, o incremento mais recente aoproduto, a capacidade da equipe e o histórico de desempenho da equipe.Cabe somente a equipe a decisão de quanto itens do Product Backlog ela deve selecionar.Somente a Equipe pode avaliar o que ele é capaz de realizar na próxima Sprint.Meta da Sprint:Uma vez selecionado o Product Backlog , a Meta da Sprint é delineada. A Meta da Sprint é oobjetivo que será atingido através da implementação do Product Backlog. Ela é uma descrição quefornece orientação a equipe sobre a razão pela qual ele está desenvolvendo o incremento. AMeta da Sprint é um subconjunto da Meta da Release.O motivo para se ter uma Meta da Sprint é dar a equipe alguma margem com relação à funcionalidade.Por exemplo, a meta para a Sprint acima poderia também ser: “Automatizar a funcionalidade demodificação de conta de clientes através de um “middleware” seguro capaz de recuperar transações.”Conforme a equipe trabalha, ela mantém a meta em mente. Para satisfazer a meta, elaa implementa afuncionalidade e a tecnologia.Se o trabalho se mostrar mais difícil do que a equipe esperava, a equipe então irá colaborarcom o Product Owner e implementar a funcionalidade apenas parcialmente.
  59. 59. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 59Framework Scrum: Eventos de Duração Fixa:REUNIÃO DE PLANEJAMENTO DA SPRINT (Continuação):Na segunda parte da Reunião de Planejamento da Sprint, a equipe trata a questão:“como?”.Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, a equipedefine como transformará o Backlog do Produto selecionado durante a Reunião dePlanejamento (o quê) em um incremento pronto. A equipe geralmente começaprojetando o trabalho. Enquanto projeta, a equipe identifica tarefas. Essas tarefassão “pedaços” detalhados do trabalho necessário para converter os itens do ProductBacklog em software funcional. As tarefas devem ser decompostas para quepossam ser feitas em menos de um dia. Essa lista de tarefas é chamada de SprintBacklog que é um artefato do SCRUM. A equipe se auto-organiza para se encarregare se responsabilizar pelo trabalho contido na Sprint Backlog , tanto durante a Reuniãode Planejamento da Sprint quanto no próprio momento da execução da Sprint.O Product Owner está presente durante a segunda parte da Reunião dePlanejamento da Sprint para esclarecer o Product Backlog e para ajudar aefetuar trocas. Se a equipe concluir que ele tem trabalho demais ou de menos,ele pode renegociar os itens do Product Backlog escolhido com o Product Owner.A equipe também pode convidar outras pessoas , tais como clientes finais e/ouespecialista de negócio, a participarem da reunião para fornecerem conselhostécnicos ou sobre o domínio em questão.Geralmente, uma equipe nova percebe pela primeira vez se irá ganhar ou perdercomo uma equipe - não individualmente - nessa reunião. A equipe percebe quedeve contar consigo mesmo. Conforme ele percebe isso, ele começa a se auto-organizar para assumir as características e comportamento de uma verdadeiroequipe.Artefato resultante dessa reunião: Sprint BacklogIncluir novoclientealterarclienteconsultarclienteFazer TestesUnitáriosSprint BacklogFazer UIFazer asTabelas
  60. 60. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 60Framework Scrum: Eventos de Duração Fixa:SprintBacklogProdutoPlanejamentoda SprintReuniãodiáriaSprint2-4 Semanas24 horasRevisãoda SprintRetrospectivada SprintVisão ProdutoBacklog
  61. 61. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 61Framework Scrum: Eventos de Duração Fixa:A SPRINTA Sprint é uma iteração. Sprints são eventos com duração fixa. Durante a Sprint, o ScrumMastergarante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composiçãoda equipe quanto as metas de qualidade devem permanecer constantes durante a Sprint. AsSprints contêm e consistem na reunião de Planejamento de Sprint, o trabalho dedesenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma apósa outra, sem intervalos entre elas.Um projeto serve para cumprir alguma função. Em desenvolvimento de software, o projeto éutilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definição doque será desenvolvido, um plano para desenvolvê-lo, o trabalho realizado de acordo com oplano e o produto resultante. Cada projeto possui um horizonte, que é o período de tempo parao qual o plano é válido. Se o horizonte for longo demais, a definição poderá ter mudado, variáveisdemais poderão ter surgido, o risco poderá ser grande demais etc. Scrum é um framework paraprojetos cujo horizonte não é superior ao período de um mês, onde já há complexidade suficiente talque um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve sercontrolada pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torneimprevisível é contido pelo menos a cada mês.As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente oProduct Owner tem a autoridade para cancelar a Sprint, embora ele possa fazê-lo sob influênciadas partes interessadas, da equipeou do ScrumMaster. Sob que tipo de circunstâncias pode sernecessário cancelar uma Sprint? A gerência pode precisar cancelar uma Sprint se a Meta da Sprintse tornar obsoleta. Isso pode ocorrer se a empresa mudar de direção ou se as condições domercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela não fizer maissentido dadas as circunstâncias atuais, todavia isso deve ser uma exceção. Porém, por causa da curtaduração das Sprints, raramente isso faz sentido.Artefato resultante dessa iteração: Parte do produto
  62. 62. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 62Framework Scrum: Eventos de Duração Fixa:SprintBacklogProdutoPlanejamentoda SprintReuniãodiáriaSprint2-4 Semanas24 horasRevisãoda SprintRetrospectivada SprintVisão ProdutoBacklog
  63. 63. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 63Framework Scrum: Eventos de Duração Fixa:REUNIÃO DIÁRIAA equipe deve se encontrar diariamente para uma reunião de 15 minutos chamada ReuniãoDiária. Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints.Durante a reunião, cada membro explica:1. O que ele realizou desde a última reunião diária;2. O que ele vai fazer antes da próxima reunião diária; e3. Quais obstáculos estão em seu caminho.As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identificam eremovem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida dedecisões e melhoram o nível de conhecimento de todos acerca do projeto.O ScrumMaster deve garantir que a equipe realize essa reunião. A equipe é responsável porconduzir a Reunião Diária. O ScrumMaster ensina a equipe a manter a Reunião Diária com curtaduração, reforçando as regras e assegurando que as pessoas falem brevemente. O ScrumMastertambém enfatiza a regra de que galinhas não estão autorizadas a falar e nem a interferir de modoalgum na Reunião Diária.A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estãotransformando os itens do Product Backlog um incremento (a equipe), e para mais ninguém. Aequioe se comprometeu com uma Meta da Sprint, e a esses itens do product Backlog. AReunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as trêsperguntas).Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está porvir na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance sua Meta. Essa é umareunião fundamental de inspeção e adaptação no processo empírico do Scrum.
  64. 64. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 64Framework Scrum: Eventos de Duração Fixa:SprintBacklogProdutoPlanejamentoda SprintReuniãodiáriaSprint2-4 Semanas24 horasRevisãoda SprintRetrospectivada SprintVisão ProdutoBacklog
  65. 65. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 65Framework Scrum: Eventos de Duração Fixa:REVISÃO DA SPRINTAo final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês, essa é umareunião com duração fixa de 4 horas. Para Sprints de durações mais curtas, essa reunião não devetomar mais do que 5% do total da Sprint. Durante a Revisão da Sprint, a equipe Scrum e as partesinteressadas colaboram sobre o que acabou de ser feito.Baseados nisso e em mudanças no Product Backlog feitas durante a Sprint, eles colaboram sobrequais são as próximas coisas que podem ser feitas. Essa é uma reunião informal, com aapresentação da funcionalidade, que tem a intenção de promover a colaboração sobre o que fazer emseguida.A reunião inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e oque não foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foramenfrentados, além de como esses problemas foram resolvidos. A equipe então demonstra o trabalhoque está pronta e responde a questionamentos. O Product Owner então discute o Product Backlogda maneira como esse se encontra.Ele faz projeções de datas de conclusão prováveis a partir de várias hipóteses de velocidade. Emseguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazerem seguida. A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento deSprints seguintes.
  66. 66. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 66Framework Scrum: Eventos de Duração Fixa:SprintBacklogProdutoPlanejamentoda SprintReuniãodiáriaSprint2-4 Semanas24 horasRevisãoda SprintRetrospectivada SprintVisão ProdutoBacklog
  67. 67. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 67Framework Scrum: Eventos de Duração Fixa:RETROSPECTIVA DA SPRINTApós a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, a equipe Scrumtem a reunião de Retrospectiva da Sprint.Nessa reunião, com duração fixa de três horas, o ScrumMaster encoraja a equipe a revisar, dentrodo modelo de trabalho e das práticas do processo do Scrum, seu processo dedesenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. Existemdiversas técnica que são úteis em uma Retrospectiva.A finalidade da Retrospectiva é inspecionar como foi a última Sprint em se tratando de pessoas,das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizaros principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam terdeixado as coisas ainda melhores. Isso inclui a composição da equipe, os preparativos parareuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos paratransformar itens do Product Backlog em alguma coisa “pronta”.No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as ações de melhoriafactíveis que será implementada na próxima Sprint. Essas mudanças se tornam a adaptação paraa inspeção empírica.
  68. 68. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 68ArtefatosFramework Scrum: Artefatos
  69. 69. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 69Framework Scrum: ArtefatosScrum tem quatro artefatos principais:- Product Backlog: é uma lista priorizada de tudo que pode ser necessário no produto.- Sprint Backlog: é uma lista de tarefas para transformar o Product Backlog , por uma Sprint, emum incremento do produto potencialmente entregável. Um burndown é uma medida dobacklog restante pelo tempo.- Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano deRelease do Produto.- Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.
  70. 70. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 70PRODUCT BACKLOG e RELEASE BURNDOWNOs requisitos para o produto que a equipe está desenvolvendo estão listados no Product BacklogO Product Owner (PO) é o responsável pelo Product Backlog , por sua criação, por seuconteúdo, por sua disponibilidade e por sua priorização.O Product Backlog nunca está completo. A seleção inicial para o seu desenvolvimento somentemostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui à medidaque o produto e o ambiente em que ele será usado evoluem. O Backlog é dinâmico, no sentido deque ele está constantemente mudando para identificar o que o produto necessita para serapropriado, competitivo e útil. Enquanto existir um produto, o Product Backlog também existirá.O Product Backlog representa tudo que é necessário para desenvolver e lançar um produto desucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções dedefeitos que constituem as mudanças que serão efetuadas no produto para releases futuras. Ositens do Product Backlog possuem os atributos de descrição, prioridade e estimativa. A prioridade édeterminada por risco, valor e necessidade. Há diversas técnicas para dar valor a esses atributos.O Product Backlog é ordenado por prioridade, os itens com as maiores prioridades devem ter odesenvolvimento imediato.Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há maisconsenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem maisinformações e detalhes do que os itens do Backlog de menor prioridade. É mais fácil de fazer aestimativa quando existem mais informações e mais detalhes.Framework Scrum: Artefatos
  71. 71. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 71PRODUCT BACKLOG e RELEASE BURNDOWN (continuação):Quando um produto é utilizado, que seu valor aumenta e que o cliente fornece feedback, oProduct Backlog poderá se tornar uma lista maior e mais aprofundada. Os requisitos nunca paramde mudar. O Product Backlog é um documento vivo. Mudanças nos requisitos de negócios,condições do mercado, tecnologia e equipe causam mudanças no Product Backlog. Paraminimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Ositens do Product Backlog que ocuparão a Equipe Scrum pelas várias Sprints seguintes deverão tergranularidade mais fina (mais detalhados), tendo sido decompostos de forma tal que cada um dositens possa ser feito dentro da duração da Sprint.Frequentemente, múltiplas equipes trabalham juntas no mesmo produto. Um único ProductBacklog é usado para descrever o trabalho a ser realizado no produto. Então, um atributo queagrupe os itens é aplicado no Backlog do Produto.O agrupamento pode ocorrer por conjuntos de características, por tecnologia ou por arquitetura,e ele é frequentemente utilizado como uma forma de se organizar o trabalho por equipe.O gráfico de Release Burndown registra a soma das estimativas dos esforços restantes do ProductBacklog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida detrabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmentesão Sprints.As estimativas dos itens do Product Backlog são inicialmente calculadas durante o Planejamentoda Release, e posteriormente à medida que itens forem sendo criados. Durante a preparação doProduct Backlog , os itens são revistos e revisados.Entretanto, eles podem ser atualizados em qualquer momento. A equipe é responsável por todasas estimativas. O Product Owner (PO) pode influenciar a equipe, ajudando-o a entender e aescolher as mudanças, mas a estimativa final é feita pelo equipe. O Product Owner mantém oProduct Backlog e o Release Burndown do Backlog atualizados e publicados todo o tempo. Umalinha de tendência pode ser traçada baseada na mudança do trabalho restante.Framework Scrum: Artefatos
  72. 72. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 72PRODUCT BACKLOG: ExemploFramework Scrum: ArtefatosTema* Item Prioridade Pontos (estimados)Venda dePassagemVender passagens áreas Alta 40Venda dePassagemConsulta de disponibilidade depassagens áreasAlta 13Check-in Fazer check-in Alta 40Check-in Cancelar Check-in Alta 8Programa deFidelidadeAdesão ao programa defidelidadeMédia 20Programa deFidelidadeConsultar os pontos doprograma de fidelidadeMédia 5Atendimento aoclienteFazer registro de comentários,sugestões e reclamações dosclientesBaixa 8Atendimento aoclienteResponder ao cliente (por e-mail)Baixa 5Nota: O que é Tema ?Tema é utilizado para agrupar “Estórias do Usuários” relacionadas, as estórias são representam o detalhamento dos itens do Backlog, ao usar oconceito de “tema”, ele poderá facilitar as atividades de priorização e de estimativa.Product Backlog
  73. 73. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 73RELEASE BURNDOWN: ExemploFramework Scrum: ArtefatosSprintsPontos(estimados)150100500Sprint #1 Sprint #2 Sprint #13 Sprint #4139Release Burndown905220Release Burndown registra asoma das estimativas dos esforçosrestantes do Product Backlog aolongo do tempo. O esforçoestimado deve estar em qualquerunidade de medida de trabalhoque a equipe e a organizaçãotenham decidido usar. Asunidades de tempo geralmentesão Sprints.
  74. 74. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 74SPRINT BACKLOG E SPRINT BURNDOWN:A Sprint Backlog consiste nas tarefas que a equipe executa para transformar os itens do ProductBacklog em um incremento “pronto”. Muitas deles são elaboradas durante a Reunião dePlanejamento da Sprint.A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta daSprint. Os itens do Sprint Backlog devem ser decompostos. A decomposição deve ser suficientepara que mudanças no progresso possam ser entendidas na Reunião Diária.A equipe modifica a Sprint Backlog no decorrer da Sprint. Quando chega às tarefas individuais, aequipe pode descobrir que mais ou menos tarefas serão necessárias, ou que uma determinadatarefa levará mais ou menos tempo do que era esperado. À medida que novo trabalho surge, aequipe o adiciona a Sprint Backlog.À medida que se trabalha nas tarefas ou que elas são completadas, as horas estimadas de trabalhorestantes para cada tarefa são atualizadas. Quando se verifica que determinadas tarefas sãodesnecessárias, elas são removidas.Somente a equipe pode modificar a Sprint Backlog durante uma Sprint, pode mudar o seu conteúdoou as suas estimativas. A Sprint Backlog é um retrato em tempo real altamente visível dotrabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.Framework Scrum: Artefatos
  75. 75. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 75SPRINT BACKLOG E SPRINT BURNDOWN: ExemploFramework Scrum: ArtefatosNa reunião de Planejamento daSprint, PO deverá apresentar avisão do produto, Product Backloge seus Itens, comentando o nívelde prioridade de cada item. Osmembros da equipe devemselecionar os itens com os maioresníveis de prioridades para fazerparte da Sprint.Como cliente de negócio, eu quero fazer check-inpela web para que fique menos tempo em filas.Pontos: ?Titulo: “Fazer Check-in”Prioridade: AltaEstória do Usuário A estória do usuário auxilia noentendimento do que deve serfeito, ela permite fazer aestimativa de velocidade daequipe e também é, utilizadacomo lembrete e para asatividades de planejamento.Geralmente a estimativa é feitaem pontos (pontos de estória)
  76. 76. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 76SPRINT BACKLOG E SPRINT BURNDOWN: ExemploFramework Scrum: ArtefatosComo cliente de negócio, eu quero fazer check-inpela web para que fique menos tempo em filas.Pontos: ?Titulo: “Fazer Check-in”Prioridade: AltaEstória do UsuárioQuebrar a estória do Usuário emtarefas:- Para facilitar a estimativa develocidade da equipe, considerequebrar a estória em tarefas, istopode fazer que todos os membrosda equipe visualizem todas astarefas que devem ser feitas paraimplementar o item do backlog.Mas, ainda precisamos estimar ospontos...Sprint BacklogFazer Check-inFazerinterfacedo usuárioIntegrarcom Sistemade ReservaCriarComponentesde validaçãoExecutartestesunitáriosExecutartestes deaceitaçãoImpressãodo TicketA Sprint Backlog é umartefato resultante da reuniãode Planejamento da Sprint
  77. 77. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 77Estimando os pontos da “Estória do Usuário”:Uma breve introdução sobre estimativa:Estimar é Difícil ?- Estimativa (mundo real) representa um valor aproximado.- Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato.Contudo, devemos estimar as Estórias do Usuário para saber se elas “cabem” dentro de uma Sprint.Uma vez que os pontos são estimados eles ajudam a definir a velocidade da equipe, a partir desteparâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber aopção é quebrar esta estória em estórias menores.Pessoal, qualestimativa paraessa estória...Product OwnerTitulo: Pagamento com Cartão de Crédito Prioridade: ?Quem ?como um clienteO que ?preciso de uma interface de pagamento por cartão decrédito que seja intuitiva e fácil de usar.Por que ?Com objetivo de facilitar os pagamentos.Pontos: ?Exemplo de Estórias do Usuário:
  78. 78. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 78Baseado na duração de tarefas.- Dias ou horas é unidade bem definida, contudo o “tempo ideal”quase nunca é igual ao “tempo real”...- É mais fácil de estimar, mas pode ser tornar difícil de estimar seconsideramos todas as interrupções e variaçõesBaseia-se no tamanho da estória influenciado pela:- Nível de dificuldade, complexidade e experiência (é empírico);Foco nas funcionalidades;O importante são os valores relativos;Pontos são medidas sem unidade;Equipe diferentes podem ter pontos diferentes para a mesmaestórias.Pontos de Estória (Story Points)Principais técnicas:◦ Opinião de especialista;◦ Analogia;◦ Decomposição (Dividir para conquistar).Dias Ideais (Ideal Days)Pontos de Estória:◦ Valores relativos◦ Mais abstratoIdeal Days:◦ Mais fácil para iniciantes◦ Fácil de explicarQuando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade daequipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória.Estimando os pontos da “Estória do Usuário”:
  79. 79. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 79Estimativa* e o Planning Poker:Geralmente o Planning Poker usa um conjunto de cartas com valores específicos quepodem representar pontos relativos e é praticado como se fosse um jogo de cartas. Ospontos devem estar em uma escala não linear, por e exemplo a Fibonacci:(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escalaPara fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever asestórias do usuário.O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseadano consenso de toda a equipe.Pessoal, qual éestimativa paraessa estória...Product Owner Equipe404040100Jogando o Planning Poker:Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estóriaque pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência parapontuação das demais estórias.O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade...404040401ª. Rodada Quando todas as cartasestiverem lançadas, elassão viradas e caso nãohaja consenso nospontos, as diferenças sãodiscutidas de formabreve, e uma novarodada acontece até quehaja concesso.Nª. RodadaEquipeEstimando os pontos da “Estória do Usuário”:
  80. 80. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 80SPRINT BACKLOG: ExemploFramework Scrum: ArtefatosComo cliente de negócio, eu quero fazer check-inpela web para que fique menos tempo em filas.Pontos: 40Titulo: “Fazer Check-in”Prioridade: AltaEstória do UsuárioPlanning Poker, estória do usuárioe pontos de estória, nada disso fazparte do framework Scrum,contudo são técnicas e ferramentascomplementares ao framework.Elas são altamente utilizadas parafazer a estimativa de velocidade daequipe.E finalmente temos a SprintBacklog e podemos criar o SprintBurndonw.Fazer Check-inFazerinterfacedo usuárioIntegrarcom Sistemade ReservaCriarComponentesde validaçãoSprint BacklogExecutartestesunitáriosExecutartestes deaceitaçãoA Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint.Impressãodo Ticket
  81. 81. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 81SPRINT BACKLOG E SPRINT BURNDOWN:A Sprint Burndown (ou Burndown ) é um gráfico daquantidade restante de trabalho do Sprint Backlog emuma determinada Sprint ao longo do tempo da Sprint.Para criar esse gráfico, determine quanto trabalho restasomando as estimativas do Backlog a cada dia daSprint.A quantidade de trabalho restante para uma Sprint é asoma do trabalho restante para tudo da Sprint Backlog.Acompanhe essas somas diariamente e utilize-as para criarum gráfico que mostre o trabalho restante ao longo dotempo. Traçando uma linha através dos pontos nográfico, a equipe pode gerenciar seu progresso emcompletar o trabalho de uma Sprint.A duração não é considerada em Scrum. O trabalhorestante e a data são as únicas variáveis de interesse.Uma das regras do Scrum está ligada ao objetivo de cadaSprint, que é ter como resultado incrementos defuncionalidade potencialmente entregáveis que estejam deacordo com uma definição de “pronto”.Framework Scrum: ArtefatosA Sprint Burndown é um artefatoque deve ser utilizado exclusivamentepela equipe.Se PO tentar fazer a gestão doprojeto com base na SprintBurndown é considerado comomicro-gerenciamento e que podelevar ao comando-controle...O PO deve fazer a gestão do projetoolhando a Release Burndown.Dica:Sempre que possível, desenhe a Sprint Burndown em umquadro que esteja na área de trabalho da equipe. É maisprovável que a equipe veja um gráfico grande e visível do queum gráfico de feito em uma planilha de calculo.
  82. 82. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 82SPRINT BURNDOWN : ExemploFramework Scrum: ArtefatosO Quadro de Tarefas tambémnão parte do frameworkScrum, ele parte de umatécnica chamada Gestão àVista, que tem como objetivofacilitar a comunicação e darvisibilidade (transparência).A transparência, que é dos pilares do Scrum, garante queaspectos do processo que afetam o resultado devem ser visíveispara aqueles que gerenciam os resultados. O Quadro de Tarefasdeixam a Sprint com visibilidade e transparência.
  83. 83. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 83ProntoFramework Scrum: Definição de Pronto
  84. 84. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013Uma conversa comum entre o cliente e o desenvolvedor:[Cliente] E aí como anda o desenvolvimento da aplicação ?[Desenvolvedor] Está pronta...[Cliente] Isso quer dizer que eu posso implementa-la ?[Desenvolvedor] Bem...ainda não, preciso fazer mais alguns testes...[Cliente] Mas, aplicação não estava pronta..84Definição de Pronto (*DoD):Definir claramente quando o produto estará “pronto”,pois:Pronto, para desenvolvedor significa:- Encerrou a codificação...Pronto, para PO significa:- Quando foi entregue...Pronto, para os usuários finais e/ou clientes significa:- Quando o software começou a funcionar em ambientede produção...Evite: A síndrome dos 90% feito (pronto).
  85. 85. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 85No desenvolvimento de produtos, afirmar que a funcionalidade está pronta pode levar alguém apresumir que ela está pelo menos bem codificada, refatorada, que tenha passado por testesunitários, que tenha sido feito o “build” e que tenha passado por testes de aceitação.Outros podem presumir que apenas o código tenha sido desenvolvido.Se não houve definição de “pronto”, os outros dois pilares do controle de processos empíricos nãofuncionam. Quando alguém descreve algo como “pronto”, todos devem entender o que “pronto”significa.“Pronto” define o que a equipe quer dizer quando se compromete a “aprontar” um item deProduct Backlog em uma Sprint. Alguns produtos não contêm documentação, de forma que suadefinição de “pronto” não inclui documentação. Um incremento completamente “pronto” inclui todaa análise, projeto, refatoramento, programação, documentação e testes para o incremento e todos ositens do Product Backlog no incremento. Os testes incluem testes de unidade, desistema, de usuário e de regressão, bem como testes não-funcionais como de performance, deestabilidade, de segurança e de integração.“Pronto” inclui também qualquer internacionalização necessária. Algumas equipes ainda não sãocapazes de incluir em sua definição de “pronto” tudo o que é necessário para a implantação. Istodeve estar claro para o Product Owner. Esse trabalho restante deverá ser feito antes que oproduto possa ser implantado e utilizado.Framework Scrum: Definição de ProntoScrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cadaSprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner (PO)pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, oincremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cadaincremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado,garantindo que todos os incrementos funcionem juntos.A Definição de PRONTO
  86. 86. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 86A Definição de PRONTO e “NÃO PRONTO”Algumas organizações são incapazes de desenvolver um incremento completo dentro de umaSprint. Elas podem ainda não ter infraestrutura automatizada de testes para completar todos ostestes. Nesse caso, duas categorias são criadas para cada incremento: o trabalho “pronto” eo trabalho “não pronto”. O trabalho “não pronto” é a porção de cada incremento que terá que sercompletada mais tarde. O Product Owner sabe exatamente o que ele está inspecionando ao finalda Sprint, porque o incremento atende à definição de “pronto” e o Product Owner entende essa definição.O trabalho “não pronto” é adicionado a um item do Product Backlog o chamado “trabalho não pronto”, deforma que ele se acumula e isso é refletido corretamente no gráfico de Release Burndown Release.Essa técnica cria transparência no progresso em direção à entrega. A inspeção e a adaptação naRevisão da Sprint serão tão precisas quanto essa transparência for.Framework Scrum: Definição de ProntoExemplo:Se uma equipe não é capaz de realizar os testes de performance, regressão, estabilidade,segurança e integração para cada item do Product Backlog, a proporção desse trabalho emrelação ao trabalho que pode ser pronto (análise, projeto, refatoramento, programação,documentação, testes unitário e testes de usuário) é calculada.Vamos supor que essa proporção é de seis peças de “pronto” e quatro peças de “não pronto”. Se aequipe terminar um item de Product Backlog de seis unidades de trabalho (a equipe estáestimando baseado no que ele sabe como “aprontar”), quatro unidades serão acrescidas aoitem do Product Backlog denominado “trabalho não pronto” quando eles tiverem terminado.Sprint a Sprint, o trabalho “não pronto” de cada incremento vai se acumulando e deve sertratado antes da entrega do produto. Esse trabalho é acumulado linearmente, embora haja algumtipo de acúmulo exponencial que é dependente das características de cada organização.Sprints são adicionados ao final de cada release para completar o trabalho “não pronto”. Onúmero de Sprints é imprevisível, visto que o acúmulo de trabalho “não pronto” não é linear.
  87. 87. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 87Exercícios:1 - Quando as regras não são declaradas, espera-se que os usuários de Scrum descubram o quedevem fazer. Não tente descobrir uma solução perfeita, porque geralmente o problema mudarapidamente. Ao invés disso, tente algo e veja como se sai. Os mecanismos de inspeção-e-adaptaçãoinerentes à natureza empírica do Scrum irão lhe guiar.[ ] Verdadeiro [ ] FalsoResponda Verdadeiro ou Falso para as declarações:2 - O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner.O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners queeles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos oScrumMaster responsável.[ ] Verdadeiro [ ] Falso3 - O ScrumMaster pode ser um membro da equipe; por exemplo, um desenvolvedor realizando tarefasda Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entreremover impedimentos ou realizar tarefas.[ ] Verdadeiro [ ] Falso4 - O ScrumMaster nunca deve ser o Product Owner.[ ] Verdadeiro [ ] Falso
  88. 88. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 88Exercícios:5 - O Product Owner pode ser um membro da equipe, trabalhando também na realização das tarefas.Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partesinteressadas.[ ] Verdadeiro [ ] FalsoResponda Verdadeiro ou Falso para as questões:6 – Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o ProductOwner para remover ou reduzir o escopo da Sprint Backlog (itens do Product Backlog selecionado paraa Sprint). Se a equipe sentir que sobrará tempo ele pode trabalhar junto ao Product Owner paraselecionar mais do itens do Product Backlog.[ ] Verdadeiro [ ] Falso7- Geralmente, somente 60-70% do total da Sprint Backlog será definido na Reunião de Planejamentoda Sprint. O restante é deixado para ser detalhado mais tarde ou são dadas estimativas grandes queserão decompostas mais tarde na Sprint.[ ] Verdadeiro [ ] Falso8 - Os itens do Product Backlog são comumente representados como “Estórias do Usuário”. Casos deUso também são apropriados.[ ] Verdadeiro [ ] Falso
  89. 89. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 89Exercícios:9 - Testes de aceitação fazem parte da Estória de Usuário, são utilizados parar substituir descriçõestextuais mais detalhadas com uma descrição testável.[ ] Verdadeiro [ ] FalsoResponda Verdadeiro ou Falso para as questões:10 - O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlogao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que aequipe Scrum e a organização tenham decidido usar. As unidades de tempo geralmente sãoEstórias do Usuário.[ ] Verdadeiro [ ] Falso
  90. 90. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 901 – Desafios do desenvolvimento de Software2 – Sobre o SCRUM3 – Entendendo SCRUM4 – Estudo de CasoConteúdo:
  91. 91. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 91Objetivo:Estudo de CasoObjetivo:Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM emprojeto de desenvolvimento de Software.Pré-requisito:Conhecimento das práticas Scrum.
  92. 92. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 92Estudo de CasoEstudo de Caso
  93. 93. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013Framework SCRUMArtefatosSprintBacklogProdutoPlanejamentoda SprintReuniãodiáriaSprint(2-4 Semanas)24 horasRevisãoda SprintRetrospectivada SprintReuniões• Sprint Burndown• Release BurndownProductBacklogLegenda:• Product Owner (PO)• ScrumMaster (SM)• Equipe (time)• Product Backlog• Sprint Backlog• Sprint Burndown• Release BurndownPapéisReuniõesArtefatos• Planejamento da Release• Planejamento da Sprint• Diária• Revisão da Sprint• Retrospectiva da SprintVisãoPlanejamentoda Release93
  94. 94. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 94Estudo de Caso: VisãoSprintBacklogProdutoPlanejamentoda SprintReuniãodiária24 horasRevisãoda SprintRetrospectivada SprintVisãoProdutoBacklogSprint2-4 SemanasPrimeiro passo: definir a Visão do Produto.Planejamentoda Release1
  95. 95. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 95A necessidade:Um hotel, quer incrementar um novo canal de consultas e vendas de reservas deapartamentos. A sugestão foi criar um Portal de Reservas para vender os serviços.Estudo de Caso: Visão do ProdutoDeclaração da Visão do Produto:Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line é umsoftware baseado na web, intuitivo e fácil de usar que fornece a possibilidade fazer aconsultas e reservas de apartamentos.Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente.Para definir a visão do Produto, primeiro é necessário entender qual é a real necessidade do cliente:Após entender a necessidade do cliente, é hora de definir a Visão do Produto:
  96. 96. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 96O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver elançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias ecorreções de defeitos que constituem as mudanças que serão efetuadas no produto para futurasreleases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudandopara identificar o que o produto necessita.Estudo de Caso: Visão do ProdutoApós a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:Funcionalidades do produto
  97. 97. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 97Estudo de Caso: Visão do Produto
  98. 98. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 98Podemos fazer a declaração da Visão do Produto sem entender a real necessidade do cliente ?Exercício:Estudo de Caso: Visão do Produto
  99. 99. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 99Estudo de Caso: Reunião de Planejamento da ReleaseSprintBacklogProdutoPlanejamentoda SprintReuniãodiária24 horasRevisãoda SprintRetrospectivada SprintVisãoProdutoBacklogSprint2-4 SemanasSegundo passo: Realizar a Reunião de Planejamento da Release, o resultado desta reunião é oPlano de Release e o Release Burndown (artefato Scrum).Planejamentoda Release2
  100. 100. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 100O propósito da Reunião de Planejamento da Release é o de estabelecer o Plano de Release, as Metase Release Burndown (que é um artefato do Scrum) que a Equipe Scrum e o resto da organizaçãopossam entender e comunicar.O planejamento da release responde às questões:- Como podemos transformar a visão em um produto da melhor maneira possível?- Como podemos alcançar ou exceder a satisfação do cliente ?- Como podemos alcançar o ROI (retorno sobre investimento) ?O Plano de Release estabelece a meta da release, as maiores prioridades do Product Backlog,os principais riscos e as características gerais e funcionalidades que estarão contidas na release.Ele estabelece também uma data de entrega e custos prováveis que devem se manter se nada mudar. Aorganização pode então inspecionar o progresso e fazer mudanças nesse Plano de Release a cadaSprint.O planejamento da release requer estimar e priorizar o Product Backlog para a release. Há diversastécnicas para fazê-lo que estão fora do alcance do Scrum (lembre-se o SCRUM é framework ele nãoindica nenhuma técnica), mas que apesar disso são úteis quando usadas com ele.Estudo de Caso: Reunião de Planejamento da ReleasePlanejamentoda ReleaseProduct Backlog (visão inicial)Product Backlog (priorizado)Visão do ProdutoPlano de ReleaseEntradasSaídasReleaseBurndown(artefato)Equipe SCRUM
  101. 101. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 101Estudo de Caso: Reunião de Planejamento da ReleasePlano de ReleaseReserva PromoçõesPrograma deFidelidadeTour VirtualReleasesNível dePrioridadeRelacionamentoao clientePrazo(estimado)Alto Médio Médio Médio Baixo30 dias 15 dias 7 dias 15 dias 15 dias5 Releases82 dias1 Alto, 3 médioe 1 baixo123Visão inicial do Product Backlog, antes da reunião de Planejamento daSprint, ele tem somente as funcionalidades do produto, agrupadas portema (este agrupamento é opcional).O Plano de Releaseé elaborado nessareunião. Nesse planodefine-se o prazo deentrega do produto enível de prioridadedos itens do backlogO Plano de Releaseé base para atualizaçãodo Product BacklogAgora ele apresenta onível de prioridade equantidade de pontosestimados dos itens.O PO é responsávelpela priorização dositens e a Equipe éresponsável pelaestimativa.
  102. 102. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 102ReleasesPontos(estimados)12080400Release #1 Release #2 Release #3 Release #5108Release Burndown684820Estudo de Caso: Reunião de Planejamento da Release40Release #4Com Product Backlog atualizado e o Plano de Release, o PO poderá construir o Release Burndown, que é umdos artefatos do SCRUM. As estimativas dos itens do Product Backlog são inicialmente calculadas durantea Reunião de Planejamento da Release.O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo dotempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e aorganização tenham decidido usar. As unidades de tempo geralmente são Sprints.O Product Owner é responsávelpor manter o Product Backlog eo Release Burndown atualizadose publicados todo o tempo.Uma linha de tendência pode sertraçada baseada na mudança dotrabalho restante.
  103. 103. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 103Estudo de Caso: Reunião de Planejamento da Release
  104. 104. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 104O que aconteceria se a equipe SCRUM não fizer a Reunião de Planejamento da Release ?Estudo de Caso: Reunião de Planejamento da ReleaseExercício:
  105. 105. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 105Estudo de Caso: Reunião de Planejamento da SprintSprintBacklogProdutoPlanejamentoda SprintReuniãodiária24 horasRevisãoda SprintRetrospectivada SprintProdutoBacklogSprint2-4 SemanasTerceiro passo: Realizar a Reunião de Planejamento da Sprint, o resultado desta reunião são osartefatos Sprint Backlog e Sprint Burndown.Planejamentoda ReleaseVisão3
  106. 106. rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFSSCRUM®,OTutorialDefinitivoTodos os direitos reservados e protegidos © 2006 e 2013 106Product Backlog: Sistema de Reserva On-LineEstudo de Caso: Reunião de Planejamento da SprintA Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. No nossoexemplo a duração é fixada em 8 horas, pois, a Sprint tem a estimativa de um mês.Essa reunião é dividida em duas partes:1ª. Parte da Reunião (4 horas):A equipe Scrum trata da questão: “o quê?”.O PO apresenta a equipe o que é maisprioritário no Product Backlog. Todos trabalhamem conjunto para definir qual funcionalidadedeverá ser desenvolvida durante a próximaSprint. O Product Backlog está ordenado deacordo com nível de prioridade dos itens.A equipe deve selecionar o item de maiorprioridade e definir qual será a meta da Sprint.2ª. Parte da Reunião (4 horas):A equipe trata a questão: “como?”.Durante as 4 horas seguintes a equipe define comotransformará o item selecionado em incremento doproduto “pronto” e potencialmente entregável.O PO estará presente para esclarecer dúvidas e paraajudar a efetuar trocas, se necessário. Se a equipeconcluir que ela tem trabalho demais ou de menos,ela pode renegociar os itens do Product Backlogescolhido com o PO

×