Framework Scrum

Mapa mental do framework Scrum para auxilo da prova de certificação PSM I

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Framework Scrum por Mind Map: Framework Scrum

1. Necessidades negocias determinam prioridade do desenvolvimento

2. São auto-organizados

3. Pode ser alguém de negócios ou alguém experiente dentro da organização com amplo conhecimento nos produtos

4. Todos do time Scrum participam

5. Adaptação

5.1. Equipe flexível e adaptável a mudanças

5.2. Quando identificado um problema uma ação de adaptação é realizada

5.3. Durante as cerimonias pode ser realizadas inspenções que irão provocar adaptações

6. Revisão da sprint

6.1. Ocorre no final de cada sprint

6.2. Time-box de 4 horas para um Sprint de um mês

6.2.1. Proporcionalmente menor para sprints menores

6.2.2. É uma hora para cada semana de duração da sprint

6.3. O Dono do Produto fornece feedback sobre o desenvolvimento do incremento realizado

6.4. Todos do time Scrum participam

6.4.1. O PO pode convidar partes interessadas para validar o incremento

6.5. Foco no produto

7. Reunião diária

7.1. Sempre uma time-box de 15 minutos

7.2. Ocorre todos os dias, exceto quando há reuniões de planejamento, revisão e retrospectiva da sprint

7.3. É mantida no mesmo horário e local para diminuir a complexidade

7.4. A presença do Scrum master é opcional

7.5. Os membros respondem a 3 perguntas

7.5.1. O que eu fiz desde a última reunião?

7.5.2. O que eu vou fazer até a próxima reunião diária?

7.5.3. Há alguma coisa impedindo o meu trabalho?

7.6. Serve para sincronização das informações das tarefas em andamento da Sprint

8. Causando mudanças que aumentam a produtividade do Time Scrum

9. Integrantes multidisciplinares

9.1. Conseguem contribuir realizando mais que uma tarefa ex: Desenvolver e testar o software

10. Entrega incrementos que possuem valor ao cliente

10.1. Backlog do produto

10.1.1. É uma lista ordenada de tudo que deve ser necessário no produto

10.1.2. O Product Owner é responsável pelo Backlog do Produto

10.1.3. É um artefato vivo

10.1.3.1. O Backlog do Produto é dinâmico

10.1.3.2. Muda constantemente a medida que se aprende mais sobre o produto

10.1.4. Um Backlog do Produto nunca está completo

10.1.5. O Backlog do Produto existirá enquanto o produto também existir

10.1.6. Recomenda-se um Backlog de produto por produto mesmo que varias equipes trabalhem no mesmo produto

10.1.7. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa

10.1.8. Os itens com prioridade maior terão maior detalhamento

10.1.9. As estimativas dos itens são realizadas pelo time de desenvolvimento

10.2. O PO é responsavel por maximizar o valor do produto

11. Auxiliar o Dono do Produto ensinando técnicas para o gerenciamento do backlog do produto

12. Retrospectiva da sprint

12.1. Planejamento da sprint

12.1.1. Primeiro evento que ocorre na sprint

12.1.2. Time-box com no máximo oito horas para uma Sprint de um mês de duração

12.1.3. Todos do time Scrum participam colaborativamente

12.1.4. Responde as seguintes questões:

12.1.4.1. O que pode ser entregue?

12.1.4.1.1. Define meta/objetivo da sprint

12.1.4.1.2. Itens são estimados em complexidade pelo time

12.1.4.1.3. Somente o time de desenvolvimento deve dizer quantos pontos são capazes de desenvolver

12.1.4.2. Como o trabalho necessário para entregar o incremento será realizado?

12.1.4.2.1. Tarefas podem ser estimadas em horas

12.1.4.2.2. Criado o artefato backlog da Sprint

12.1.5. Definição da meta e objetivo da Sprint

12.2. Ocorre logo após a revisão de cada sprint

12.3. Time-box de 3 horas para uma sprint de um mês

12.3.1. Proporcionalmente menor para sprints menores

12.4. Características gerais dos eventos

12.4.1. Todos eventos são time-boxed

12.4.2. O Scrum master deve garantir a realização de todos os eventos. Sua presença não é obrigatória nas reuniões diárias

13. Fundamentos

13.1. Valores

13.1.1. Foco

13.1.1.1. A equipe Scrum foca o trabalho no backlog da Sprint e nos objetivos do time Scrum

13.1.2. Comprometimento

13.1.3. Coragem

13.1.3.1. Coragem para fazer a coisa certo e trabalhar com produtos complexos

13.1.4. Abertura

13.1.4.1. O time Scrum e os interessados Stakeholders precisam estar abertos e dispostos a todo trabalho e aos desafios para construção do trabalho

13.1.5. Respeito

13.1.5.1. O time se compromete a alcançar os objetivos da Sprint

13.1.5.2. Respeitam uns aos outros entendem que todos são independentes e capazes

13.2. Scrum é um Framework

13.2.1. Scrum não é uma metodologia

13.2.2. É uma estrutura para desenvolvimento de projetos completos

13.2.3. Pode ser empregado a outras técnicas, metodologias e processos

13.3. Transparência

13.3.1. Informação disponível a todos

13.3.2. Estimativas são levantadas por quem desenvolve a tarefa

13.3.3. Todos ficam cientes sobre os impedimentos que possam atrapalhar o progresso da Sprint

13.3.4. Comprometimento de acordo com a capacidade de desenvolvimento

13.4. Pilares

13.4.1. Inspenção

13.4.1.1. Os artefatos e o processo são frequentemente inspencionados

13.5. Principais características

