Agile e Scrum, qual é realmente a diferença? — Fundamentos práticos para equipes de desenvolvimento

Introdução

Este artigo organiza a relação entre Agile e Scrum e resume o conhecimento mínimo necessário para trabalhar de forma eficaz no campo. É destinado a pessoas que estão prestes a se juntar a uma equipe ou que desejam atualizar os conhecimentos adquiridos de forma autodidata.

O que é Agile?

Em uma frase

Agile não é uma metodologia específica, mas sim uma "forma de pensar" e um "conjunto de valores" para o desenvolvimento de software. Seu ponto de partida é o "Manifesto Ágil" (Agile Manifesto), publicado em 2001 por 17 desenvolvedores de software que se reuniram.

Os quatro valores

O Manifesto Ágil expressa que se valoriza mais o lado direito do que o esquerdo.

Um ponto importante: não se diz que "o lado esquerdo não tem valor". Ambos os lados têm valor, mas é dado maior peso ao lado direito — essa é a postura do Agile.

12 princípios (extrato)

Por trás do manifesto há 12 princípios. Não é necessário memorizar todos, mas aqui estão os três mais citados:

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor.
2. Mudanças nos requisitos são bem-vindas, mesmo no final do desenvolvimento.
3. Entregamos software funcionando com frequência, de algumas semanas a alguns meses, com preferência à escala de tempo mais curta.

"Entregar software funcionando em ciclos curtos" e "Dar boas-vindas às mudanças" — esses dois pontos podem ser considerados o núcleo do Agile.

O que é Scrum?

Sua relação com Agile

É precisamente aqui que a confusão frequentemente ocorre. Em forma de diagrama:

Agile (mentalidade / valores)
├── Scrum (framework) ← o mais difundido
├── XP (Extreme Programming)
├── Kanban
└── Outros...

Em outras palavras, Scrum é um dos frameworks concretos para praticar Agile. Agile ≠ Scrum, e a relação correta é Scrum ⊂ Agile.

O 3-5-3 do Scrum

O Scrum é composto por "3 Responsabilidades (Accountabilities), 5 Eventos e 3 Artefatos". Na versão 2020, o antigo termo "papéis" foi substituído por "responsabilidades", e cada artefato recebeu um compromisso (Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done).

As 3 Responsabilidades

• Product Owner (PO): Responsável por maximizar o valor do produto. Decide as prioridades do que deve ser construído.
• Scrum Master (SM): Apoia o correto funcionamento do Scrum. É o coach da equipe e a pessoa que remove impedimentos.
• Developers: As pessoas que realmente constroem o produto. Engenheiros, designers, QA, etc.

Os 5 Eventos

Os 3 Artefatos

• Product Backlog: Uma lista priorizada de tudo o que se deseja fazer. Gerenciado pelo PO.
• Sprint Backlog: A lista de trabalho para o Sprint atual. Gerenciado pelos Developers.
• Increment: O produto funcional completado no Sprint.

O ciclo do Sprint

[Planning] → [Desenvolvimento + Daily × N dias] → [Review] → [Retro] → Próximo Sprint

Repetir esse ciclo em um período fixo é o ritmo fundamental do Scrum.

Aprofundando o Scrum com exemplos concretos

A partir daqui, exploramos em detalhes as partes difíceis de entender apenas com explicações abstratas, usando um produto fictício como exemplo.

Aprofundando as Responsabilidades

Product Owner (PO) — O dia de Ana

O trabalho do PO é frequentemente resumido como "decidir prioridades", mas na realidade é muito mais complexo. Este é um dia típico de Ana, a PO da equipe FitLog:

• Manhã: Revisa os dados de uso do último release, identifica as telas com alta taxa de abandono. Organiza as solicitações enviadas pela equipe de Customer Success.
• Tarde: Reúne-se com os stakeholders (marketing, diretoria) para alinhar os objetivos de negócios do Q3 com o Product Goal.
• Entretanto: Responde imediatamente a perguntas dos developers como "Essa spec — essa implementação seria mais leve, o que você acha?"
• Semanalmente: Refina o backlog e esclarece os critérios de aceitação dos itens prioritários.

