Metodologias ágeis: Scrum e Kanban na prática

1. Fundamentos das metodologias ágeis

O Manifesto Ágil, publicado em 2001, estabeleceu quatro valores fundamentais: indivíduos e interações mais que processos e ferramentas; software em funcionamento mais que documentação abrangente; colaboração com o cliente mais que negociação de contratos; e responder a mudanças mais que seguir um plano. Esses valores são sustentados por doze princípios que incluem entregas frequentes, aceitação de mudanças tardias e reflexão regular da equipe.

É crucial distinguir entre mindset ágil — uma filosofia de trabalho baseada em adaptação contínua, feedback rápido e melhoria incremental — e os frameworks operacionais como Scrum e Kanban. O mindset é a cultura; os frameworks são as ferramentas que implementam essa cultura.

A escolha entre Scrum, Kanban ou uma abordagem híbrida depende do contexto:
- Scrum: ideal para projetos com requisitos estáveis durante sprints curtos (2-4 semanas) e equipes dedicadas.
- Kanban: recomendado para fluxos contínuos com prioridades dinâmicas, equipes de suporte ou manutenção.
- Híbrido (Scrumban): útil quando se deseja a estrutura do Scrum com a flexibilidade do Kanban.

2. Scrum: papéis, eventos e artefatos na prática

Papéis essenciais

  • Product Owner (PO): responsável por maximizar o valor do produto, gerenciar o Product Backlog e priorizar itens.
  • Scrum Master: facilita o processo, remove impedimentos e garante que o time siga as práticas Scrum.
  • Time de Desenvolvimento: equipe multifuncional e auto-organizável, tipicamente de 3 a 9 pessoas.

Eventos do Sprint

  • Sprint Planning: define o que será entregue no Sprint (Sprint Backlog) e como será feito.
  • Daily Scrum: reunião de 15 minutos para sincronizar atividades e identificar impedimentos.
  • Sprint Review: demonstração do Incremento para stakeholders e coleta de feedback.
  • Sprint Retrospective: reflexão sobre o processo e definição de melhorias.

Artefatos

  • Product Backlog: lista priorizada de funcionalidades, melhorias e correções.
  • Sprint Backlog: itens selecionados do Product Backlog para o Sprint atual.
  • Incremento: versão utilizável do produto ao final de cada Sprint.

Exemplo de Sprint Backlog (formato texto):

Sprint Backlog - Sprint 3 (15/04 a 28/04)

Prioridade 1:
- [US-12] Implementar login com Google OAuth (estimativa: 5 pontos)
- [US-13] Criar tela de cadastro de usuário (estimativa: 3 pontos)

Prioridade 2:
- [US-14] Validação de formulário de contato (estimativa: 2 pontos)
- [B-05] Corrigir bug no cálculo de frete (estimativa: 1 ponto)

Tarefas técnicas:
- [TEC-07] Atualizar dependências de segurança (estimativa: 2 pontos)

Total de pontos planejados: 13
Capacidade do time: 15 pontos

3. Kanban: fluxo contínuo e visualização do trabalho

Princípios fundamentais

  1. Visualizar o trabalho: mapear o fluxo de valor em colunas.
  2. Limitar o trabalho em progresso (WIP): restringir itens simultâneos por coluna.
  3. Gerenciar o fluxo: otimizar a movimentação dos cartões.
  4. Tornar políticas explícitas: definir regras claras de transição.
  5. Implementar ciclos de feedback: revisões regulares do processo.

Montagem do quadro Kanban

Quadro Kanban - Equipe de Suporte

| BACKLOG (10) | ANALISANDO (WIP:3) | DESENVOLVENDO (WIP:3) | TESTANDO (WIP:2) | CONCLUÍDO |
|--------------|--------------------|------------------------|------------------|------------|
| Ticket #45   | Ticket #42         | Ticket #38            | Ticket #35       | Ticket #30 |
| Ticket #46   | Ticket #43         | Ticket #39            | Ticket #36       | Ticket #31 |
| Ticket #47   | Ticket #44         |                        |                  | Ticket #32 |
| Ticket #48   |                    |                        |                  |            |

Políticas explícitas:
- "Analisando": ticket deve ter descrição completa e critérios de aceite.
- "Desenvolvendo": apenas 3 tickets simultâneos; novo ticket só entra quando um sai.
- "Testando": testes automatizados devem passar antes de mover para Concluído.

Métricas-chave

  • Lead time: tempo desde a criação do ticket até sua conclusão.
  • Cycle time: tempo desde o início do trabalho até a conclusão.
  • Throughput: número de tickets concluídos por unidade de tempo.

4. Comparação prática: Scrum vs Kanban

Tabela comparativa - Scrum vs Kanban