13.5.1. Mais foco em pessoas e menos em processos

13.5.2. Empirismo

13.5.2.1. Conhecimento baseado na experiência

13.5.2.2. Compreende que um problema não pode ser completamente definido

13.5.2.3. O processo é adaptado a medida em que se aprende

13.5.2.4. A medida em que desenvolvo aprendo mais sobre o produto

13.5.3. Equipe auto gerenciadas

13.5.3.1. Na equipe todos são capazes e independentes

13.5.3.2. A equipe de desenvolvimento que escolhem as historias do Backlog do produto para o backlog da Sprint

13.5.3.3. A equipe de desenvolvimento que estima esforço

13.5.3.4. o time de desenvolvimento que gerencia suas atividades para alcançar os objetivos da Sprint

14. O time Scrum

14.1. Product Owner

14.1.1. O dono do produto representa Clientes, usuários e Stakeholders

14.1.2. Deve existir um para cada produto

14.1.2.1. O Product Owner é uma pessoa e não um comitê

14.1.2.2. Mas um PO pode representar vários produtos

14.1.2.3. Em uma organização pode existir um PO chefe para auxiliar os outros POs em diversos produtos

14.1.3. Responsabiliades

14.1.3.1. Ordenar os itens do Backlog do Produto

14.1.3.2. Responsável por maximizar o valor do produto

14.1.3.3. Responsável por gerenciar o Backlog do Produto.

14.1.3.4. Fornecer feedback na revisão da sprint

14.1.3.5. Defini a data que o incremento é liberado para produção

14.1.3.6. Fazer o planejamento das releases

14.1.3.7. Priorizar os itens do backlog do produto

14.1.3.8. Pode delegar suas atividades ao time desenvolvimento mas a responsabilidade continua sendo dele

14.1.3.9. Determinar os itens do backlog do produto junto as clientes e partes interessadas

14.2. Membros com diversas areas de conhecimentos necessários para o desenvolvimento da sprint

14.3. Development team

14.3.1. Só existe o titulo de desenvolvedor na equipe

14.3.2. Multifuncional

14.3.3. Tamanho do time

14.3.3.1. 6 +/- 3 pessoas

14.3.3.2. Máximo recomendado: 9 pessoas

14.3.3.3. Mínimo recomendado: 3 pessoas

14.3.3.4. Pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho

14.3.3.5. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem

14.3.4. Responsabilidades

14.3.4.1. Gerenciar/atualizar o backlog da sprint

14.3.4.2. Responsável pelo sucesso do projeto

14.3.4.3. Fornecer as estimativas

14.3.4.4. Realizar todas as atividades para produzir um incremento do produto

14.3.4.5. Criar uma definição de "pronto" e acordar com o Product Owner quando não existe uma definição padrão na organização

14.4. Scrum master

14.4.1. Um para cada time

14.4.2. Atua como lider

14.4.2.1. Responsável por remover impedimentos

14.4.2.2. Ensina o framework Scrum

14.4.3. Possui uma posição de gestão de processos

14.4.3.1. Lembre-se processo não pessoas

14.4.4. É responsável por garantir que o Scrum seja entendido e aplicado.

14.4.4.1. Responsável por mover impedimentos

14.4.5. Responsabilidades

14.4.5.1. É responsável por garantir que o Scrum seja entendido e aplicado.

14.4.5.2. Mediador entre as partes quando necessário

14.4.5.3. Facilitar os eventos Scrum conforme exigidos ou necessários

14.4.5.4. Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;

15. Eventos

15.1. Sprint

15.1.1. Duração máxima de um mês

15.1.2. Durante a sprint podem ser implementadas melhorias no processo

15.1.3. compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint

15.1.4. Deve ser entregue um incremento funcional e de valor ao negocio do cliente

15.1.5. Somente o Dono do Produto pode cancelar uma sprint

15.1.6. Não existe Sprint 0 para planejamento de infraestrutura ou qualquer outra preparação de ambiente

15.1.7. Termina quando sua time-box termina

15.1.7.1. Uma Sprint começa imediatamente quando a anterior termina

15.1.7.2. Os itens que não forem completados podem voltar para o backlog do produto e serão repriorizados pelo dono do produto

15.1.8. Mudanças devem ser evitadas quando a sprint está em execução

16. Artefatos

16.1. Incremento de software

16.1.1. Definição de "pronto"

16.1.1.1. Todos devem entender o que o “Pronto” significa

16.1.1.2. É usado para assegurar quando o trabalho esta completado no incremento do produto

16.1.1.3. Orienta o Time de Desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante a Reunião de Planejamento da Sprint

16.1.1.4. Se a definição de “pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem seguila como um mínimo.

16.1.1.5. Se “pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto

16.1.2. É a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores

16.1.3. Ao final da Sprint um novo incremento deve estar “Pronto”

16.1.4. Deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum

16.1.5. Product Owner decidir quando liberá-lo para produção

16.1.6. O Scrum Master deve trabalhar com o Product Owner, Time de desenvolvimento e outras partes envolvidas para entender se os artefatos estão plenamente transparentes

16.2. Backlog da sprint

16.2.1. É um artefato construído na cerimonia de planejamento da Sprint

16.2.2. Somente o time de desenvolvimento realiza alterações

16.2.3. Disponível para todos

16.2.4. Todas tarefas são de responsabilidade do time de desenvolvimento

16.2.5. No desenvolvimento tarefas podem serem acrescentadas

16.2.6. Formado por itens do backlog do produto mais as atividades necessárias para realizar o desenvolvimento do incremento

17. Transparência do artefato