1. Ferramentas de monitoramento
1.1. Gráfico burndown da sprint
1.1.1. Mostra a quantidade de trabalho restante em uma sprint
1.1.2. O time pode atualizar
1.1.3. Útil para fazer gestão e monitoramento do andamento da sprint
1.1.4. É uma ferramenta para gestão e depende da transparência dos membros da equipe
1.1.5. É uma ferramenta com objetivo primário de servir ao time de desenvolvimento
1.2. Gráfico burndown da release
1.2.1. Mostra a quantidade de trabalho restante para concluir o backlog do produto naquele instante
1.2.2. É uma "foto" da situação atual
1.2.3. Deve ser atualizado toda vez que o backlog do produto mudar
1.2.4. O Dono do Produto é responsável
2. Desenvolvimento orientado por valor
2.1. Razão pela qual os projetos são realizados
2.1.1. Gerar valor para o negócio
2.1.2. 80% do valor normalmente reside em 20% das características
2.2. Práticas orientadas a valor
2.2.1. Avaliando valor
2.2.1.1. Retorno do Investimento (ROI)
2.2.1.2. Valor Presente Líquido (VPL)
2.2.1.3. Taxa Interna de Retorno (TIR)
2.2.2. Planejamento de valor
2.2.2.1. Carta de abertura
2.2.2.2. Mapeamento do fluxo de valor
2.2.2.3. Priorização baseada no valor para o cliente
2.2.2.4. Priorização relativa
2.2.2.5. Roadmap do produto
2.2.2.6. Riscos
2.2.3. Entregando valor
2.2.3.1. Task/Quadro Scrum
2.2.3.2. Quadro Kanban
2.2.3.3. Limite WIP
2.2.4. Confirmando Valor
2.2.4.1. Priorização baseada no valor ao cliente
2.2.4.2. MVP
2.2.4.3. Satisfação e feedback de usuários
2.2.5. Reportando valor
2.2.5.1. Gráficos burdown
2.2.5.2. Tarefas/Quadro Kanban
2.2.5.3. Quadro Scrum
2.3. Produto Viável Mínimo (Minimum Viable Product - MVP)
2.3.1. Mínimo conjunto de funcionalidades que permite uma ação e aprendizado
2.3.2. Provar a visão inicial do empreendedor
2.4. MMP - Minimal Marketable Product
2.4.1. Baseia-se na ideia de que menos é mais
2.4.2. Produto com o menor conjunto de recursos possível que atenda às necessidades do usuário
2.4.3. Ferramenta para reduzir o time-to-market
3. Gerenciamento de requisitos
3.1. Importante saber
3.1.1. Envolvimento ativo dos usuários é mandatório
3.1.2. Requisitos surgem e evoluem de acordo com o desenvolvimento do software
3.1.3. Requisitos são desenvolvidos em pequenas fatias
3.1.4. Suficiente é suficiente – aplique a regra 80/20
3.2. User stories
3.2.1. Descreve os requisitos ou funcionalidades do produto
3.2.2. Três partes
3.2.2.1. Cartão
3.2.2.1.1. Ator
3.2.2.1.2. Ação
3.2.2.1.3. Objetivo
3.2.2.2. Conversa
3.2.2.2.1. Conversar com a parte interessada
3.2.2.2.2. Análise Just in Time (JIT)
3.2.2.3. Confirmação
3.2.2.3.1. Testes de aceitação
3.2.2.3.2. Verificar se a história está pronta e completa
3.2.3. Critérios de qualidade
3.2.3.1. Independente
3.2.3.2. Negociável
3.2.3.3. Valiosa
3.2.3.4. Small (pequena)
3.2.3.5. Testável
3.2.4. Categoria
3.2.4.1. Tema
3.2.4.2. Épico
3.3. Spikes
3.3.1. Tipo especial de história
3.3.2. Usadas para atividades de pesquisa, design, exploração ou prototipação
3.3.3. Fazem parte do backlog do produto
3.4. Todos os requisitos devem ser registrados no backlog do produto
3.5. Definição de Preparado – Definition of Ready (DoR)
3.6. Estimativas
3.6.1. Não estime em horas
3.6.2. Estimativas são feitas por pessoas que farão o trabalho
3.6.3. Métodos para estimativa
3.6.3.1. Story points (Pontos de história)
3.6.3.2. Planning poker
3.6.3.3. Método T-shirt
3.6.4. Cone da incerteza
3.7. Técnicas para priorização
3.7.1. Votos cumulativos
3.7.2. MoSCoW
3.7.3. Priorização baseada em riscos
3.7.4. Ranking relativo
3.7.5. Análise de Pareto
3.7.6. Minimum Marketable Feature (ou Product)
3.7.7. Minimum Viable Product
3.7.8. Análise de Kano (modelo Kano)
3.7.9. Retorno de Investimento (ROI)
3.7.10. Valor Presente Líquido (VPL)
3.7.11. Taxa Interna de Retorno (TIR)
4. Planejamento de release
4.1. Múltiplos níveis de planejamento (planning onion)
4.1.1. Planejamento do produto
4.1.1.1. Estabelece a visão do produto
4.1.2. Roadmap do produto
4.1.2.1. Ajuda os interessados a saber quando esperar novos recursos
4.1.2.2. Facilita as conversas sobre prioridades de recurso
4.1.2.3. Mapa de histórias
4.1.2.3.1. Utilizados quando as equipes estão tentando visualizar roadmaps de produtos de alto nível e planos de release
4.1.2.3.2. Três elementos
4.1.3. Planejamento de liberação
4.1.3.1. Importante saber
4.1.3.1.1. Dono do Produto é responsável por realizar o plano de releases
4.1.3.1.2. Ao final da sprint o Dono do Produto decidirá se implanta o incremento liberado em produção
4.1.3.1.3. Não faz parte do core estrutural do Scrum
4.1.3.1.4. Realizada em intervalos regulares
4.1.3.2. Estabelece
4.1.3.2.1. Objetivo da release
4.1.3.2.2. Os itens de maior prioridade
4.1.3.2.3. Os principais riscos
4.1.3.2.4. As características gerais e funcionalidades
4.1.4. Planejamento da sprint
4.1.5. Planejamento diário
5. Mapa desenvolvido pela TIEXAMES
5.1. www.tiexames.com.br
5.2. Não divulgue este material
5.3. Somente alunos matriculados no curso devem usá-lo
5.4. Incluímos o essencial para o exame
5.5. Não há garantia de aprovação no exame apenas decorando este mapa
6. Artefatos
6.1. Visão do produto
6.1.1. Problema a ser resolvido
6.1.2. Propósito do projeto em alto nível
6.1.3. Um esboço do produto
6.1.4. Deveria responder
6.1.4.1. Quem vai comprar o produto?
6.1.4.2. Quais os clientes-alvo?
6.1.4.3. Quem vai usar o produto?
6.1.4.4. Quais necessidades o produto precisa suportar?
6.1.4.5. Qual o valor que o produto adiciona?
6.1.4.6. Qual a vantagem competitiva do produto se comparado ao produto dos concorrentes?
6.1.4.7. O produto é viável?
6.1.5. Características
6.1.5.1. Compartilhada e unificada
6.1.5.2. Ampla e envolvente
6.1.5.3. Curta e “doce”
6.1.6. Template
6.1.6.1. PARA <público-alvo>
6.1.6.2. QUEM <declaração de necessidade>
6.1.6.3. O <nome do produto> é um <categoria do produto>
6.1.6.4. QUE <benefício fundamental, razão para comprar e usar>
6.1.6.5. AO CONTRÁRIO <concorrência/alternativa>
6.1.6.6. O NOSSO PRODUTO <declaração dos diferenciais>
6.2. Backlog do produto
6.2.1. Lista ordenada de tudo aquilo que pode ser necessário no produto
6.2.2. Somente o Dono do Produto pode incluir, alterar e ordenar itens
6.2.3. Disponível para todos visualizarem
6.2.4. Está em constante evolução
6.2.4.1. Deve refletir as mudanças no negócio
6.2.5. Recomenda-se apenas um backlog do produto, mesmo que haja múltiplas equipes
6.2.6. O Dono do Produto deve ordenar os itens de acordo com os melhores critérios conforme seu julgamento
6.3. Backlog da sprint
6.3.1. Inclui itens selecionados do backlog do produto + tarefas necessárias
6.3.1.1. Pode conter
6.3.1.1.1. Tarefas
6.3.1.1.2. Testes a executar
6.3.1.1.3. Casos de uso
6.3.1.1.4. História de usuário
6.3.2. Resultado da segunda parte do planejamento da sprint
6.3.3. Tarefas podem ser acrescentadas durante a sprint
6.3.4. Somente o time de desenvolvimento pode alterar
6.3.5. Vísivel para todos
6.3.6. Pode ser feito um quadro kanban para gestão
6.3.7. Todas as tarefas são de responsabilidade do time de desenvolvimento
6.3.7.1. Um membro pode voluntariamente assumir uma tarefa para fazer, mas todos são donos de todas as tarefas
6.4. Incremento de software
6.4.1. Ao final de cada sprint, um incremento de software deve ser entregue
6.4.2. Este incremento de software deve ser integrado aos incrementos já existens do software
6.4.3. Deve estar "pronto" e potencialmente utilizável pelos clientes
6.4.4. Quando faz sentido, o Dono do Produto ordena a sua implantação no ambiente de produção
7. Fundamentos do Scrum
7.1. É um framework e não uma metodologia
7.1.1. Indicado para gerenciar desenvolvimento de produtos complexos
7.1.2. Você pode empregar vários processos ou técnicas dentro deste framework
7.2. Adota o desenvolvimento iterativo e incremental
7.2.1. Entregas pequenas e parciais – 1 a 4 semanas
7.2.2. Entrega do maior valor agregado mais cedo
7.2.3. Redução das incertezas por meio de entregas menores e rápidas
7.2.4. Permite a rápida e contínua inspeção
7.3. Entrega de valor
7.3.1. Necessidades do negócio determinam as prioridades do desenvolvimento
7.3.2. O Dono do Produto é responsável por garantir o ROI do investimento
7.4. Foco mais nas pessoas e menos no processo
7.5. Processo empírico
7.5.1. Aceita que um problema não pode ser completamente entendido ou definido
7.5.2. Foca na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes
7.5.3. A equipe adapta os processos rapidamente para atingir melhores resultados
7.6. Não é recomendado fazer alterações no vocabulário ao implantar na organização
7.7. Equipes são auto-organizadas e autogerenciadas
7.7.1. Membros são multifuncionais, podem atuar em todas as atividades da sprint
7.7.2. Não precisam de um gerente de projeto (o Scrum master é um líder-servo e o PO se responsabiliza pelo produto)
7.7.3. Compostas por pessoas comprometidas
7.7.4. Determinam as tarefas necessárias para os itens selecionados para a sprint
7.7.5. As tarefas são do time de desenvolvimento e todos são responsáveis; ninguém individualmente se apropria
7.7.6. Não há líderes funcionais dentro da equipe
7.7.7. O Scrum master e o Dono do Produto não são chefes do time de desenvolvimento
7.8. Pilares do Scrum
7.8.1. Transparência
7.8.1.1. Informações devem ser visíveis para todos
7.8.1.2. Informações são entendidas por todos da mesma maneira
7.8.1.3. Estimativas são dadas de acordo com o que cada membro do time de desenvolvimento realmente acredita
7.8.1.4. Problemas não podem ser escondidos
7.8.1.5. Comprometer-se somente com aquilo que se acredita
7.8.2. Inspeção
7.8.2.1. Processos, práticas e atividades devem ser inspecionadas com frequência
7.8.2.2. A inspeção é a base para a adaptação
7.8.3. Adaptação
7.8.3.1. Alterações no processo para evitar erros e problemas
7.8.3.2. Feita pelo time de desenvolvimento, Scrum master e Dono do produto
7.8.3.3. As reuniões são aproveitadas para realizar inspeção e adaptação
7.8.3.4. Sempre que for dedectado um problema, uma ação de adaptação pode ser iniciada imediatamente
7.9. Valores do scrum
7.9.1. Comprometimento das pessoas em alcançar os objetivos do time Scrum
7.9.2. Coragem para fazer a coisa certa e trabalhar em problemas difíceis
7.9.3. Foco no trabalho da sprint e nos objetivos do time Scrum
7.9.4. Transparência em relação ao trabalho que está sendo feito
7.9.5. Respeito uns aos outros para serem pessoas capazes e independentes
8. Papéis no Scrum
8.1. Scrum team
8.1.1. Product Owner
8.1.1.1. Pode ser alguém da área de negócio
8.1.1.2. Representa clientes e usuários
8.1.1.3. Deve existir um para cada produto
8.1.1.3.1. Tem que ser uma única pessoa por produto, não pode ser um comitê
8.1.1.3.2. A mesma pessoa pode ser o PO de várias equipes
8.1.1.3.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
8.1.1.4. Principais responsabilidades
8.1.1.4.1. Estabelecer a visão do produto
8.1.1.4.2. Maximizar o ROI do produto
8.1.1.4.3. É o único dono do backlog do produto
8.1.1.4.4. Determinar os itens do backlog do produto junto com as partes interessadas
8.1.1.4.5. Priorizar os itens do backlog do produto
8.1.1.4.6. Tirar dúvidas do time de desenvolvimento sobre os itens do backlog do produto
8.1.1.4.7. Fornecer feedback na revisão da sprint
8.1.1.4.8. Fazer o planejamento das releases
8.1.1.4.9. Decidir quando liberar um incremento em produção
8.1.2. Scrum master
8.1.2.1. Atua como líder-servo
8.1.2.1.1. Remove os impedimentos para o time de desenvolvimento
8.1.2.1.2. Ensina o time Scrum a usar o Scrum
8.1.2.1.3. Não tem autoridade sobre o time de desenvolvimento, mas pode fornecer auxílio quando solicitado
8.1.2.2. Deve existir um para cada equipe Scrum
8.1.2.2.1. Uma única pessoa pode ser Scrum master de várias equipes
8.1.2.3. É uma posição de gestão
8.1.2.3.1. Porém de gestão de processo e não de pessoas
8.1.2.4. Principais responsabilidades
8.1.2.4.1. Garantir o uso correto do Scrum
8.1.2.4.2. Remover impedimentos para o time de desenvolvimento
8.1.2.4.3. Atuar como mediador entre as partes, somente quando for necessário
8.1.2.4.4. Ensinar a equipe a ser auto-organizada e autogerenciada
8.1.2.4.5. Disseminar a cultura do Scrum na organização
8.1.2.4.6. Auxiliar o Dono do Produto no gerenciamento do backlog do produto ensinando técnicas para isto
8.1.2.4.7. Sugerir melhorias para aumentar a eficiência e eficácia do time de desenvolvimento
8.1.2.4.8. Deve garantir/facilitar a realização de todos os eventos do Scrum
8.1.3. Development team
8.1.3.1. Formado por pessoas comprometidas com os objetivos do projeto
8.1.3.2. Todos os membros são DESENVOLVEDORES
8.1.3.2.1. Não há papéis específicos, como testador
8.1.3.3. Os membros devem ser multifucionais
8.1.3.3.1. Os membros devem ter todas as habilidades necessárias para o trabalho na sprint
8.1.3.3.2. Os membros podem realizar mais de uma função/atividade
8.1.3.4. Deve ser multifuncional
8.1.3.4.1. Inclui membros com diversos conhecimentos necessários
8.1.3.5. Deve ser auto-organizado e autogerenciado
8.1.3.5.1. Não há líderes dentro do time
8.1.3.5.2. Os membros se organizam da melhor forma para realizarem o trabalho da sprint
8.1.3.6. Tamanho ideal
8.1.3.6.1. 6 +/- 3 pessoas
8.1.3.6.2. Máximo recomendado: 9 pessoas
8.1.3.6.3. Mínimo recomendado: 3 pessoas
8.1.3.7. Principais responsabilidades
8.1.3.7.1. Responsável pelo sucesso do projeto
8.1.3.7.2. Realizar todas as atividades para produzir um incremento de software
8.1.3.7.3. Gerenciar/atualizar o backlog da sprint
8.1.3.7.4. Fornecer as estimativas para os itens do backlog do produto
8.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
9. Eventos no Scrum
9.1. Importante saber
9.1.1. Todos os eventos no Scrum são time-boxed
9.1.2. O 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; ele participará de todos os outros eventos
9.2. Sprint
9.2.1. Duração máxima de um mês
9.2.2. É o momento em que é feito o trabalho para transformar os itens do backlog do produto selecionados em incremento de software funcionando
9.2.3. Toda sprint deve gerar no final um incremento de software potencialmente utilizável e "pronto"
9.2.3.1. É importante que o time de desenvolvimento estabeleça a definição de "pronto", se esta definição não existir na organização
9.2.4. Composição
9.2.4.1. Dentro de uma sprint haverá 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
9.2.5. Inicia-se junto com a reunião de planejamento da sprint e termina junto com a reunião de retrospectiva
9.2.6. Termina quando sua time-box termina
9.2.6.1. Durante a sprint novas tarefas podem ser identificadas pelo time de desenvolvimento
9.2.6.2. Se sobrar tempo, novos itens do backlog do produto podem ser selecionados e desenvolvidos
9.2.6.3. Os itens que não forem completados podem voltar para o backlog do produto e serão repriorizados pelo Dono do Produto
9.2.6.4. Uma vez que uma sprint termina, outra é iniciada imediatamente
9.2.7. Mudanças devem ser evitadas quando a sprint está em execução
9.2.8. Somente o Dono do Produto pode cancelar uma sprint antes do seu término
9.2.9. Itens do backlog da sprint podem ser removidos ou alterados se o time de desenvolvimento perceber que não dará conta de fazer tudo
9.2.10. Durante a sprint podem ser implementadas melhorias no processo sempre que for necessário
9.2.11. Não existe sprint 0 para planejamento de arquitetura/infraestrutura
9.3. Planejamento da sprint
9.3.1. Primeiro evento que ocorre na sprint
9.3.2. Serve para definir O QUE precisa ser feito e COMO deve ser feito
9.3.3. Todos do time Scrum participam
9.3.4. Time-box de 8 horas para uma sprint de um mês
9.3.4.1. Proporcionalmente menor para sprints menores
9.3.4.2. 2 horas para cada semana de duração da sprint
9.3.5. Trata de dois tópicos
9.3.5.1. Tópico 1
9.3.5.1.1. O que faremos?
9.3.5.1.2. Define meta/objetivo da sprint
9.3.5.1.3. Participação do Dono do Produto é fundamental para definir O QUE fazer
9.3.5.1.4. Itens são estimados em complexidade pelo time de desenvolvimento
9.3.5.1.5. Somente o time de desenvolvimento deve dizer quantos itens é capaz de entregar no final da sprint
9.3.5.2. Tópico 2
9.3.5.2.1. Como faremos?
9.3.5.2.2. Tarefas podem ser estimadas em horas
9.3.5.2.3. É criado o backlog da sprint (uma saída principal da reunião de planejamento)
9.4. Reunião diária
9.4.1. Serve para sincronização das informações e atividades entre os membros do time de desenvolvimento
9.4.2. Permite inspeção e adaptação do processo de forma rápida e antecipada
9.4.3. Somente os membros do time de desenvolvimento devem participar
9.4.3.1. A participação de todos os membros deste time é obrigatória
9.4.3.2. Membros atualizam status das suas atividades antes da reunião
9.4.4. Sempre uma time-box de 15 minutos
9.4.4.1. Independente da duração da Sprint
9.4.5. Ocorre todos os dias, exceto quando há reuniões de planejamento, revisão e retrospectiva da sprint
9.4.6. É mantida no mesmo horário e local todos os dias para reduzir a complexidade
9.4.7. A presença do Scrum master é opcional
9.4.7.1. O Scrum master apenas deve garantir/facilitar a sua realização
9.4.7.2. A condução da reunião é feita pelo time de desenvolvimento
9.4.8. Membros respondem a 3 perguntas
9.4.8.1. O que eu fiz desde a última reunião?
9.4.8.2. O que eu vou fazer até a próxima reunião diária?
9.4.8.3. Há alguma coisa impedindo o meu trabalho?
9.5. Revisão da sprint
9.5.1. Serve para inspecionar o incremento gerado na sprint e adaptar o backlog do produto se necessário
9.5.2. Ocorre no final de cada sprint
9.5.3. Foco no produto e não no processo
9.5.4. Todos do time Scrum participam
9.5.4.1. O Product Owner pode convidar stakeholders-chave
9.5.5. Time-box de 4 horas para uma sprint de um mês
9.5.5.1. Proporcionalmente menor para sprints menores
9.5.5.2. Uma hora para cada semana de duração da sprint
9.5.6. O Dono do Produto fornece feedback para o time de desenvolvimento sobre o trabalho realizado
9.6. Retrospectiva da sprint
9.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
9.6.2. Ocorre logo após a revisão de cada sprint
9.6.3. Time-box de 3 horas para uma sprint de um mês
9.6.3.1. Proporcionalmente menor para sprints menores
9.6.4. Todos do time Scrum participam
9.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
9.6.5. Foco na melhoria do processo e não no produto
9.6.6. Cada membro do time Scrum deve falar abertamente sobre o que considera que foi bem e o que deve ser melhorado
9.6.7. Resulta em itens de melhoria para o processo Scrum