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

1. Somente alunos matriculados no curso devem usá-lo

2. teste

3. Todos os membros são DESENVOLVEDORES

3.1. Não há papéis específicos, como testador ou analista de negócio

4. Scrum é um framework e não uma metodologia

4.1. Indicado para gerenciar desenvolvimento de produtos complexos

4.2. Propositalmente está incompleto, para que se possa empregar vários processos, técnicas e métodos com o framework

4.3. Porém não não é recomendado fazer alterações no vocabulário Scrum ao implantar na organização

5. Times devem ser autogerenciados

6. Responsabilidades no Scrum

6.1. Scrum Team

6.1.1. Os membros são multifuncionais - podem atuar em todas as atividades da sprint

6.1.2. São autogerenciáveis

6.1.2.1. Os membros decidem internamente quem faz o quê, quando e como

6.1.3. São multifuncionais

6.1.3.1. Os membros possuem todas as habilidades necessárias para criar valor a cada Sprint

6.1.4. Tamanho ideal: 10 ou menos pessoas

6.1.5. Inclui também o Product Owner e Scrum Master

6.1.6. O time inteiro é responsável por criar um Incremento valioso e útil a cada Sprint

6.1.6.1. Trabalham em ritmo sustentável

6.1.6.1.1. Horas extras não é uma boa prática

6.1.6.2. Coragem

6.1.6.2.1. Os membros do Scrum Team têm a coragem de, fazer a coisa certa e trabalhar em problemas difíceis

6.1.7. Responsabilidades específicas

6.1.7.1. Developers

6.1.7.1.1. Pessoas comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint.

6.1.7.1.2. Pode existir diferentes habilidades específicas de acordo com o produto que será desenvolvido

6.1.7.1.3. Principais responsabilidades

6.1.7.2. Product Owner

6.1.7.2.1. Pode ser alguém da área de negócio

6.1.7.2.2. Representa clientes e usuários

6.1.7.2.3. É o único dono do backlog do produto

6.1.7.2.4. Deve existir um para cada produto

6.1.7.2.5. Toda a organização deve respeitar suas decisões

6.1.7.2.6. Principais responsabilidades

6.1.7.3. Scrum master

6.1.7.3.1. Estabelece o Scrum conforme definido no Scrum Guide

6.1.7.3.2. Responsável pela eficácia do Scrum Team

6.1.7.3.3. São verdadeiros líderes que servem ao Scrum Team

6.1.7.3.4. Deve existir um para cada time

6.1.7.3.5. É uma posição de gestão

6.1.7.3.6. Principais responsabilidades

7. Determinam as tarefas necessárias para os itens selecionados para a sprint

8. www.tiexames.com.br

8.1. Mapa desenvolvido pela TIEXAMES

8.2. Não há garantia de aprovação no examep apenas decorando este mapa

8.2.1. Não divulgue este material

8.3. Incluímos o essencial para o exame

9. Fundamentos do Scrum

9.1. Emprega abordagem iterativa e incremental

9.1.1. Entregas pequenas e parciais a cada mês, pelo menos

9.1.2. Entrega do maior valor agregado mais cedo

9.1.3. Redução das incertezas por meio de entregas menores e rápidas

9.1.4. Permite a rápida e contínua inspeção

9.1.5. As necessidades do negócio determinam as prioridades do desenvolvimento

9.2. Foca na entrega de valor

9.2.1. O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team

9.3. Não precisam de um gerente de projeto (o Scrum master é um líder-servo e o PO se responsabiliza pelo produto)

9.3.1. Compostas por pessoas comprometidas

9.4. Não há líderes funcionais dentro do time

9.5. Pilares do Scrum

9.5.1. Transparência

9.5.1.1. Informações devem ser visíveis para todos

9.5.1.2. Problemas não podem ser escondidos

9.5.1.3. Informações são entendidas por todos da mesma maneira

9.5.1.4. Estimativas são dadas de acordo com o que cada desenvolvedor realmente acredita

9.5.1.5. Comprometer-se somente com aquilo que se acredita

9.5.2. Inspeção

9.5.2.1. Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados com frequência.

9.5.2.2. A inspeção é a base para a adaptação

9.6. Adaptação

9.6.1. Alterações no processo para evitar erros e problemas

9.6.2. Feita pelo Time Scrum

