Estudo Scrum

Get Started. It's Free
or sign up with your email address
Estudo Scrum by Mind Map: Estudo Scrum

1. 1 - Fundamentos

1.1. Não é uma metodologia. É um Framework

1.2. O desenvolvimento é iterativo e incremental

1.2.1. 2 a 4 semanas

1.2.2. Entregar mais valor agregado em menos tempo

1.2.3. Menos incertezas em função das entregas menores e mais rápidas

1.2.4. Rápida e contínua inspeção

1.3. Entrega de Valor

1.3.1. As necessidades do Negócio determinam a prioridade do desenvolvimento

1.3.2. O Product Owner é o responsável pelo ROI do Investimento

1.4. Maior foco nas Pessoas e menos no Processo

1.5. Processo Empírico

1.5.1. Aceita que um problema nem sempre é completamente entendido ou definido

1.5.2. Provoca resposta ágil e hábil da equipe aos desafios

1.5.3. Equipe se adequa rapidamente aos processos para buscar melhores resultados

1.6. O vocabulário do Scrum não deve ser alterado

1.7. Equipes auto-organizadas

1.7.1. Membros Multifuncionais

1.7.2. Não há GP e nem Líderes Funcionais

1.7.3. Pessoas comprometidas

1.7.4. O time determina as tarefas do backlog

1.7.5. As tarefas são do time e todos são responsáveis

1.7.6. Nem o Product Owner e o Scrum Master são chefes do time Development Team

1.8. Valores

1.8.1. Transparência

1.8.1.1. Informações visíveis e entendidas para todos e por todos

1.8.1.2. As estimativas são dadas de acordo com o que cada membro acredita

1.8.1.3. Os problemas não podem ser escondidos

1.8.2. Inspeção

1.8.2.1. Processos e práticas Scrum são verificados com frequencia

1.8.2.2. A inspeção é a base da adaptação

1.8.3. Adaptação

1.8.3.1. Os processos podem ser alterados para evitar erros e problemas

1.8.3.2. São feitas pelo Product Owner, Scrum Master e/ou Development Team

1.8.3.3. Inspeção e Adaptação são feitas nas reuniões

1.8.3.4. Ocorrendo um problema, uma ação de adaptação deve ser tomada imediatamente

2. 2 - Scrum Team

2.1. Product Owner

2.1.1. Pessoa do Negócio que representa clientes e usuários

2.1.2. Toda equipe Scrum deve ter um Product Owner (deve ser uma pessoa)

2.1.3. Responsabilidades

2.1.3.1. Estabelecer a visão do Produto

2.1.3.2. Maximizar o ROI

2.1.3.3. Dono do Product Backlog

2.1.3.4. Determina o Product Backlog junto ao Steakholders

2.1.3.5. Prioriza o Product Backlog

2.1.3.6. Tira as dúvidas do Product Backlog junto ao Development Team

2.1.3.7. Dá feedback na Reunião de Revisão da Sprint

2.1.3.8. Participa do Planejamento das Releases

2.2. Scrum Master

2.2.1. Servo-Líder que remove barreiras e dissemina conhecimento Scrum

2.2.2. Toda equipe Scrum deve ter um Scrum Master (que pode atuar em mais de um time)

2.2.3. É um gestor de processos e não de pessoas e não tem autoridade sobre o time

2.2.4. Responsabilidades

2.2.4.1. Garantir o uso correto do Scrum

2.2.4.2. Remover barreiras

2.2.4.3. Mediar as partes

2.2.4.4. Ensinar o Development Team a ser auto-organizado

2.2.4.5. Ajuda o Product Owner a gerenciar o Product Backlog

2.2.4.6. Procura sempre melhorar a eficiência e eficácia do time

2.3. Development Team

2.3.1. Pessoas comprometidas com o objetivo do projeto

2.3.2. Todos são considerados desenvolvedores (não há distinção)

2.3.3. Os membros devem ser multifuncionais, devem ter habilidades para fazer mais de uma atividade

2.3.4. Deve ser Cross-Funcional, possuindo membros com habilidades diferentes

2.3.5. Deve ser auto-organizado, não há líderes.

2.3.6. Deve possuir 6 (+-3) membros, ou seja, entre 3 e 9

2.3.7. Responsabilidades

2.3.7.1. Realização das atividades para concluir um Software Increment

2.3.7.2. Gerenciar a Sprint Backlog

2.3.7.3. Gerar as estimativas das atividades

3. 3 - Eventos

3.1. Sprint Planning

3.1.1. Time-Box: 8 horas (ou proporcional ao tamanho da Sprint)

3.1.2. Quando: 1a reunião da Sprint

3.1.3. Objetivos: Planejamento da Sprint, definir O QUE e COMO será feito

3.1.4. Dinâmica