O ponto principal é que o PO carrega tanto o "valor para o usuário" quanto o "valor de negócio". Para ter base para decidir "Feature A ou Feature B, qual primeiro?", precisa dominar pesquisa com usuários, análise de dados e reuniões de diretoria.

Scrum Master (SM) — Exemplos de intervenções de Carlos

O SM frequentemente é visto como um "facilitador de reuniões", mas sua essência é ser um coach que faz emergir a autonomia da equipe. O que Carlos, o SM da equipe FitLog, realmente faz:

• Percebe que o Developer A diz todos os dias no Daily Scrum "Ontem continuei investigando esse bug", e entra em contato em uma 1:1: "Está bloqueado? Precisa de ajuda?"
• Observa que há sempre divergências na "interpretação da spec" entre PO e developers, e leva esse problema à Retro.
• Interrompe solicitações diretas de outros departamentos ("Precisamos de ajuda urgente!") aos developers e reforça a regra: "As solicitações passam pelo PO."
• Propõe revisar o formato dos eventos Scrum quando a equipe já está rodada (ex: mudar o formato do Daily Scrum).

O SM é um papel que parece não fazer nada, mas na realidade está moldando continuamente o ambiente da equipe. "O SM parece ocioso ultimamente" pode ser um bom sinal de que a equipe está começando a funcionar de forma autônoma.

Developers — O que significa "auto-gerenciado"?

No Scrum Guide 2020, toda a equipe Scrum é descrita como auto-gerenciada (self-managing). Nos Developers especificamente, a autogestão se manifesta de formas concretas:

• "O quê" fazer no Sprint é decidido em consulta com o PO, mas "como" implementar é decidido pelos Developers.
• As tarefas não são atribuídas de cima; os Developers as pegam por conta própria.
• As estimativas são feitas pelos Developers (não pelo PO ou pelo gerente).
• Os Developers são responsáveis por manter os padrões de qualidade (Definition of Done).

Quando Lucas, developer iOS, percebe "Essa API está respondendo devagar e prejudica a UX", consulta diretamente Gabriel, developer Backend, para melhorar — esse tipo de colaboração horizontal que surge naturalmente é a marca de uma equipe Scrum saudável.

Aprofundando os Eventos

Sprint Planning — Exemplo real de como acontece

O Sprint Planning de 2 semanas da equipe FitLog acontece assim (aproximadamente 4 horas):

Parte 1: Por que este Sprint é valioso? (Estabelecer o Sprint Goal)

PO Ana: "Quero que nosso objetivo para este Sprint seja: 'Os usuários podem ver o progresso do seu treino nos últimos 30 dias por meio de um gráfico.' A pesquisa do mês passado mostrou que usuários com maior retenção usam mais a função de gráficos."

O Sprint Goal é expresso melhor como um estado a ser alcançado, não como uma lista de funcionalidades.

Parte 2: O que pode ser realizado neste Sprint? (Seleção de itens do Backlog)

Para os itens prioritários apresentados pelo PO, os developers estimam com Planning Poker e selecionam uma quantidade que se encaixa na sua capacidade.

Parte 3: Como o trabalho selecionado será concluído? (Desmembramento em tarefas)

Os developers desmembram os itens de backlog selecionados em tarefas concretas.

Developer Lucas: "Desmembrando o item 'Tela de visualização do gráfico', obtemos 4 tarefas: design de API, implementação iOS, implementação Android e testes E2E. Sem terminar o design de API não podemos paralelizar, então Gabriel deveria se concentrar nisso no primeiro dia."

Daily Scrum — Bom vs Ruim

❌ Daily ruim (vira um relatório de status)

"Ontem trabalhei na implementação da API. Hoje escreverei testes. Sem bloqueios."
"Avancei na implementação da tela. Hoje continuo."
…… (15 minutos monótonos)

Isso é um relatório de status, não inspeção e adaptação.

✅ Daily bom (inspeção e adaptação)

