1. Mapa desenvolvido pela TIEXAMES
1.1. www.tiexames.com.br
1.2. Não divulgue este material
1.3. Somente alunos matriculados no curso devem usá-lo
1.4. Incluímos o essencial para o exame
1.5. Não há garantia de aprovação no examep apenas decorando este mapa
2. Fundamentos do Scrum
2.1. Scrum é um framework e não uma metodologia
2.1.1. Indicado para gerenciar desenvolvimento de produtos complexos
2.1.2. Você pode empregar vários processos ou técnicas dentro deste framework
2.2. Adota o desenvolvimento iterativo e incremental
2.2.1. Entregas pequenas e parciais de 1 a 4 semanas
2.2.2. Entrega do maior valor agregado mais cedo
2.2.3. Redução das incertezas por meio de entregas menores e rápidas
2.2.4. Permite a rápida e contínua inspeção
2.3. Entrega de valor
2.3.1. As necessidades do negócio determinam as prioridades do desenvolvimento
2.3.2. O Dono do Produto é responsável por garantir o ROI do investimento
2.4. Foco mais nas pessoas e menos no processo
2.5. Processo empírico
2.5.1. Aceita que um problema não pode ser completamente entendido ou definido
2.5.2. Foca na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes
2.5.3. A equipe adapta os processos rapidamente para atingir melhores resultados
2.6. Não é recomendado fazer alterações no vocabulário ao implantar na organização
2.7. Equipes devem ser auto-organizadas e autogerenciadas
2.7.1. Os membros são multifuncionais - podem atuar em todas as atividades da sprint
2.7.2. Não precisam de um gerente de projeto (o Scrum master é um líder-servo e o PO se responsabiliza pelo produto)
2.7.3. Compostas por pessoas comprometidas
2.7.4. Determinam as tarefas necessárias para os itens selecionados para a sprint
2.7.5. As tarefas são do time de desenvolvimento e todos são responsáveis; ninguém individualmente se apropria de uma tarefa
2.7.6. Não há líderes funcionais dentro da equipe
2.7.7. O Scrum master e o Dono do Produto não são chefes do Time de desenvolvimento
2.8. Pilares do Scrum
2.8.1. Transparência
2.8.1.1. Informações devem ser visíveis para todos
2.8.1.2. Informações são entendidas por todos da mesma maneira
2.8.1.3. Estimativas são dadas de acordo com o que cada membro do time de desenvolvimento realmente acredita
2.8.1.4. Problemas não podem ser escondidos
2.8.1.5. Comprometer-se somente com aquilo que se acredita
2.8.2. Inspeção
2.8.2.1. Processos, práticas e atividades devem ser inspecionados com frequência
2.8.2.2. A inspeção é a base para a adaptação
2.8.3. Adaptação
2.8.3.1. Alterações no processo para evitar erros e problemas
2.8.3.2. Feita pelo time de desenvolvimento, Scrum master e Dono do Produto
2.8.3.3. As diversas reuniões são aproveitadas para realizar inspeção e adaptação
2.8.3.4. Sempre que for detectado um problema, uma ação de adaptação pode ser iniciada imediatamente
2.9. Valores do Scrum
2.9.1. Coragem
2.9.1.1. O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis.
2.9.2. Foco
2.9.2.1. Todos focam no trabalho da Sprint e nos objetivos do Time Scrum.
2.9.3. Comprometimento
2.9.3.1. As pessoas se comprometem pessoalmente em alcançar os objetivos do Time Scrum.
2.9.4. Respeito
2.9.4.1. Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes.
2.9.5. Abertura
2.9.5.1. O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a execução dos trabalhos.
3. Papéis no Scrum
3.1. Scrum team
3.1.1. Product Owner
3.1.1.1. Pode ser alguém da área de negócio
3.1.1.2. Representa clientes e usuários
3.1.1.3. É o único dono do backlog do produto
3.1.1.4. Deve existir um para cada produto
3.1.1.4.1. Deve ser uma única pessoa por produto, não pode ser um comitê
3.1.1.4.2. A mesma pessoa pode ser o PO de várias equipes
3.1.1.4.3. 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 a equipes individualmente
3.1.1.5. Principais responsabilidades
3.1.1.5.1. Estabelecer a visão do produto
3.1.1.5.2. Maximizar o ROI do produto
3.1.1.5.3. Determinar os itens do backlog do produto junto com as partes interessadas
3.1.1.5.4. Priorizar os itens do backlog do produto
3.1.1.5.5. Tirar dúvidas do time de desenvolvimento sobre os itens do backlog do produto
3.1.1.5.6. Fornecer feedback na revisão da sprint
3.1.1.5.7. Fazer o planejamento das releases
3.1.1.5.8. Decidir quando liberar um incremento em produção
3.1.2. Scrum master
3.1.2.1. Atua como líder-servo
3.1.2.1.1. Remove impedimentos do time de desenvolvimento
3.1.2.1.2. Ensina o time Scrum a usar o Scrum
3.1.2.1.3. Não tem autoridade sobre o time de desenvolvimento, mas pode fornecer auxílio quando solicitado
3.1.2.2. Deve existir um para cada time Scrum
3.1.2.2.1. Mas uma única pessoa pode ser Scrum master de vários times
3.1.2.3. É uma posição de gestão
3.1.2.3.1. Porém de gestão de processo e não de pessoas
3.1.2.4. Principais responsabilidades
3.1.2.4.1. Garantir o uso correto do Scrum
3.1.2.4.2. Remover impedimentos do time de desenvolvimento
3.1.2.4.3. Atuar como mediador entre as partes, somente quando for necessário
3.1.2.4.4. Ensinar a equipe a ser auto-organizada e autogerenciada
3.1.2.4.5. Disseminar a cultura do Scrum na organização
3.1.2.4.6. Auxiliar o Dono do Produto no gerenciamento do backlog do produto ensinando técnicas para isto
3.1.2.4.7. Sugerir melhorias para aumentar eficiência e eficácia do time de desenvolvimento
3.1.2.4.8. Deve garantir/facilitar a realização de todos os eventos do Scrum
3.1.3. Development team
3.1.3.1. Formado por pessoas comprometidas com os objetivos do projeto
3.1.3.2. Todos os membros são DESENVOLVEDORES
3.1.3.2.1. Não há papéis específicos, como testador
3.1.3.3. Os membros devem ser multifuncionais
3.1.3.3.1. Os membros devem ter todas as habilidades necessárias para o trabalho na sprint
3.1.3.3.2. Membros podem realizar mais de uma função/atividade
3.1.3.4. Deve ser multifuncional
3.1.3.4.1. Inclui membros com diversos conhecimentos necessários
3.1.3.5. Deve ser auto-organizado
3.1.3.5.1. Não há líderes dentro do time
3.1.3.5.2. Os membros se organizam da melhor forma para realizar o trabalho da sprint
3.1.3.6. Tamanho ideal
3.1.3.6.1. 6 +/- 3 pessoas
3.1.3.6.2. Máximo recomendado: 9 pessoas
3.1.3.6.3. Mínimo recomendado: 3 pessoas
3.1.3.7. Principais responsabilidades
3.1.3.7.1. Fornecer as estimativas para os itens do backlog do produto
3.1.3.7.2. Responsável pelo sucesso do projeto
3.1.3.7.3. Realizar todas as atividades para produzir um incremento de software
3.1.3.7.4. Gerenciar/atualizar o backlog da sprint
3.1.3.7.5. 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
4. Eventos no Scrum
4.1. Importante saber
4.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 é exclusiva para os membros do time de desenvolvimento, mas de todos os outros eventos ele participará
4.1.2. Todos os eventos no Scrum são time-boxed
4.2. Sprint
4.2.1. Duração máxima de um mês
4.2.1.1. A duração pode ser baseada em diversos fatores
4.2.1.1.1. Nível de incerteza da tecnologia a ser usada
4.2.1.1.2. Frequência de alterações na equipe
4.2.1.1.3. Nível de risco aceitável pelo Dono do Produto
4.2.1.1.4. Alinhamento com eventos do negócio (releases, por exemplo)
4.2.2. É o momento em que é feito o trabalho para transformar os itens do backlog do produto selecionados em incremento de software funcionando
4.2.3. Composição
4.2.3.1. 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
4.2.4. Toda sprint deve gerar no final um incremento de software potencialmente utilizável e "pronto"
4.2.4.1. É importante que o time de desenvolvimento estabeleça a definição de "pronto" se esta definição não existir na organização
4.2.5. Não existe sprint 0 no Scrum Guide para planejamento de infraestrutura/arquitetura (isto deve ser feito ao longo das sprints)
4.2.6. Inicia-se junto com a reunião de planejamento da sprint e termina junto com a reunião de retrospectiva
4.2.7. Termina quando sua time-box termina
4.2.7.1. Se sobrar tempo, novos itens do backlog do produto podem ser selecionados e desenvolvidos
4.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
4.2.7.3. Uma vez que termina uma sprint, uma nova sprint já é iniciada imediatamente
4.2.8. Mudanças devem ser evitadas quando a sprint está em execução
4.2.9. Somente o Dono do Produto pode cancelar uma sprint antes do seu término
4.2.10. Durante a sprint novas tarefas podem ser identificadas pelo time de desenvolvimento para os itens do backlog do produto já selecionados
4.2.11. Itens do backlog da sprint podem ser removidos ou alterados se o time de desenvolvimento perceber que não dará conta de fazer tudo
4.2.12. Durante a sprint podem ser implementadas melhorias no processo sempre que for necessário
4.3. Planejamento da sprint
4.3.1. Primeiro evento que ocorre na sprint
4.3.2. Serve para definir O QUE precisa ser feito e COMO deve ser feito
4.3.3. Todos do time Scrum participam
4.3.4. Time-box de 8 horas para uma sprint de um mês
4.3.4.1. Proporcionalmente menor para sprints menores
4.3.4.2. 2 horas para cada semana de duração da sprint
4.3.5. Trata de dois tópicos
4.3.5.1. Tópico 1
4.3.5.1.1. O que faremos?
4.3.5.1.2. Define meta/objetivo da sprint
4.3.5.1.3. Participação do Dono do Produto é fundamental para definir O QUE fazer
4.3.5.1.4. Itens são estimados em complexidade pelo time de desenvolvimento
4.3.5.1.5. Somente o time de desenvolvimento deve dizer quantos itens é capaz de entregar no final da sprint
4.3.5.2. Tópico 2
4.3.5.2.1. Como faremos?
4.3.5.2.2. Tarefas podem ser estimadas em horas
4.3.5.2.3. É criado o backlog da sprint (uma saída principal da reunião de planejamento)
4.4. Reunião diária
4.4.1. Serve para sincronização das informações e atividades entre os membros do time de desenvolvimento
4.4.2. Permite a inspeção e adaptação do processo de forma rápida e antecipada
4.4.3. Somente os membros do time de desenvolvimento devem participar
4.4.3.1. A partipação de todos os membros deste time é obrigatória
4.4.3.2. Membros atualizam status das suas atividades antes da reunião
4.4.4. Sempre uma time-box de 15 minutos
4.4.4.1. Independente da duração da sprint
4.4.5. Ocorre todos os dias, exceto quando há reuniões de planejamento, revisão e retrospectiva da sprint
4.4.6. É mantida no mesmo horário e local todos os dias para reduzir a complexidade
4.4.7. A presença do Scrum master é opcional
4.4.7.1. O Scrum master apenas deve garantir/facilitar a sua realização
4.4.7.2. A condução da reunião é feita pelo time de desenvolvimento
4.4.8. Os membros respondem a 3 perguntas
4.4.8.1. O que eu fiz desde a última reunião?
4.4.8.2. O que eu vou fazer até a próxima reunião diária?
4.4.8.3. Há alguma coisa impedindo o meu trabalho?
4.5. Revisão da sprint
4.5.1. Serve para inspecionar o incremento gerado na sprint e adaptar o backlog do produto se necessário
4.5.2. Ocorre no final de cada sprint
4.5.3. Foco no produto e não no processo
4.5.4. Todos do time Scrum participam
4.5.4.1. O Product Owner pode convidar stakeholders-chave para ajudar na validação do incremento
4.5.5. Time-box de 4 horas para sprint de um mês
4.5.5.1. Proporcionalmente menor para sprints menores
4.5.5.2. É uma hora para cada semana de duração da sprint
4.5.6. O Dono do Produto fornece feedback para o time de desenvolvimento sobre o trabalho realizado
4.6. Retrospectiva da sprint
4.6.1. É uma oportunidade para o time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima sprint
4.6.2. Ocorre logo após a revisão de cada sprint
4.6.3. Time-box de 3 horas para uma sprint de um mês
4.6.3.1. Proporcionalmente menor para sprints menores
4.6.4. Todos do time Scrum participam
4.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
4.6.5. Foco na melhoria do processo e não no produto
4.6.6. Cada membro do time Scrum deve falar abertamente sobre o que considera que foi bem e o que deve ser melhorado
4.6.7. Resulta em itens de melhoria para o processo Scrum
5. Artefatos no Scrum
5.1. Backlog do produto
5.1.1. É uma lista ordenada de tudo aquilo que pode ser necessário no produto
5.1.2. Somente o Dono do Produto pode incluir, alterar e ordenar itens
5.1.3. Está em constante evolução
5.1.3.1. Deve refletir as mudanças no negócio
5.1.4. Disponível para todos visualizarem
5.1.5. Recomenda-se apenas um backlog do produto, mesmo que haja várias equipes trabalhando no mesmo produto
5.1.6. O Dono do Produto deve ordenar os itens de acordo com os melhores critérios conforme ele julgar
5.1.7. O seu refinamento pode ser feito pelo Dono do Produto e pelo time de desenvolvimento
5.1.7.1. Convém que o tempo para isto não ultrapasse 10% da capacidade do time de desenvolvimento
5.1.8. Os itens com prioridade maior terão maior detalhamento para estarem preparados para entrar na próxima sprint
5.1.9. As estimativas dos itens são feitas somente pelo time de desenvolvimento
5.2. Backlog da sprint
5.2.1. É uma saída principal gerada na reunião planejamento da sprint
5.2.2. Inclui itens selecionados do backlog do produto + tarefas necessárias
5.2.2.1. Pode conter
5.2.2.1.1. Tarefas
5.2.2.1.2. Testes a executar
5.2.2.1.3. Casos de uso
5.2.2.1.4. História de usuário
5.2.3. Novas tarefas podem ser adicionadas durante a sprint
5.2.3.1. Lembre que o detalhamento das tarefas pode continuar durante a sprint
5.2.4. Somente o time de desenvolvimento pode alterar o backlog durante a sprint
5.2.5. Vísivel para todos
5.2.5.1. Pode ser apresentado em um quadro kanban para ser visível para todos
5.2.6. Todas as tarefas são de responsabilidade do time de desenvolvimento
5.2.6.1. Um membro pode voluntariamente assumir uma tarefa para fazer, mas todos são donos de todas as tarefas
5.3. Incremento de software
5.3.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
5.3.2. Ao final da sprint um novo incremento deve estar “pronto”
5.3.3. Deve estar na condição utilizável e atender à definição de “pronto” do time Scrum
5.3.4. Quando julgar que faz sentido, o Dono do Produto decidirá a sua implantação no ambiente de produção
6. Ferramentas/técnicas extras
6.1. Lembre que estas ferramentas/técnicas são usadas na prática, mas não são obrigatórias segundo o Scrum Guide
6.2. Gráfico burndown da sprint
6.2.1. Mostra a quantidade de trabalho restante em uma sprint
6.2.2. É uma ferramenta com objetivo primário de servir ao time de desenvolvimento
6.2.3. O time de desenvolvimento deve atualizar
6.2.3.1. Lembre que a equipe é autogerenciada
6.2.4. Útil para fazer o monitoramento do andamento da sprint
6.2.5. É uma ferramenta de gerenciamento visual e depende da transparência dos membros da equipe
6.3. Gráfico burndown da release
6.3.1. Mostra a quantidade de trabalho restante para concluir o backlog do produto naquele instante
6.3.2. É uma "foto" da situação atual
6.3.3. Deve ser atualizado toda vez que o backlog do produto mudar
6.3.4. O Dono do Produto é responsável pela atualização
6.4. Planejamento da release
6.4.1. Dono do Produto é responsável por realizar o plano de releases
6.4.2. Ao final de cada sprint, o Dono do Produto decidirá se implanta o incremento liberado em produção
7. Transparência do artefato
7.1. O Scrum master deve trabalhar com o time Scrum para garantir que estão sendo utilizadas práticas para favorecer a transparência
7.2. Definição de "pronto"
7.2.1. É usada para definir quando o trabalho está completado no incremento do produto
7.2.2. Orienta o time de desenvolvimento sobre quantos itens do backlog do produto podem ser selecionados durante a reunião de planejamento
7.2.3. Pode fazer parte de convenções, padrões ou diretrizes de desenvolvimento da organização
7.2.4. Se esta definição é particular de cada projeto, então cabe ao time de desenvolvimento criar uma definição de "pronto" apropriada
7.2.5. Se houver vários times Scrum trabalhando no mesmo produto, então a mesma definição deve ser acordada entre os times