Baixar para ler offline
Carregado porIoná Dourado
SCRUM - Workshop Básico
O documento apresenta os conceitos e práticas do framework Scrum, incluindo os papéis do Product Owner, Scrum Master e time, as cerimônias como Planning, Daily, Review e Retrospectiva, e artefatos como Backlog do Produto e Burndown.
![[IFMG][ENGENHARIA DE SOFTWARE] - SCRUM](https://cdn.slidesharecdn.com/ss_thumbnails/aula6-scrum-131213161946-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
SCRUM - Workshop Básico
- 1.
- 2. Scrum - UmaBreve Revisão Os Papéis do Scrum Cerimônias Artefatos Agenda
- 3.
- 4.
- 5. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 6. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 7. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 8. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 9. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 10. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 11. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 12. 24 h VisãoRetrospectiva 1 – 4 Semanas Backlog do Produto Planning + Backlog da Sprint Review + Incremento do produto
- 13.
- 14.
- 15. PAPEL DO PRODUCTOWNER • Validar os critérios de aceite de cada história, solicitar requisitos claros e concretos • Garantir o sucesso do projeto, priorizando as funcionalidades • Definir as principais metas de cada sprint • Manter o backlog do produto atualizado e priorizado • Criar e atualizar relatórios de evolução do produto • Manter a integração entre todos os envolvidos garantindo a comunicação entre eles • Manter a disponibilidade para responder todas as questões do time prontamente • Participar de todas as cerimônias e acompanhar o andamento diário das histórias
- 16. NÃO É PAPELDO PRODUCT OWNER • Definir a solução técnica, arquitetura ou modelo de desenvolvimento • O PO define “o que fazer” e não “como” fazer • Estimar as histórias e definir as tarefas • Gerenciar o time. O time é auto-gerenciável • Garantir os prazos das entregas • Garantir a qualidade das entregas • Distribuir tarefas para o time
- 17.
- 18. O Scrum Masteré o responsável por Garantir que o Scrum seja entendido e aplicado.
- 19. O PAPEL DO SCRUM MASTER • Remover os impedimentos do time • Garantir que o time não sofra interferências externas • Garantir que o método seja seguido sempre buscando a melhoria contínua • Motivar a produtividade do time mostrando os resultados • Fazer uma “ponte” entre o time e PO e todos os demais envolvidos • Reportar o andamento do projeto para o escritório de projetos • Garantir o compromisso do time com os critérios de aceite estabelecidos pelo PO
- 20. NÃO É PAPELDO SCRUM MASTER • Definir a solução técnica • Estimar o trabalho • Gerenciar o time. O time é auto gerenciável • Priorizar as histórias • Distribuir as tarefas • Definir os critérios de aceite • Detalhar os requisitos ou definir regras de negócio
- 21.
- 22. PAPEL DO TIME • Desenvolver o produto respeitando a priorização estabelecida pelo PO • Garantir a qualidade das entregas • Participar das cerimônias ao longo do projeto • Definir a solução técnica, arquitetura e processo de desenvolvimento • Estimar o trabalho a ser realizado e comprometer-se com as estimativas • Organizar o trabalho • Preparar o review meeting e apresentar o produto para o PO.
- 23. NÃO É PAPELDO TIME • Definir o que deve ser feito, somente como deve ser feito • Priorizar as histórias do backlog • Estabelecer os critérios de aceite • Detalhar os requisitos funcionais do produto • Definir regras de negócios ou detalhar requisitos funcionais
- 24. Cerimônias Planning {Prioridade e Estimativa } Sprint { Daily e Grooming } Review { Apresentar e Validar } Retrospective { Positivo e Negativo }
- 25. Time BOX •Planning (1 h) • Review (1 h) • Retrospective (30 min) • Estimar (30 min) • Daily (15 min)
- 26. Planning { Prioridade} • Ter Objetivo • Apresentar o product backlog
- 27. Estimativa Fibonacci: 0,1,1,2,3,5,8,13,21,34,55,89,144,233... • Divisão / quebrar as tarefas • Estimar Velocidade • Desenhar a linha de progresso
- 28. 1 Sprint =5 Dailys
- 29.
- 30.
- 31.
- 32. Artefatos Backlog Kanban Pronto Burndown
- 33. Backlog do Produto Histórias Detalhadas e Estimadas Sem Muitos Detalhes Alta Prioridade Sem Priorização Sprint Backlog
- 34. Definição De “Pronto” Validado e Especificado para Dev.
- 35.
- 36.
- 40.
Notas do Editor
- #4 Scrum – uma breve visão geral Origem na jogada do Rugby
- #5 Pilares do Scrum Transparência – todos os elementos do processo são visíveis para os participantes, assim como não existem ambigüidades em relação ao estado de cada elemento -> se uma funcionalidade está pronta, todos os envolvidos tem o mesmo entendimento do que isso significa. Inspeção – os responsáveis pelo processo frequentemente analisam o mesmo para verificarem se existe algum desvio. Adaptação – com base nas informações obtidas na inspeção, o processo é alterado para que apresente novamente um comportamento produtivo.
- #6 Cara do Scrum ... Vamos os principais elementos...
- #7 Visão – define qual o objetivo a ser alcançado com o produto que está sendo construído
- #8 Backlog do produto – reúne os requisitos conhecidos. É um artefato vivo, que é modificado conforme se aprende mais sobre o produto.
- #9 Planejamento da sprint - criação do plano de ação que transformará os itens prioritários do backlog em um incremento funcional do produto Sprint Backlog – representa o plano com todas as atividades levantadas pelo time.
- #10 Sprint – ciclo completo de desenvolvimento em que o time atua em período de tempo fixo e que deve entregar no final um incremento funcional do produto.
- #11 Daily meeting – ponto diário de inspeção e adaptação onde são respondidas 3 perguntas: O que fiz ontem O que pretendo fazer hoje Qual meu impedimento
- #12 Review – o resultado da Sprint e apresentado para o P.O e demais interessados – - Ponto de inspeção e adaptação do produto Neste momento pode haver uma aprovação, reprovação e os comentários relacionados a entrega O resultado da avaliação serve de insumo para o próximo planejamento
- #13 Retrospectiva – ponto de inspeção e adaptação do processso
- #14 Papeis Vamos falar rapidamente sobre os papeis existentes e nos aprofundar no papel de P.O
- #15 Papeis – time de desenvolvimento Auto organizado - Responsável pela construção do prodruto. Responsável por estabelecer um plano para a construção do produto. As estimativas são realizadas por ele. Multidisciplinar – deve possuir todas as competências para poder desenvolver o produto (front, back end, testes, analistas de req, etc.)
- #18 Papeis - Scrum Master Lider servidor - atua removendo impedimentos do time Scrum. Não tem autoridade formal sobre o time. Coach – promove o aprendizado do framework scrum para os desenvolvedores e o P.O. Ensina-os a aturem como um time Responsável pelo processo – deve garantir a aplicação do Scrum. Também atua para indicar quais alterações no processo estão alinhadas com o framework ou não.
- #19 E o P.O ...
- #22 Papeis – time de desenvolvimento Auto organizado - Responsável pela construção do prodruto. Responsável por estabelecer um plano para a construção do produto. As estimativas são realizadas por ele. Multidisciplinar – deve possuir todas as competências para poder desenvolver o produto (front, back end, testes, analistas de req, etc.)
- #26 O P.O colabora com o time para definir o conceito de pronto que será utilizado para cada estória construída. O conceito varia para cada organização ou projeto, mas deve contemplar no mínimo o funcionamento da estória, testes (unitário, de aceitação, funcional...) e requisitos organizacionais, como documentação.
- #27 - Precisa estar confortável com alto grau de incerteza, riscos, experimentação e aprendizado que caracterizam o desenvolvimento de um novo produto/projeto. - Estabelecendo a visão de longo prazo, o P.O guia o time em torno deste objetivo
- #28 - Precisa estar confortável com alto grau de incerteza, riscos, experimentação e aprendizado que caracterizam o desenvolvimento de um novo produto/projeto. - Estabelecendo a visão de longo prazo, o P.O guia o time em torno deste objetivo
- #29 - O P.O participa da Daily como ouvinte, tendo a oportunidade de acompanhar o andamento do trabalho que está sendo realizado. O time pode realizar questionamentos ao P.O que podem remover empecilhos para a continuidade das atividades. - Ao termino da reunião o P.O pode compartilhar informações relevantes com o time
- #30 Reunião para Preparar/Refinar o backlog para o próximo planejamento. Durante o Gromming, o P.O se reune com uma parte do time de desenvolvimento para trabalharem no refinamento dos requisitos de maior prioridade. Recomenda-se que 10% do tempo de um sprint seja reservado para esta atividade.
- #31 - O P.O participa da Daily como ouvinte, tendo a oportunidade de acompanhar o andamento do trabalho que está sendo realizado. O time pode realizar questionamentos ao P.O que podem remover empecilhos para a continuidade das atividades. - Ao termino da reunião o P.O pode compartilhar informações relevantes com o time
- #32 P.O pode participar com o time da retrospectiva. O P.O participa da cerimônia como um mebro do time Scrum, tendo como objetivo a melhoria do processo de desenvolvimento para a próxima iteração.
- #34 - Precisa estar confortável com alto grau de incerteza, riscos, experimentação e aprendizado que caracterizam o desenvolvimento de um novo produto/projeto. - Estabelecendo a visão de longo prazo, o P.O guia o time em torno deste objetivo
- #35 O P.O colabora com o time para definir o conceito de pronto que será utilizado para cada estória construída. O conceito varia para cada organização ou projeto, mas deve contemplar no mínimo o funcionamento da estória, testes (unitário, de aceitação, funcional...) e requisitos organizacionais, como documentação.
- #36 Release Planning
- #37 Vamos praticar?
- #38 Roman Pichler
- #39 Mike Cohn – User Stories
- #40 Mike Cohn – User Stories