Developer Lucas: "A biblioteca de renderização de gráficos é mais pesada do que o esperado. Para alcançar o Sprint Goal, quero considerar mudar para outra biblioteca. Preciso de 2 horas a mais de investigação depois do Planning."
Developer Gabriel: "Então posso adiantar minha implementação de API um dia e vir te apoiar."
Developer Lucas: "Então vamos acertar os detalhes em 30 minutos depois disso."

O verdadeiro propósito é um espaço para replanejar como agir hoje em relação ao Sprint Goal.

Sprint Review — Muito mais do que apenas uma demo

Um equívoco frequente sobre a Review é "demo do produto funcionando e pronto". Uma Review real é um espaço de diálogo com os stakeholders.

• Os Developers demonstram o Increment funcionando
• Os stakeholders experimentam e dão feedback
• Informações externas são compartilhadas: "As condições do mercado mudaram", "A reação dos usuários-alvo foi diferente do esperado"
• Com base nisso, o Product Backlog é ajustado para o que vem a seguir

Portanto, a Review serve não apenas como "inspeção do passado" mas também como "input para o planejamento futuro".

Sprint Retrospective — Dicas para evitar o ritual vazio

As Retros são frequentemente vistas como "usamos o KPT (Keep/Problem/Try)", mas qualquer formato serve. Mudar o formato de acordo com a situação da equipe é útil, mas isso é um meio, não um fim.

Variações que a equipe FitLog está experimentando:

E limitar os Try a apenas um e começar a trabalhar nele no início do próximo Sprint. "Vamos fazer tudo" equivale a não fazer nada.

Aprofundando os Artefatos

Product Backlog — A granularidade correta dos itens

Os Product Backlog Items (PBIs) são frequentemente escritos no formato de User Story:

Como [que tipo de usuário]
Eu quero [fazer o quê]
Para que [por que quero fazer isso]

Bom exemplo de PBI para FitLog:

Título: Exibir gráfico do progresso de treino dos últimos 30 dias

Como usuário que pratica corrida regularmente, quero ver um gráfico da minha distância percorrida nos últimos 30 dias, porque quero manter minha motivação visualizando meus esforços.

Critérios de aceitação:

• Uma aba "Progresso" é adicionada à tela principal
• A distância diária dos últimos 30 dias é exibida como gráfico de linhas
• Os dias sem dados aparecem em branco no gráfico
• Tocar no gráfico navega para a tela de detalhes daquele dia

❌ Mau exemplo de PBI: "Implementar a função de gráfico" ← Não está claro para quem nem com qual propósito

Os PBIs idealmente deveriam satisfazer o princípio INVEST (Independent / Negotiable / Valuable / Estimable / Small / Testable).

Sprint Backlog — Conexão com o Product Goal

O Sprint Backlog não é uma "lista de tarefas"; é um plano composto por três elementos:

1. Sprint Goal (por quê): O estado a ser alcançado neste Sprint
2. PBIs selecionados (o quê): Itens escolhidos do Product Backlog
3. Plano de execução (como): Desmembramento em tarefas e abordagem

Sprint Goal: Os usuários podem consultar seu progresso de treino dos últimos 30 dias por meio de um gráfico
├─ PBI 1: Tela de visualização do gráfico de progresso [8 pt]
│   ├─ Tarefa: Design do endpoint de API
│   ├─ Tarefa: Implementação iOS
│   ├─ Tarefa: Implementação Android
│   └─ Tarefa: Testes E2E
├─ PBI 2: Navegar para detalhes ao tocar no gráfico [3 pt]
│   └─ ...
└─ PBI 3: Melhoria da exibição com dados vazios [2 pt]
    └─ ...

Increment — A "Definition of Done (DoD)"

O Increment é descrito como "produto funcionando", mas o que constitui estar completo precisa ser claramente definido pela equipe. Isso é a Definition of Done (DoD).

Exemplo de DoD da equipe FitLog:

• Code review com pelo menos 2 Approvals
• Cobertura de testes unitários de 80% ou mais
• Testes E2E passados
• Verificação de acessibilidade concluída (VoiceOver / TalkBack)
• PM verificou os critérios de aceitação e deu OK
• Rascunho das release notes criado

Qualquer coisa que não satisfaça a DoD é considerada "incompleta" e levada para o próximo Sprint. Entregar 5 funcionalidades a 100% é melhor do que acumular 10 funcionalidades a 80% — essa é a mentalidade Scrum.

Velocidade (Velocity) — Medindo a "velocidade" da equipe

Se você leu até aqui, talvez esteja se perguntando: "O que era aquele [8 pt] ao lado dos PBIs?" Isso leva ao tema da Velocidade (Velocity), que é importante para operar o Scrum na prática.

Definição

A velocidade é o tamanho total dos itens de backlog que uma equipe completa por Sprint. Geralmente é definida como:

Velocidade = Soma dos Story Points dos PBIs que satisfizeram a Definition of Done naquele Sprint

Pontos importantes:

• Apenas PBIs completados são contados (80% feito = 0)
• A unidade são geralmente Story Points (SP) (não horas)
• Medida por Sprint; frequentemente observada como uma média móvel de vários Sprints

O que são Story Points?

Story Points representam o tamanho relativo do trabalho. Em vez de valores absolutos como "dias-pessoa" ou "horas", estima-se comparando com uma tarefa de referência: "Qual o tamanho deste trabalho em comparação com aquela tarefa base?"

A escala comumente usada é a sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21...). Os intervalos crescentes refletem que "tarefas maiores têm mais incerteza, e distinções finas não fazem sentido".

Referência de estimativa da equipe FitLog:

Exemplo: Evolução da velocidade da equipe FitLog

Vamos ver os resultados da equipe FitLog nos últimos 6 Sprints:

Sprint 1: 18 pt (PBIs completados: 5 + 5 + 3 + 3 + 2)
Sprint 2: 22 pt (PBIs completados: 8 + 5 + 5 + 2 + 2)
Sprint 3: 25 pt (PBIs completados: 8 + 8 + 5 + 3 + 1)
Sprint 4: 23 pt
Sprint 5: 26 pt
Sprint 6: 24 pt
─────────────────────
Média dos últimos 3 Sprints: 24,3 pt ← velocidade atual

Isso nos diz que a equipe consegue lidar com aproximadamente 24 pontos por Sprint.

Como usar a velocidade

Uma vez que a velocidade se estabiliza, ela pode ser usada das seguintes formas:

1. Entender a capacidade no Sprint Planning

PO Ana: "Os PBIs candidatos para o próximo Sprint somam 32 pontos."
Developer Lucas: "Com uma média recente de 24 pontos, é realista assumir os primeiros 26 pontos (8+8+5+3+2)."

Em vez de "vamos dar um jeito com esforço", isso permite um acordo baseado em evidências.

2. Prever planos de release

Se todo o Product Backlog é de 180 pontos e a velocidade é de 24 pontos, a previsão é de 180 ÷ 24 = aproximadamente 7,5 Sprints para terminar.

Com isso, pode-se explicar aos stakeholders de forma fundamentada: "Provavelmente podemos lançar no final do Q3."

3. Melhoria contínua da precisão das estimativas

Quando discrepâncias são vistas como "estimado em 5 pontos, mas o esforço real foi de 10 pontos", isso se torna material para discussão na Retro.

Anti-padrões comuns

A velocidade é útil, mas quando usada incorretamente, pode destruir uma equipe.

❌ Anti-padrão 1: Tornar a velocidade um KPI

"Este mês a velocidade precisa ser maior do que o mês passado", "Ter menos velocidade que a outra equipe significa que vocês estão preguiçosos" — essa é a pior forma de usá-la.

A velocidade é um valor relativo próprio de cada equipe, e compará-la entre equipes não faz sentido. Além disso, pressionar a equipe para "aumentar a velocidade" apenas faz com que inflem as estimativas — a produtividade real não muda (e até diminui).

❌ Anti-padrão 2: Story Points = Tempo