9.6.3. Os eventos do Scrum são aproveitadas para realizar inspeção e adaptação

9.6.4. O ajuste deve ser feito o mais rápido possível para minimizar novos desvios.

9.6.5. Espera-se que um Scrum Team se adapte no momento em que aprende algo novo por meio da inspeção

9.7. Valores do Scrum

9.7.1. Compromisso

9.7.1.1. O Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros

9.7.2. Foco

9.7.2.1. O foco principal do Time Scrum é o trabalho da Sprint para fazer o melhor progresso possível em direção a essas metas.

9.7.3. Abertura

9.7.3.1. O Scrum Team e seus stakeholders são abertos quanto ao trabalho e os desafios

9.7.4. Respeito

9.7.4.1. Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham.

9.8. Scrum é baseado no empirismo e lean thinkin

9.8.1. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado.

9.8.2. O lean thinking reduz o desperdício e se concentra no essencial.

10. Eventos no Scrum

10.1. Importante saber

10.1.1. O Scrum master deve garantir a realização de todos os eventos, mas não necessariamente participará de todos; ele não participa da reunião diária que é voltada para os desenvolvedores, mas de todos os outros eventos ele participará

10.1.2. Todos os eventos no Scrum são time-boxed

10.1.3. Todos os eventos são uma oportunidade para inspecionar e adaptar os artefatos do Scrum

10.1.4. O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade

10.2. Sprint

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

10.2.1.1. A duração pode ser baseada em diversos fatores

10.2.1.1.1. Nível de incerteza da tecnologia a ser usada

10.2.1.1.2. Frequência de alterações no Time Scrum

10.2.1.1.3. Nível de risco aceitável

10.2.1.1.4. Alinhamento com eventos do negócio (releases, por exemplo)

10.2.2. É o momento em que é feito o trabalho para transformar os itens do backlog do produto selecionados em incremento de produto funcionando

10.2.3. Composição

10.2.3.1. A Sprint é um contêiner para todos os outros eventos

10.2.3.2. Dentro de uma sprint ocorrem a reunião de planejamento da sprint, as reuniões diárias, o trabalho de desenvolvimento, uma revisão da sprint e a retrospectiva da sprint

10.2.4. Toda Sprint deve gerar no final um incremento de produto utilizável de acordo com a Definição de Pronto

10.2.5. Não existe sprint 0 no Scrum Guide para planejamento de infraestrutura/arquitetura (isto deve ser feito ao longo das sprints)

10.2.6. Inicia-se junto com a reunião de planejamento da sprint e termina junto com a reunião de retrospectiva

10.2.7. Termina quando sua time-box termina

10.2.7.1. Se sobrar tempo, novos itens do backlog do produto podem ser selecionados e desenvolvidos

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

10.2.7.3. Uma vez que termina uma sprint, uma nova sprint já é iniciada imediatamente

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

10.2.9. Somente o Product Owner o pode cancelar uma sprint antes do seu término

10.2.10. Durante a sprint, novas tarefas podem ser identificadas pelos Desenvolvedores para os itens do backlog do produto já selecionados

10.2.11. Itens do backlog da sprint podem ser removidos ou alterados se os Desenvolvedores perceberem que não darão conta de fazer tudo

10.2.11.1. Há necessidade de acordar com o Product Owber o que vai ser removido

10.2.12. Durante a sprint podem ser implementadas melhorias no processo sempre que for necessário

10.3. Planejamento da Sprint

10.3.1. Primeiro evento que ocorre na sprint

10.3.2. Serve para definir O QUE precisa ser feito e COMO deve ser feito

10.3.3. Todos do Time Scrum participam

10.3.4. Time-box de 8 horas para uma sprint de um mês

10.3.4.1. Proporcionalmente menor para sprints menores

10.3.4.2. 2 horas para cada semana de duração da sprint

10.3.5. Trata de 3 tópicos

10.3.5.1. Tópico 1

10.3.5.1.1. Por que esta Sprint é valiosa?

10.3.5.1.2. Define a Meta da Sprint

10.3.5.2. Tópico 2

10.3.5.2.1. O que pode ser feito nesta Sprint?

10.3.5.2.2. Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O

10.3.5.2.3. Participação do Product Owner é fundamental para definir O QUE fazer

10.3.5.2.4. Somente os Desenvolvedores podem dizer quantos itens são capazes de entregar no final da sprint

