Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Conteúdo do exame Professional Scrum Master I da Scrum.org by Mind Map: Conteúdo do exame
Professional Scrum 
Master I da Scrum.org
5.0 stars - 14 reviews range from 0 to 5

Conteúdo do exame Professional Scrum Master I da Scrum.org

Mapa desenvolvido pela TIEXAMES

www.tiexames.com.br

Não divulgar este material.

Somente alunos matriculados no curso devem usá-lo

Incluímos o essencial para o exame

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

Fundamentos do Scrum

Scrum é um framework e não uma metodologia

Indicado para gerenciar desenvolvimento de produtos complexos

Você pode empregar vários processos ou técnicas dentro deste framework

Adota o desenvolvimento iterativo e incremental

Entregas pequenas e parciais – 1 a 4 semanas

Entrega do maior valor agregado mais cedo

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

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

Entrega de valor

Necessidades do negócio determinam as prioridades do desenvolvimento

Dono do Produto é responsável por garantir o ROI do investimento

Foco mais nas pessoas e menos no processo

Processo empírico

Aceita que um problema não pode ser completamente entendido ou definido

Foca na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes

A equipe adapta os processos rapidamente para atingir melhores resultados

Não recomendado fazer alterações no vocábulario ao implantar na organização

Equipes devem ser auto-organizadas e autogerenciadas

Membros são multifuncionais, podem atuar em todas as atividades da Sprint

Não precisam de um gerente de projeto (Scrum Master é um Líder-servo e o PO se responsabiliza pelo produto)

Compostas por pessoas comprometidas

Determinam as tarefas necessárias para os itens selecionados para a Sprint

As tarefas são do Time de desenvolvimento e todos são responsáveis, ninguém individualmente se apropria de uma tarefa

Não há líderes funcionais dentro da equipe

Scrum Master e Dono do Produto não são chefes do Time de desenvolvimento

Pilares do Scrum

Transparência, Informações devem ser visíveis para todos, Informações são entendidas por todos da mesma maneira, Estimativas são dadas de acordo com o que cada membro do time de desenvolvimento realmente acredita, Problemas não podem ser escondidos, Comprometer-se somente com aquilo que se acredita

Inspeção, Processos, práticas e atividades devem ser inspecionados com frequência, A inspeção é a base para a adaptação

Adaptação, Alterações no processo para evitar erros e problemas, Feita pelo Time de desenvolvimento, Scrum master e Dono do produto, As diversas reuniões são aproveitadas para realizar inspeção e adaptação, Sempre que for dedectado um problema, uma ação de adaptação pode ser iniciada imediatamente

Valores do scrum

Comprometimento das pessoas em alcançar os objetivos do Time Scrum

Coragem para fazer a coisa certa e trabalhar em problemas difíceis

Foco no trabalho da Sprint e nos objetivos do Time Scrum

Transparência em relação ao trabalho que está sendo feito

Respeito uns aos outros para serem pessoas capazes e independentes

Papéis no Scrum

Scrum Team

Product Owner, Pode ser alguém da área de negócio, Representa clientes e usuários, É o único dono do Backlog do Produto, Deve existir um para cada Produto, Tem que ser uma única pessoa por produto, não pode ser um comitê, A mesma pessoa pode ser o PO de várias equipes, Quando um PO não consegue atender a várias equipes no mesmo Produto, então pode ser criada uma hierarquia onde há um PO chefe e alguns POs subordinados atendendo equipes individualmente, Principais Responsabilidades, Estabelecer a visão do produto, Maximizar o ROI do produto, Determinar os itens do Backlog do Produto junto as partes interessadas, Priorizar os itens do Backlog do Produto, Somente ele pode fazer isto, Tirar dúvidas do Time de desenvolvimento sobre os itens do Backlog do Produto, Fornecer feedback na Revisão da Sprint, Fazer o planejamento das Releases, Decidir quando liberar um incremento em produção

Scrum Master, Atua como líder-servo, Remove impedimentos do Time de desenvolvimento, Ensina o Time Scrum a usar o Scrum, Não tem autoridade sobre o time de desenvolvimento, mas pode fornecer auxílio quando solicitado, Deve existir um para cada Time Scrum, Mas pode uma única pessoa ser Scrum Master de várias equipes, É uma posição de gestão, Porém de gestão de processo e não de pessoas, Principais Responsabilidades, Garantir o uso correto do Scrum, Remover impedimentos do Time de Desenvolvimento, Atuar como mediador entre as partes, somente quando for necessário, Ensinar a equipe a ser auto-organizada e autogerenciada, Disseminar a cultura do Scrum na organização, Auxiliar o Dono do Produto no gerenciamento do Backlog do Produto ensinando técnicas para isto, Sugerir melhorias para aumentar a eficiência e eficácia do Time de desenvolvimento, Deve garantir / facilitar a realização de todos os eventos do Scrum, Ele só não participa como membro da Reunião Diária, mas deve garantir que ela ocorra