| Característica          | Scrum                          | Kanban                      |
|-------------------------|--------------------------------|-----------------------------|
| Cadência                | Sprints fixos (2-4 semanas)    | Fluxo contínuo              |
| Planejamento            | No início de cada Sprint       | Contínuo, sob demanda       |
| Mudanças durante ciclo | Bloqueadas (após Sprint start) | Permitidas a qualquer tempo |
| Papéis fixos            | PO, SM, Time                   | Não exige papéis específicos|
| Métricas principais     | Velocity, Burndown             | Lead time, Cycle time       |
| Melhor para            | Projetos com escopo definido   | Suporte, manutenção, urgências|

Cenários recomendados:
- Scrum: desenvolvimento de novo produto com requisitos estáveis por sprint.
- Kanban: equipe de suporte técnico, manutenção de sistemas legados, operações.
- Híbrido: projetos que alternam entre sprints planejados e demandas emergenciais.

5. Implementação híbrida: Scrumban na prática

Scrumban combina a estrutura de sprints do Scrum com os limites de WIP do Kanban. É particularmente útil quando a equipe precisa de previsibilidade (sprints) mas também lida com interrupções frequentes.

Adaptação de papéis e cerimônias

  • PO mantém backlog priorizado, mas permite reabastecimento contínuo.
  • Scrum Master foca em métricas de fluxo, não apenas velocity.
  • Daily permanece, mas foca no fluxo do quadro Kanban.
  • Retrospectiva ocorre a cada sprint ou a cada 2 semanas, independente do ciclo.

Exemplo de quadro Scrumban

Quadro Scrumban - Sprint 4 (01/05 a 14/05)

| BACKLOG | SPRINT (WIP:5) | DESENVOLVENDO (WIP:3) | TESTANDO (WIP:2) | CONCLUÍDO |
|---------|----------------|-----------------------|------------------|------------|
| US-20   | US-15          | US-12                 | US-10            | US-08      |
| US-21   | US-16          | US-13                 | US-11            | US-09      |
| US-22   | US-17          |                       |                  |            |
|         | US-18          |                       |                  |            |
|         | US-19          |                       |                  |            |

Políticas adicionais:
- Sprint Backlog é reabastecido semanalmente com itens de alta prioridade.
- Limite de WIP no "Desenvolvendo" impede sobrecarga do time.
- Itens urgentes (críticos) podem pular para "Desenvolvendo" com aprovação do PO.

6. Ferramentas e métricas para monitoramento

Ferramentas digitais

  • Jira: mais completa para Scrum e Kanban, com relatórios nativos.
  • Trello: simples e visual, ideal para equipes pequenas.
  • Notion: flexível, combina documentação com gestão de projetos.
  • Azure Boards: integração com DevOps e pipelines CI/CD.

Gráficos essenciais

Burndown chart (Scrum):

Burndown - Sprint 3

Dia | Ideal | Real
----|-------|------
 1  | 13    | 13
 2  | 11.7  | 12
 3  | 10.4  | 10
 4  | 9.1   | 9
 5  | 7.8   | 8
 6  | 6.5   | 6
 7  | 5.2   | 5
 8  | 3.9   | 4
 9  | 2.6   | 2
10  | 1.3   | 1
11  | 0     | 0

Interpretação: time está dentro do esperado, com leve atraso nos dias 2 e 5.

Cumulative Flow Diagram (Kanban):

CFD - Semana 16 a 20

Semana | Backlog | Em Andamento | Concluído
-------|---------|--------------|----------
16     | 20      | 8            | 5
17     | 18      | 7            | 9
18     | 15      | 6            | 14
19     | 12      | 5            | 20
20     | 10      | 4            | 26

Interpretação: WIP está diminuindo (bom sinal), throughput médio de 5 tickets/semana.

7. Armadilhas comuns e como evitá-las

Armadilha 1: Scrum sem inspeção e adaptação

Problema: rituais mecanizados — daily de 30 minutos virando reunião de status, retrospectiva sem ações concretas.
Solução: limitar daily a 15 minutos com foco em impedimentos; na retrospectiva, definir no máximo 3 ações mensuráveis.

Armadilha 2: Kanban sem limites de WIP

Problema: equipe pega múltiplas tarefas simultâneas, aumentando lead time e reduzindo foco.
Solução: definir WIP inicial conservador (ex: 2 por pessoa) e ajustar com base em dados de cycle time.

Armadilha 3: Falta de autonomia da equipe

Problema: gerentes externos definem prioridades sem consultar o time, transformando Scrum em "mini-waterfall".
Solução: fortalecer o papel do PO como única voz de priorização; proteger o time de interferências externas.

Armadilha 4: Micromanagement disfarçado

Problema: Scrum Master ou gerente monitora cada tarefa individualmente, minando a auto-organização.
Solução: focar métricas de time (velocity, throughput) em vez de métricas individuais; confiar na equipe.

Referências