Começar a usar "1 ponto = 4 horas" como conversão fixa torna os Story Points sem sentido. As vantagens da estimativa relativa (expressar incerteza, tornar a discussão mais eficiente) são perdidas, e regride para uma simples estimativa de esforço.

❌ Anti-padrão 3: Contar crédito parcial para PBIs incompletos

"Um PBI de 8 pontos está 70% completo, então contamos 5,6 pontos" — isso não deve ser feito. PBIs que não satisfazem a Definition of Done contam como 0 pontos.

Motivo: A velocidade é uma métrica para prever "quanto podemos completar no próximo Sprint". Contar trabalho em progresso distorce a previsão.

❌ Anti-padrão 4: Confiar nos valores logo após mudanças na equipe

Quando membros entram ou saem, ou a stack tecnológica muda, a velocidade reinicia. Depois de estabelecer uma nova configuração de equipe, a regra de ouro é executar primeiro 3-4 Sprints antes de recalcular a média.

A opção de não usar a velocidade

Nos últimos anos, cada vez mais equipes "não acompanham a velocidade". As métricas alternativas incluem:

• Throughput (Rendimento): Número de PBIs completados (sem pontos, mantendo a granularidade consistente e contando)
• Cycle Time (Tempo de ciclo): Tempo desde que um PBI é iniciado até ser concluído
• Lead Time (Tempo de espera): Tempo desde que um PBI é criado até ser concluído

Especialmente em combinação com Kanban, ou para equipes maduras que desejam reduzir o custo das estimativas, essas métricas podem ser mais eficazes.

Glossário essencial

Scrum/Agile tem muita terminologia própria, e conhecê-la ou não afeta significativamente a eficiência da comunicação dentro de uma equipe. Aprofundamos com exemplos reais.

Planning Poker

O que faz

O Planning Poker é uma técnica em que toda a equipe estima os Story Points dos PBIs. Em vez de um engenheiro experiente decidir "isso são 5 pontos", todos os membros revelam suas cartas simultaneamente e chegam a um consenso.

Por que o formato "Pôquer"?

Para evitar o "efeito de ancoragem", onde as pessoas são arrastadas pela opinião da pessoa mais vocal ou com mais experiência. Se alguém diz primeiro "isso são 8 pontos, não é?", os outros membros acham difícil dizer "eu acho que são 3". Todos revelam suas cartas simultaneamente para evitar isso.

Como funciona (exemplo da equipe FitLog)

As cartas usam a sequência de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, ?, ☕). "?" significa "não sei" e "☕" significa "preciso de uma pausa".

Passo 1: Explicar o PBI

PO Ana: "Próximo: 'Enviar lembretes via notificação push'. Se um usuário configurou um horário e não registrou treino naquele dia, enviar uma notificação."

Passo 2: Perguntas e respostas

Developer Lucas: "A mensagem da notificação pode ser personalizada?"
PO Ana: "Não, uma mensagem fixa está bem."
Developer Gabriel: "Planejamos usar a infraestrutura de notificações existente do servidor?"
PO Ana: "Sim, partindo da infraestrutura existente."

Passo 3: Todos revelam suas cartas simultaneamente

Passo 4: Pedir aos valores extremos que expliquem

Valor mais baixo, Gabriel: "Do lado BE, é só adicionar uma chamada à infraestrutura de notificações existente, então 3."
Valor mais alto, Isabela: "Do lado Android, preciso implementar 3 coisas: salvar a configuração do usuário, um job periódico e o tratamento de notificações. Da última vez que fiz algo parecido demorou bastante, por isso coloquei 13."

Passo 5: Votar novamente após a discussão

Após a discussão, todos convergem para "8". Acordo final em 8 pontos.

Pontos-chave

• Não se apressar a votar: Revelar as cartas somente após as P&R terem alinhado os pressupostos
• Não culpar quem diverge: A divergência é causada por diferenças de informação; compartilhá-la é o objetivo
• Não gastar muito tempo: Mirar em 5-10 minutos por PBI. PBIs sem acordo voltam para o Refinement.