Development Team, Formado por pessoas comprometidas com os objetivos do projeto, Todos os membros são DESENVOLVEDORES, Não há papéis específicos, como testador, Os membros devem ser multifucionais, Os membros devem ter todas as habilidades necessárias para o trabalho na Sprint, Membros podem realizar mais de uma função/atividade, Deve ser cross-funcional, Inclui membros com diversos conhecimentos necessários, Deve ser auto-organizado, Não há líderes dentro do time, Os membros se organizam da melhor forma para realizar o trabalho da Sprint, Tamanho ideal, 6 +/- 3 pessoas, Máximo recomendado: 9 pessoas, Mínimo recomendado: 3 pessoas, Principais responsabilidades, Responsável pelo sucesso do projeto, Realizar todas as atividades para produzir um incremento de software, Gerenciar/atualizar o Backlog da Sprint, Fornecer as estimativas para os Itens do Backlog do Produto, Criar uma definição de "Pronto" e acordar com o Product Owner quando esta definição não existir na organização como sendo um padrão para todos os projetos

Eventos no Scrum

Importante saber

Scrum Master deve garantir a realização de todos os eventos, mas não necessariamente ele participará de todos. Ele não participa da reunião Diária que é exclusiva para os membros do time de desenvolvimento. Todos os outros ele participará.

Todos os eventos no Scrum são time-boxed

Sprint

Duração máxima de um mês, A duração pode ser baseada em diversos fatores, Nível de incerteza da tecnologia a ser usada, Frequência de alterações na equipe, Nível de risco aceitável pelo dono do produto, Alinhamento com eventos do negócio (releases, por exemplo)

É o momento em que é feito o trabalho para transformar os itens do Backlog do Produto selecionados em incremento de software funcionando

Composição, Dentro de uma Sprint irá ocorrer reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.

Toda Sprint feve gerar no final um incremento de software potencialmente utilizável e "Pronto", Importante que o Time de desenvolvimento estabeleça a Definição de "Pronto", se esta definição não existir na organização

Não existe Sprint 0 no Scrum Guide para planejamento de infraestrutura/arquitetura, isto tem que ser feito ao longo das Sprints

Inicia-se junto com a reunião de planejamento da Sprint e termina junto com a reunião de Retrospectiva

Termina quando sua time-box termina, Se sobrar tempo, novos itens do Backlog do Produto podem ser selecionados e desenvolvidos, Os itens que não forem completados podem voltar para o Backlog do Produto e serão repriorizados pelo Dono do Produto, Uma vez que termina uma Sprint, uma nova já é iniciada imediatamente

Mudanças devem ser evitadas quando a Sprint está em execução

Somente o Dono do Produto pode cancelar uma Sprint antes do seu término

Durante a Sprint novas tarefas podem ser identificadas pelo Time de desenvolvimento para os itens do Backlog do Produto já selecionados

Itens do Backlog da Sprint podem ser removidos ou alterados se o Time de desenvolvimento perceber que não dará conta de fazer tudo

Durante a Sprint podem ser implementadas melhorias no processo sempre que for necessário

Planejamento da Sprint

Primeiro evento que ocorre na Sprint

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

Todos do Time Scrum participam

Time-box de 8 horas para uma Sprint de um mês, Proporcionalmente menor para Sprints menores, 2 horas para cada semana de duração da Sprint

Trata de dois tópicos, Tópico 1, O que faremos?, Seleção de itens do Backlog do Produto, Define meta/objetivo da Sprint, O que deve ser alcançado ao final da Sprint, É acordado com todo o Time Scrum, Participação do Dono do Produto é fundamental para definir O QUE fazer, Itens são estimados em complexidade pelo Time de desenvolvimento, Somente o Time de desenvolvimento deve dizer quantos itens é capaz de entregar no final da Sprint, Tópico 2, Como faremos?, O Time de desenvolvimento identifica as tarefas necessárias para os itens do Backlog selecionados para a Sprint, Tarefas podem ser estimadas em horas, É criado o Backlog da Sprint (uma saída principal da Reunião de Planejamento)

Reunião Diária

Serve para sincronização das informações e atividades entre os membros do Time de Desenvolvimento

Permite a inspeção e adaptação do processo de forma rápida e antecipada

Somente os membros do Time de Desenvolvimento devem participar, Partipação de todos os membros deste time é obrigatória, Membros atualizam status das suas atividades antes da reunião

