Por que este curso não escolhe Scrum ou Kanban — ainda.
As práticas de entrega de software formam uma pilha com três camadas, e a maioria das equipes tenta adotá-las na ordem errada.
Camada 1: Fundamentos. Controle de código-fonte, rastreamento de trabalho, comunicação de intenção, hábitos de estimativa e rastreabilidade. Essas são as práticas que este curso cobre. Elas são agnósticas de metodologia — uma equipe Scrum e uma equipe Kanban precisam delas, e elas parecem quase idênticas em ambos os contextos.
Camada 2: Metodologia. Scrum, Kanban, XP ou um híbrido. É aqui que você escolhe uma cadência (sprints ou fluxo contínuo), define papéis (ou escolhe explicitamente não ter) e adota cerimônias (standups, retrospectivas, sessões de planejamento). A metodologia dá ritmo e estrutura a uma equipe — mas pressupõe que os fundamentos já estejam em vigor.
Camada 3: Escala. SAFe, LeSS, Lean Portfolio Management ou padrões de coordenação caseiros. Esta camada só importa quando várias equipes precisam coordenar a entrega. Ela pressupõe que tanto os fundamentos quanto a metodologia estejam funcionando no nível da equipe.
A pilha importa porque cada camada depende da que está abaixo dela. Uma equipe executando Scrum sem rastreamento sólido de trabalho gastará metade de cada reunião de planejamento de sprint redescobrindo o que está em andamento. Uma organização adotando SAFe sem retrospectivas funcionais no nível da equipe escalará disfunção, não entrega.
A maioria das "transformações ágeis" falha porque começa na Camada 2 ou Camada 3. Elas compram uma ferramenta, contratam um coach, renomeiam reuniões — e então se perguntam por que a velocidade não melhora. A resposta é quase sempre a mesma: os fundamentos não estavam lá.
Toda metodologia pressupõe que você já tem o básico. Scrum pressupõe que você pode rastrear trabalho em um backlog, fazer commit de código em um repositório compartilhado e estimar esforço com consistência suficiente para planejar um sprint. Kanban pressupõe que você pode visualizar itens de trabalho, medir tempo de ciclo e rastrear um ticket desde a solicitação até a entrega. XP pressupõe que você pode escrever testes, revisar código e fazer deploy com frequência.
Nenhuma dessas suposições é declarada nos guias de metodologia, porque os autores as consideravam óbvias. Mas para muitas equipes, elas não são óbvias — são aspiracionais. E quando uma equipe adota uma metodologia sem os fundamentos, a metodologia se torna teatro: as cerimônias acontecem, os artefatos existem, mas os resultados não mudam.
Você já viu isso. A equipe que executa planejamento de sprint mas não consegue responder "ao que nos comprometemos no último sprint?" porque os tickets não foram atualizados. A equipe que faz standups diários mas não consegue compartilhar progresso porque metade do trabalho não é rastreado. A equipe que realiza retrospectivas mas não consegue agir sobre os insights porque não há sistema para atribuir e acompanhar itens de ação.
A solução não é abandonar a metodologia. A solução é acertar os fundamentos primeiro, depois colocar a metodologia em cima. Essa é a ordem que este curso segue: os Módulos 2–4 cobrem os fundamentos (controle de código-fonte, tickets, estimativa), e o Módulo 5 ajuda você a escolher qual metodologia — se alguma — adotar uma vez que a base esteja sólida.