10.3.5.3. Tópico 3

10.3.5.3.1. Como o trabalho escolhido será realizado?

10.3.5.3.2. Os Desenvolvedores identificam as tarefas necessárias para os itens do backlog selecionados para a sprint (de acordo com a Definição de Pronto)

10.3.5.3.3. Cabe somente aos Desenvolvedores decompor os itens do Backlog do Produto em trabalhos menores

10.3.5.3.4. É criado o backlog da sprint (uma saída principal da reunião de planejamento)

10.4. Reunião diária

10.4.1. Seu propósito é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado.

10.4.2. É uma reunião dedicada aos Desenvolvedores

10.4.2.1. A participação de todos os desenvolvedores é obrigatória

10.4.2.2. Desenvolvedores atualizam status das suas atividades antes da reunião

10.4.3. Sempre uma time-box de 15 minutos

10.4.3.1. Independente da duração da sprint

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

10.4.5. É mantida no mesmo horário e local todos os dias para reduzir a complexidade

10.4.6. A presença do Scrum master e Product Onwer é opcional

10.4.6.1. O Scrum master apenas deve garantir/facilitar a sua realização

10.4.6.2. A condução da reunião é feita pelos Desenvolvedores

10.4.6.3. Outros papéis podem estar presentes, se houver necessidade (faz parte da transparência)

10.5. Revisão da Sprint

10.5.1. Seu propósito é inspecionar o resultado da Sprint e determinar as adaptações futuras.

10.5.2. Ocorre no final de cada Sprint

10.5.3. Maior foco no produto e não no processo

10.5.3.1. O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido.

10.5.4. Todos do Time Scrum participam

10.5.4.1. Pode ser convidados stakeholders-chave para ajudar na verificação do incremento

10.5.5. Time-box de 4 horas para sprint de um mês

10.5.5.1. Proporcionalmente menor para Sprints menores

10.5.5.2. É uma hora para cada semana de duração da Sprint

10.5.6. Como resultado, o Product Backlog pode ser ajustado para atender a novas oportunidades

10.6. Retrospectiva da Sprint

10.6.1. Seu propósito é planejar maneiras de aumentar a qualidade e a eficácia.

10.6.2. Ocorre logo após a revisão de cada Sprint

10.6.3. Time-box de 3 horas para uma Sprint de um mês

10.6.3.1. Proporcionalmente menor para sprints menores

10.6.4. Todos do Time Scrum participam

10.6.4.1. O Scrum master também é um membro desta reunião devido a ele ser responsável pelo processo Scrum, o qual também é objeto de melhoria

10.6.5. Maior foco na melhoria do processo e não no produto

10.6.5.1. O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto.

10.6.5.2. O Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvido

10.6.6. Cada membro do Time Scrum deve falar abertamente sobre o que considera que foi bem e o que deve ser melhorado

10.6.7. O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia

10.6.7.1. As melhorias mais impactantes são endereçadas o mais rápido possível

10.6.7.2. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint.

11. Artefatos no Scrum

11.1. Importante saber

11.1.1. Os artefatos no Scrum são projetados para maximizar a transparência das principais informações

11.1.2. Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso pode ser medido

11.1.2.1. Para o Product Backlog, é a Meta do produto.

11.1.2.2. Para o Sprint Backlog, é a Meta da Sprint.

11.1.2.3. Para o incremento, é a Definição de Pronto

11.2. Backlog do produto

11.2.1. O Product Owner é o "dono" do Backlog do Produto

11.2.1.1. Isso significa que cabe a ele decidir o que entra ou sai desse Backlog

11.2.2. É uma lista ordenada de tudo aquilo que pode ser necessário no produto

11.2.2.1. Se espera que aquilo que tenha maior valor tenha uma prioridade maior.

11.2.3. O progresso é medido pela Meta do produto

11.2.3.1. É objetivo de longo prazo para o Scrum Team

11.2.4. Está em constante evolução

11.2.4.1. Deve refletir as mudanças no negócio

11.2.5. Disponível para todos visualizarem (transparência)

11.2.6. Recomenda-se apenas um Backlog do Produto, mesmo que haja vários Times trabalhando no mesmo produto

11.2.7. As estimativas dos itens devem ser feitas por quem vai realizar o trabalho (no caso, os Desenvolvedores)