Sempre um time-box de 15 minutos, Independente da duração da Sprint

Ocorre todos os dias, exceto quando tem as reuniões de planejamento, revisão e retrospectiva da Sprint

É mantida no mesmo horário e local todo dia para reduzir a complexidade

Presença do Scrum Master é opcional, Scrum Master apenas deve garantir / facilitar a sua realização, A condução da reunião é feita pelo Time de desenvolvimento

Membros respondem a 3 perguntas, O que eu fiz desde a última reunião?, O que eu vou fazer até a próxima reunião diária?, Tem alguma coisa impedindo o meu trabalho?

Revisão da Sprint

Serve para inspecionar o incremento gerado na Sprint e adaptar o Backlog do Produto se necessário

Ocorre no final de cada Sprint

Foco no produto e não no processo

Todos do Time Scrum participam, O Product Owner pode convidar stakeholders chave para ajudar na validação do incremento

Time-box de 4 horas para Sprint de um mês, Proporcionalmente menor para Sprints menores, É uma hora para cada semana de duração da Sprint

Dono do Produto fornece feedback para o Time de desenvolvimento sobre o trabalho realizado

Retrospectiva da Sprint

É uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint

Ocorre logo após a Revisão de cada Sprint

Time-box de 3 horas para uma Sprint de um mês, Proporcionalmente menor para Sprints menores

Todos do Time Scrum participam, 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

Foco na melhoria do processo e não no produto

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

Resulta em itens de melhoria para o processo Scrum

Artefatos no Scrum

Backlog do Produto

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

Somente o Dono do Produto pode incluir, alterar, ordenar itens

Está em constante evolução, Deve refletir as mudanças no negócio

Disponível para todos visualizar

Recomenda-se apenas um Backlog do Produto, mesmo que haja várias equipes trabalhando no mesmo produto

Dono do Produto deve ordenar os itens de acordo com os melhores critérios que julgar

O seu refinamento pode ser feito pelo Dono do Produto e Time de desenvolvimento, Convém que o tempo para isto não ultrapasse 10% da capacidade do Time de desenvolvimento

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

As estimativas dos itens são feitas somente pelo Time de Desenvolvimento

Backlog da Sprint

É uma saída principal gerada na reunião planejamento da Sprint

Inclui Itens selecionados do Backlog do Produto + tarefas necessárias, Pode conter, Tarefas, Testes a executar, Casos de uso, História de usuário

Novas tarefas podem ser adicionadas durante a Sprint, Lembrar que o detalhamento das tarefas pode  continuar durante a Sprint

Somente o Time de Desenvolvimento pode alterar durante a Sprint

Vísivel para todos, Pode ser apresentado em um quadro Kanban para tornar visível para todos

Todas as tarefas são de responsabilidade do Time de Desenvolvimento, Um membro pode voluntariamente assumir uma tarefa para fazer, mas todos são donos de todas as tarefas

Incremento de Software

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

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

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

Quando fizer sentido, o Dono do Produto decidirá a sua implantação no ambiente de produção

Ferramentas / Técnicas extras

Lembrar que estas ferramentas/técnicas são usadas na prática, mas não são obrigatórias no Scrum Guide

Gráfico Burndown da Sprint

Mostra a quantidade de ​trabalho restante em uma Sprint

É uma ferramenta com objetivo primário de servir o time de desenvolvimento

O time de desenvolvimento deve atualizar, Lembrar que a equipe é autogerenciada

Útil para fazer o monitoramento do andamento da Sprint

É uma ferramenta para gestão à vista e depende da transparência dos membros da equipe

Gráfico Burndown da Release

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

É uma "foto" da situação atual

Deve ser atualizado toda vez que o backlog do produto mudar

O Dono do Produto é responsável pela atualização

Planejamento de Release

Dono do Produto é responsável por realizar o plano de releases

Ao final de cada Sprint, o Dono do Produto decidirá se implanta o incremento liberado em produção

Transparência do Artefato

O Scrum Master deve trabalhar com o Time Scrum para garantir que estão sendo utilizadas práticas para favorecer a transparência

Definição de "Pronto"

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

Orienta o time de desenvolvimento de quantos itens do Backlog do Produto podem ser selecionados durante a Reunião de Planejamento

Pode fazer parte das convenções, padrões ou diretrizes de desenvolvimento da organização

Se esta definição é particular de cada projeto, então cabe ao Time de Desenvolvimento definir uma definição de "Pronto" apropriada

Se houver vários Times Scrum trabalhando no mesmo produto, então a mesma definição deve ser acordada entre os times.