3.1.4.1. Parte 1: O QUE fazer

3.1.4.1.1. Time-Box: 4 horas

3.1.4.1.2. Selecionar os Itens do Product Backlog

3.1.4.1.3. Definir a meta da Sprint

3.1.4.1.4. Presença do Product Owner é obrigatória

3.1.4.1.5. Development Team estima a complexidade do Itens

3.1.4.1.6. Development Team informa quantos Itens no Product Backlog será capaz de entregar

3.1.4.2. Parte 2: Como fazer

3.1.4.2.1. Time-Box: 4 horas

3.1.4.2.2. Identificar tarefas adicionais aos Itens do Product Backlog

3.1.4.2.3. Presença do Product Owner é opcional

3.1.4.2.4. Estimar as tarefas em horas

3.1.4.2.5. É criado o Backlog da Sprint

3.2. Sprint

3.2.1. Time-Box: 2 a 4 semanas

3.2.2. Objetivos: Gerar um incremento de software utilizável ( ou pronto) a partir da Sprint Backlog (consequentemente Product Backlog)

3.2.3. Cliclo

3.2.3.1. Sprint Planning

3.2.3.2. Daily Scrum

3.2.3.3. Execução das tarefas

3.2.3.4. Sprint Review

3.2.3.5. Sprint Restrospective

3.2.4. Principais regras

3.2.4.1. Só o Product Owner pode cancelar uma Sprint, caso haja justificativa

3.2.4.2. Termina sempre dentro do Time-Box

3.2.4.2.1. Se houver tempo, novas tarefas podem ser inseridas

3.2.4.2.2. Tarefas não cumpridas passam para próxima Sprint

3.2.4.3. Durante a execução, novos Itens da Backlog Sprint podem ser adicionados / removidos pelo Development Team

3.3. Daily Scrum

3.3.1. Time-Box: 15 minutos

3.3.2. Objetivos: Sincronizar e atualizar atividades e informações do Development Team, permitindo a inspeção e adaptação do processo.

3.3.3. Quando: Diariamente (exceto nos dias da Sprint Planning, Sprint Review e Sprint Retrospective)

3.3.4. TODOS os membros do Developmente Team devem participar (Scrum Master é opcional)

3.3.5. Dinâmica

3.3.5.1. Em pé (todos no mesmo local e na mesma hora)

3.3.5.2. Cada membro responde 3 perguntas

3.3.5.2.1. O que eu fiz desde a última Daily?

3.3.5.2.2. O que farei hoje?

3.3.5.2.3. Quais são os meus impedimentos?

3.4. Sprint Review

3.4.1. Time-Box: 4 horas

3.4.2. Quando: Fim da Sprint

3.4.3. Objetivos: Foco o PRODUTO, apresentar o resultado ao Product Owner

3.4.4. Todos participam

3.4.5. Product Owner fornece feedback do trabalho ao Development Team

3.4.6. Permite a inspeção e adaptação do Produto

3.5. Sprint Retrospective

3.5.1. Time-Box: 3 horas

3.5.2. Quando: Logo após a Sprint Review

3.5.3. Objetivos: Foco no PROCESSO, falar abertamente sobre o processo, o que foi bem, o que pode ser melhorado, lições aprendidas etc.

3.5.4. Todos participam (a presença do Product Owner é opcional)

4. 4 - Artefatos

4.1. Product Vision

4.1.1. Escopo do que será desenvolvido em alto nível

4.1.2. Problema a ser resolvido

4.2. Product BackLog

4.2.1. Lista de itens necessários para atender a Product Vision, feita pelo Product Owner (somente ele pode incluir, alterar, excluir e ordenar itens)

4.2.2. Define as regras de negócio e está sempre evoluindo

4.2.3. Visível a todo o Scrum Team

4.2.4. Existe apenas um Product Backlog, mesmo que existam várias equipes

4.3. Sprint Backlog

4.3.1. Itens selecionados do Product Backlog + Tarefas necessárias

4.3.1.1. Product Backlog e Development Team participam na listagem do Itens

4.3.1.2. Development Team determina as outras tarefas necessárias (presença do Product Owner é opcional)

4.3.1.2.1. Testes a Executar

4.3.1.2.2. Casos de uso

4.3.1.2.3. Histórias de usuários

4.3.2. Define o que será feito na Sprint

4.3.3. Visível a todo o Scrum Team

4.3.4. Pode fazer uso de um Kanban para gestão

4.3.5. As tarefas são de responsabilidades de todos do Development Team, ainda que um membro voluntariamente assuma alguma tarefa.

4.4. Increment

4.4.1. Entregue no final da Sprint, é o resultado do trabalho

4.4.2. Deve estar pronto e utilizável

4.4.3. O Product Owner determina a implantação em produção