Backlog Refinement

O que faz

O Refinement é a atividade contínua de manutenção do Product Backlog. Concretamente:

• Dividir PBIs muito grandes
• Concretizar os critérios de aceitação dos PBIs prioritários
• Remover PBIs obsoletos
• Estimar (frequentemente usado como sessão de Planning Poker)

Quando fazer

O Scrum Guide não o define como um evento independente, mas a maioria das equipes dedica 1-2 horas semanais. Muitas equipes o programam por volta da metade do Sprint.

Definition of Ready

Um conceito às vezes discutido em contraste com o DoD na prática é a Definition of Ready. A ideia é que quando um PBI atinge o estado Ready por meio do Refinement, ele pode ser levado para o Planning.

Exemplo de definição de Ready da equipe FitLog:

• Escrita no formato User Story
• Possui 3 ou mais critérios de aceitação
• Todos os membros da equipe entendem o conteúdo
• Dividida em 8 pontos ou menos
• Se existem dependências externas, elas foram acordadas com as partes envolvidas

O princípio INVEST (Aprofundamento)

As 6 qualidades que um bom PBI deveria satisfazer. Vamos ver cada uma com exemplos.

Hierarquia de User Stories — Tema, Epic, Story, Tarefa

O Product Backlog é uma lista unidimensional, mas na prática costuma-se pensar em 4 níveis.

Tema: Melhorar o engajamento do usuário
└─ Epic: Mecanismos para promover a continuidade do treino
   ├─ User Story: Pode ver o progresso dos últimos 30 dias em gráfico [8 pt]
   │  ├─ Tarefa: Implementação de API
   │  ├─ Tarefa: Implementação de UI iOS
   │  └─ Tarefa: Implementação de UI Android
   ├─ User Story: Pode receber notificações de lembrete [8 pt]
   └─ User Story: Exibir dias consecutivos registrados [3 pt]

Os PBIs que aparecem no Backlog são principalmente Epics e User Stories.

Burndown Chart / Burnup Chart

Burndown Chart

Um gráfico que visualiza o progresso do trabalho restante durante um Sprint. Observa-se como o progresso real se move em relação à linha ideal (uma linha que diminui uniformemente).

pt restantes
24┤●
22┤  ●
20┤    ●─ Linha ideal ────
18┤      ╲╲
16┤        ●(Real, ligeiramente atrasado)
14┤          ●
12┤            ╲
 0┤──────────────●
    Dia1 Dia3 Dia5 Dia7 Dia10

Se a curva real permanece consistentemente acima da linha ideal → sinal de que o Sprint Goal está em risco. Considerar agir cedo (redução de scope, pedir ajuda).

Burnup Chart

Um gráfico que exibe o trabalho concluído e o scope em linhas separadas. É mais fácil entender a situação do que um Burndown quando ocorrem mudanças de scope, frequentemente usado para o acompanhamento de planos de release.

MVP e MMP

MVP (Minimum Viable Product)

O produto mínimo necessário para validar uma hipótese. Um conceito popularizado por "A Startup Enxuta" de Eric Ries.

Exemplo de MVP do FitLog: "Os usuários abrem o app, registram manualmente sua distância percorrida e podem ver uma lista de registros anteriores." Sem gráficos, notificações ou funções sociais. Com isso, valida-se a hipótese "As pessoas pagarão por um app de acompanhamento de treino?"

MMP (Minimum Marketable Product)

O produto mínimo vendável no mercado. Um nível mais rico que o MVP. O MVP é para usuários internos/limitados; o MMP é para o público geral.

Timebox

Os eventos Scrum têm limites máximos de tempo. Isso é o timebox.

Efeitos do timebox:

• Evita que as discussões se dispersem: O tempo limitado força o foco no que é essencial
• Evita que as reuniões inchem: Permitir extensões leva a um crescimento infinito
• Terminar mais cedo está OK: Se o objetivo foi alcançado, pode ser mais curto

Spike

Trabalho em timebox para investigar tecnologia ou resolver incerteza. Um termo que vem do XP mas amplamente utilizado no Scrum.

