Trilha Scrum (Scrum.org PSM / PSPO / PSD): tudo o que estudar, tópico por tópico

A teoria por trás do Scrum: controle empírico de processo baseado em transparência, inspeção e adaptação, a diferença em relação a processos definidos (preditivos), o pensamento lean e como cada evento do Scrum oferece uma oportunidade formal de inspecionar e adaptar

Compromisso, Foco, Abertura, Respeito e Coragem: o que cada valor significa na prática, como os valores sustentam os pilares e como um Scrum Master reconhece e trata comportamentos que os violam

O Scrum como framework leve: o Scrum Team único, cinco eventos, três artefatos com seus compromissos, as regras que os unem, o que o Guia de 2020 mudou (sem Development Team, Product Goal, Sprint Goal como compromisso, autogerenciamento, sem as três perguntas) e o que o Scrum deixa propositalmente sem especificar

Reconhecer o 'Scrum-but', sprints de mini-cascata, Daily Scrums como reunião de status, o Scrum Master como gerente de projeto, a velocidade como meta, sprints de estabilização e outros desvios, respondendo a eles com o Scrum Guide como referência e mantendo o framework completo

O Scrum Master como líder verdadeiro responsável pela efetividade do Scrum Team: servir à equipe (coaching, foco em Incrementos que atendam à Definition of Done, remoção de impedimentos, eventos positivos e dentro do timebox), ao Product Owner e à organização, e o que um Scrum Master não é

Uma pessoa responsável por maximizar o valor do produto resultante do trabalho do Scrum Team: desenvolver e comunicar o Product Goal, criar e ordenar itens do Product Backlog, garantir transparência, o que pode ser delegado e o dever da organização de respeitar as decisões do Product Owner

Os Developers são as pessoas comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint: criar o plano da Sprint, instilar qualidade por meio da Definition of Done, adaptar o plano diariamente em direção ao Sprint Goal e responsabilizar-se mutuamente como profissionais; quem conta como Developer

O Scrum Team como uma unidade de foco sem subequipes ou hierarquias, pequeno o bastante (tipicamente dez ou menos) e multifuncional, autogerenciável em quem, o que e como; crescimento do autogerenciamento, trade-offs do tamanho da equipe, colaboração com partes interessadas e o que um gerente ainda pode fazer

A Sprint como evento contêiner e batimento cardíaco: duração fixa de um mês ou menos, consistência, nenhuma mudança que ponha em risco o Sprint Goal, esclarecimento e renegociação de escopo, quem pode cancelar e quando, e por que Sprints não são estendidas

Os três tópicos da Sprint Planning: por que a Sprint é valiosa (Sprint Goal), o que pode ser feito (os Developers selecionam itens do Product Backlog) e como o trabalho será feito (plano); entradas, timebox de oito horas para uma Sprint de um mês e os papéis de cada responsabilidade

Um evento de 15 minutos para os Developers inspecionarem o progresso em direção ao Sprint Goal e adaptarem o Sprint Backlog: estrutura escolhida pelos Developers, mesmo horário e local, quem participa e quem é dono, e por que não é um relatório de status para a gestão

Uma sessão de trabalho para inspecionar o resultado da Sprint e determinar adaptações futuras: Scrum Team e partes interessadas-chave, progresso em direção ao Product Goal, revisão do Product Backlog e do mercado, quatro horas para uma Sprint de um mês e como difere de uma demo ou aprovação

O evento que planeja formas de aumentar qualidade e efetividade: inspecionar pessoas, interações, processos, ferramentas e a Definition of Done, identificar as mudanças mais úteis, tratá-las o quanto antes, timebox de três horas e manter as melhorias fluindo para a próxima Sprint

O Product Backlog como lista única, emergente e ordenada do que é necessário para melhorar o produto, o Product Goal como seu objetivo de longo prazo e compromisso, o refinamento como trabalho contínuo, itens pequenos o bastante para uma Sprint e a transparência da ordenação

O Sprint Backlog como o Sprint Goal (por quê), os itens do Product Backlog selecionados (o quê) e o plano para entregá-los (como), de propriedade dos Developers e atualizado ao longo da Sprint; o Sprint Goal como o compromisso que dá flexibilidade

O Incremento como um passo concreto e utilizável em direção ao Product Goal, aditivo e verificado, a Definition of Done como o compromisso que cria transparência, padrões organizacionais vs da equipe, tratamento de trabalho não concluído e evolução da Definition of Done

Prever entregas com dados empíricos em vez de promessas: gráficos de burn-up e burn-down, throughput e diagrama de fluxo cumulativo, faixas de Monte Carlo, planejamento de releases sob incerteza, por que a velocidade não é um compromisso e como manter os artefatos transparentes para decisões

As posturas entre as quais um Scrum Master transita: líder servidor, facilitador, coach, professor, mentor, gestor, removedor de impedimentos e agente de mudança; escolher a postura certa para cada situação e evitar ficar em uma só (como sempre resolver)

Facilitar eventos e decisões sem assumir o controle: preparação, divergência e convergência, técnicas de decisão, lidar com vozes dominantes e silêncio, conflitos entre Developers ou com o Product Owner, disfunções e como um Scrum Master intervém com a mínima força

Evoluir a organização em torno de Scrum Teams: impedimentos organizacionais, cultura e estrutura, papéis da gestão intermediária, estilos de liderança do diretivo ao capacitador, trabalho com partes interessadas e como um Scrum Master lidera, treina e orienta a adoção do Scrum na organização

Usar evidências para melhorar o valor: as quatro Áreas-Chave de Valor (Valor Atual, Valor Não Realizado, Time-to-Market, Capacidade de Inovar), medidas-chave de valor, metas e experimentos, evitar métricas de vaidade e de saída, e usar as medidas para inspecionar e adaptar em vez de julgar pessoas

Criar valor com o Scrum: visão e estratégia do produto, definição e medição de valor, clientes e usuários vs partes interessadas, colaboração na Sprint Review e entre os eventos, dizer não e gerenciar expectativas sobre escopo e data fixos

O refinamento como atividade contínua que acrescenta detalhe, estimativas e ordem; os Developers são donos do dimensionamento; divisão vertical de itens, critérios de aceitação, estimativa relativa, Planning Poker, histórias de referência, throughput e #NoEstimates, mantendo as estimativas úteis em vez de precisas

TDD vermelho-verde-refatorar, testes unitários e de integração, pirâmide de testes, desenvolvimento orientado a comportamento e testes de aceitação, automação de testes vs testes exploratórios manuais, suítes de regressão e dublês de teste; testar dentro da Sprint e não depois dela

Integração contínua, pipelines de implantação, desenvolvimento baseado em trunk, feature toggles, infraestrutura como código, ambientes, gates de qualidade automatizados, monitoramento e ciclos de feedback, e a cultura DevOps como forma de manter o Done pronto para release

A dívida técnica como o custo de atalhos anteriores, dívida visível vs oculta, refatoração, código limpo, métricas de código, design emergente e arquitetura evolutiva, e como a Definition of Done e o Product Backlog tornam qualidade e dívida transparentes

Programação em par, mob programming, revisão de código, propriedade coletiva do código, padrões de codificação compartilhados, polivalência (pessoas em T) e swarming em itens do backlog, equilibrando colaboração e fluxo individual, e como essas práticas sustentam uma equipe multifuncional

Identificar e reduzir riscos técnicos cedo: spikes e protótipos, walking skeletons, requisitos não funcionais (segurança, desempenho, confiabilidade), dependências e integração, prova de conceito e tratamento da incerteza por meio de pequenos experimentos dentro da Sprint