11.3. Backlog da sprint

11.3.1. É uma saída principal gerada na reunião Planejamento da Sprint

11.3.2. É composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como)

11.3.2.1. Esta meta é criada durante o evento Sprint Planning

11.3.2.2. Pode conter como itens

11.3.2.2.1. Tarefas

11.3.2.2.2. Testes a executar

11.3.2.2.3. Casos de uso

11.3.2.2.4. História de usuário

11.3.3. O progresso é medido pela Meta da Sprint

11.3.3.1. Conforme os Developers trabalham durante a Sprint, eles mantêm a Meta da Sprint em mente. S

11.3.3.2. O escopo do Backlog da Sprint pode ser negociado com o Product Owner durante a Sprint, mas sem afetar esta Meta

11.3.4. É um plano feito por e para os Developers

11.3.5. Novas tarefas podem ser adicionadas durante a Sprint

11.3.5.1. Lembre que o detalhamento das tarefas pode continuar durante a sprint

11.3.6. Visível para todos (transparência)

11.3.6.1. Pode ser apresentado em um quadro kanban para ser visível para todos

11.3.7. Todas as tarefas são de responsabilidade do Time Scrum, ninguém vira dono exclusivo de um item

11.3.7.1. Um desenvolvedor pode voluntariamente assumir uma tarefa para fazer, mas todos são donos de todas as tarefas

11.3.8. O seu refinamento pode ser feito pelo Product Owner com apoio dos Desenvolvedores

11.3.8.1. Esta é uma atividade contínua

11.3.8.2. Ideal que os itens esteja preparados (ready) para seleção durante a Reunião de Planejamento da Sprint

11.3.8.3. Cabe aos desenvolvedores o dimensionamento dos itens do Backlog do Produto

11.3.8.4. Os itens com prioridade maior terão maior detalhamento para estarem preparados para entrar na próxima sprint

11.4. Incremento

11.4.1. É a soma de todos os itens do backlog do produto completados durante a sprint e o valor dos incrementos de todas as sprints anteriores

11.4.2. Ao final da sprint um novo incremento deve estar “pronto”

11.4.3. Deve estar na condição utilizável e atender à definição de “pronto” do time Scrum

11.4.4. Quando julgar que faz sentido, o Product Owner decidirá a sua implantação no ambiente de produção

11.4.5. Definição de "Pronto"

11.4.5.1. É usada para definir quando o trabalho está completado no incremento do produto

11.4.5.2. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Revie

11.4.5.3. Orienta os Desenvolvedores sobre quantos itens do backlog do produto podem ser selecionados durante a reunião de planejamento

11.4.5.4. Se fizer parte de convenções, padrões ou diretrizes de desenvolvimento da organização, então todos os Times Scrum devem seguir o que já existe

11.4.5.5. Se esta definição é particular de cada projeto, então cabe ao Time Scrum criar uma definição de "pronto" apropriada

11.4.5.6. Se houver vários times Scrum trabalhando no mesmo produto, então a mesma definição deve ser acordada entre os times para que os incrementos possam ser integrados

12. Ferramentas/técnicas complementares

12.1. Lembre que estas ferramentas/técnicas são usadas na prática, mas não são obrigatórias segundo o Scrum Guide

12.2. Gráfico burndown da sprint

12.2.1. É uma ferramenta com objetivo primário de servir ao time de desenvolvimento

12.2.2. Os desenvolvedores podem atualizar

12.2.2.1. Lembre que a equipe é autogerenciada

12.2.3. Mostra a quantidade de ​trabalho restante em uma sprint

12.2.4. Útil para fazer o monitoramento do andamento da sprint

12.2.5. É uma ferramenta de gerenciamento visual e depende da transparência dos membros do time

12.3. Gráfico burndown da release

12.3.1. Mostra a quantidade de trabalho restante para concluir o backlog do produto naquele instante

12.3.2. O Product Owner é responsável por realizar o plano de releases

12.3.3. É uma "foto" da situação atual

12.3.4. Deve ser atualizado toda vez que o backlog do produto mudar

12.3.5. O Product Owner é responsável pela atualização

12.4. Planejamento da release

12.4.1. Ao final de cada sprint, o Product Owner decidirá se implanta o incremento liberado em produção

13. Incremento de Requisitos