Quando usar:

• "Não está claro se isso pode ser realizado com a nova biblioteca" → Validar em um timebox de 1 dia
• "Não é possível estimar o custo de refactoring desta parte do código existente" → Investigar meio dia
• "Não está claro se a velocidade de resposta da API atende aos requisitos" → Criar um protótipo

O entregável de um spike é conhecimento, não código. O código escrito para validação é fundamentalmente descartado.

Limite WIP (Work In Progress Limit)

Uma regra que limita o número de itens trabalhados simultaneamente. Vem do Kanban mas cada vez mais adotado em equipes Scrum.

Exemplo: "Máximo de 3 itens simultaneamente na coluna 'Em Progresso'"

Efeitos:

• Foco na conclusão: Concluir 3 itens completamente traz mais valor do que avançar 5 pela metade
• Os gargalos se tornam visíveis: Onde está travando fica claro
• Reduz os custos do multitarefa: A troca de contexto reduz significativamente a produtividade

Dívida Técnica (Technical Debt)

Um conceito cunhado por Ward Cunningham que usa a dívida como metáfora para o estado em que você terá que pagar juros (custos adicionais) mais tarde porque tomou um atalho às custas da manutenibilidade futura.

Tipos:

• Dívida intencional: Implementado rapidamente sabendo "prazo primeiro, refatorar depois"
• Dívida não intencional: Surgida por falta de conhecimento ou erros de design
• Dívida ambiental: Surgida relativamente à medida que as tecnologias circundantes envelhecem (legacy)

Outros termos úteis para conhecer

Equívocos comuns e armadilhas

"Não escrever documentação" é um erro

Interpretando mal o "software funcionando sobre documentação abrangente" do Manifesto Ágil, algumas equipes avançam com zero documentação. A interpretação correta é escrever a documentação necessária para a operação.

"Não planejar" também é um erro

Abandonar o planejamento se escondendo atrás de "resposta a mudanças" também está errado. O Scrum tem planejamento em múltiplos níveis (Product Goal, Sprint Goal, plano diário). Agile não significa não planejar, mas planejar de forma adaptativa.

O Daily Scrum vira um relatório de status

Um Daily Scrum transformado em reunião de relatório de progresso para o PM ou a gestão perdeu seu propósito original. O Daily é um espaço de inspeção e adaptação pelos Developers, para os Developers.

A duração do Sprint muda frequentemente

Mudar para "desta vez estamos ocupados, então 3 semanas" ou "vamos tentar 1 semana" torna impossível medir a velocidade (velocidade da equipe). A duração do Sprint deveria ser fixa.

Casos em que Agile/Scrum não se aplica

Não é uma solução universal. Nas situações a seguir, outra abordagem pode ser mais apropriada:

• Os requisitos estão completamente fixos e as mudanças raramente ocorrem (ex: conformidade regulatória)
• Áreas em que a segurança é extremamente crítica e releases incrementais não são permitidas
• Quando a equipe é extremamente grande e os custos de coordenação superam os benefícios

No entanto, dado que existem métodos de escalabilidade para Scrum em larga escala (LeSS, SAFe, etc.), é precipitado concluir imediatamente "grande demais para isso".

Resumo

• Agile é uma mentalidade e conjunto de valores. O núcleo é "entregar software funcionando em ciclos curtos" e "dar boas-vindas às mudanças".
• Scrum é um framework representativo para praticar Agile.
• O Scrum consiste em "3 Responsabilidades, 5 Eventos e 3 Artefatos" e repete Sprints de duração fixa.
• Copiar apenas a forma leva ao ritual vazio. Entender os valores vem primeiro, o framework vem depois.

O objetivo não é "fazer Scrum" mas "entregar continuamente produtos valiosos". Pensar no framework como uma ferramenta para esse propósito é, acredito, a chave para um relacionamento duradouro com ele.

Referências

• Manifesto para Desenvolvimento Ágil de Software
• Guia do Scrum 2020
• Jeff Sutherland, "Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo"