Aula 2 – Iteração eficaz: planejamento, fluxo e DoR/DoD

• Aula: 2 - Iteração eficaz: planejamento, fluxo e DoR/DoD
• Objetivos: Estruturar o planejamento de iterações ágeis, explicitar políticas de fluxo e aplicar Definition of Ready (DoR) e Definition of Done (DoD) para elevar a previsibilidade e a qualidade das entregas.
• Curso: CST em Análise e Desenvolvimento de Sistemas
• Série: 4º período (semestral)
• Disciplina: Gerenciamento de Projetos Ágil

1. Por que falar de iteração, fluxo, DoR e DoD?

A entrega de valor em ambientes ágeis depende de ciclos curtos, metas claras e um fluxo de trabalho visível, controlado por políticas objetivas. Três pilares sustentam esse resultado:

• Planejamento de iteração: define o propósito do ciclo e o que será entregue.
• Políticas de fluxo: explicitam como o trabalho avança e como é limitado (WIP), garantindo foco.
• DoR/DoD: qualificam entrada e saída de trabalho, evitando iniciar itens imaturos e concluir sem qualidade.

Ao dominar esses elementos, equipes reduzem retrabalho, aumentam previsibilidade e sustentam qualidade técnica e de produto.

2. Planejamento de iteração (2.1)

2.1.1 Conceitos e objetivos

• Iteração: janela de tempo com objetivo de aprendizagem e entrega de valor (ex.: Sprint) ou ciclo cadenciado de reabastecimento em Kanban.

• Objetivo da iteração (Sprint Goal): enunciado conciso do resultado desejado, conectando backlog ao propósito do produto.

• Entradas: visão de produto, metas de curto prazo, backlog priorizado, capacidade do time, riscos e dependências.

• Saídas: objetivo da iteração, backlog selecionado, plano inicial de execução, riscos e critérios de sucesso claros.

2.1.2 Níveis de planejamento e alinhamento

• Estratégico: visão e objetivos mensuráveis.
• Tático: roadmap e releases.
• Operacional: iteração (Sprint/Replenishment) e tarefas.
• Alinhamento: cada iteração deve contribuir para objetivos mensuráveis (outcomes), não apenas para a entrega de itens (outputs).

2.1.3 Capacidade e compromisso

• Capacidade: estimativa do volume de trabalho que o time consegue concluir com qualidade.

• Fontes para projeção:

  • Histórico (velocidade/throughput).
  • Disponibilidade do time (feriados, folgas, treinamentos).
  • Complexidade e riscos dos itens.

• Compromisso responsável:

  • Selecionar itens que caibam na capacidade.
  • Garantir que atendam ao DoR antes de entrar.
  • Ajustar o plano conforme surgem fatos novos.

Exemplo de cálculo simples de capacidade:

• Pessoas ativas: 6
• Disponibilidade média prevista: 80%
• Throughput histórico médio: 12 itens/iteração
• Ajuste por riscos/dependências: -15%
• Capacidade alvo: ~10 itens

2.1.4 Seleção de itens e objetivos

• Comece pelo objetivo da iteração.
• Selecione itens que melhor suportem o objetivo (coerência).
• Prefira itens menores e independentes para aumentar fluxo.
• Garanta DoR atendido para cada item antes de puxar para a iteração.

Template de objetivo de iteração:

2.1.5 Plano operacional da iteração

• Quebra de trabalho: fatiar histórias em tarefas técnicas pequenas (ex.: PRs até 300 linhas, testes, migrações).
• Sequenciamento: ordem que reduz bloqueios e riscos antes.
• Dependências: explicitar e alinhar janelas com times/fornecedores.
• Riscos: registrar, mitigar cedo e monitorar diariamente.
• Critérios de sucesso: indicadores claros do resultado esperado.

2.1.6 Iteração em Scrum vs. Kanban

• Scrum: Sprint fixa com Sprint Goal, Sprint Backlog e revisão de incremento.
• Kanban: fluxo contínuo com cadências de reabastecimento, limites de WIP e revisão de métricas de fluxo.
• Convergência: em ambos, políticas explícitas, DoR/DoD e melhoria contínua.

3. Políticas de fluxo, DoR e DoD (2.2)

3.1 Políticas de fluxo: tornando o trabalho previsível

• Política de fluxo: regras explícitas que orientam como itens entram, avançam e saem de cada etapa.

• Benefícios:

  • Visibilidade do processo e redução de variabilidade.
  • Identificação e remoção de gargalos.
  • Aumento da qualidade e da previsibilidade.

Elementos essenciais:

• Colunas/etapas claras (ex.: Ready, In Progress, Code Review, Test, Ready for Release, Done).
• Regras de entrada/saída por coluna.
• Limites de trabalho em progresso (WIP).
• Classes de serviço (ex.: urgente/expedite, padrão, data fixa).
• Políticas de bloqueio/desbloqueio e gestão de filas.

Diagrama de fluxo de trabalho (exemplo):

Exemplo de política escrita:

3.2 Definition of Ready (DoR)

• Finalidade: garantir que um item esteja compreendido, estimável e preparado para execução sem bloqueios óbvios.

• Benefícios:

  • Reduz interrupções e retrabalho.
  • Aumenta a qualidade do plano da iteração.
  • Torna a seleção de itens mais objetiva.

Checklist DoR (exemplo adaptável):

• Valor e objetivo do item descritos de forma clara.
• Critérios de aceite definidos e testáveis.
• Dependências mapeadas e janelas alinhadas.
• Dados necessários identificados (máscaras e privacidade quando aplicável).
• Impactos em UX e API sinalizados (protótipo/link).
• Riscos conhecidos e plano de mitigação.
• Tamanho adequado (fatia que caiba na iteração).
• Estratégia de testes discutida (unitário, integração, e2e).
• Considerações de segurança e conformidade relevantes identificadas.

Template de item com DoR e critérios de aceite:

3.3 Definition of Done (DoD)

• Finalidade: definir o que significa “concluído” de maneira verificável para manter qualidade e reduzir débito técnico.

• Benefícios:

  • Qualidade consistente entre equipes.
  • Menos surpresas em produção.
  • Maior confiança em releases frequentes.

Níveis de DoD:

• Item de backlog (história/tarefa).
• Feature/épico.
• Release (pronto para usuários).

Checklist DoD (história):

• Código implementado e revisado (peer review).
• Cobertura mínima de testes automatizados atendida.
• Testes funcionais/integração aprovados em CI.
• Segurança básica verificada (linters, SAST, dependabot).
• Observabilidade: logs/metricas/tracing preparados.
• Documentação mínima atualizada (README/ADR/CHANGELOG).
• Feature toggle configurado (se aplicável).
• Migrações de dados validadas e reversíveis.
• Critérios de aceite atendidos e evidenciados.
• Implantado em ambiente de validação/aprovação.

Checklist DoD (release):

• Notas de versão publicadas.
• Plano de rollback testado.
• Monitoramento e alertas configurados.
• Indicadores de negócio e técnicos alinhados.
• Aprovações formais quando exigidas por conformidade.

Exemplo de evidências de DoD:

4. Guia prático: passo a passo da iteração

1. Preparação (pré-iteração/refinamento)

• Atualize prioridades e alinhe objetivo potencial.
• Aplique o DoR nos itens candidatos.
• Quebre itens grandes; elimine dependências desnecessárias.
• Levante riscos e planeje mitigação.

2. Planejamento

• Defina o objetivo da iteração (resultado desejado).
• Projete capacidade e selecione itens coerentes.
• Esboce plano inicial e políticas específicas da iteração (ex.: foco em reduzir WIP).
• Registre critérios de sucesso e métricas a observar.

3. Execução

• Puxe trabalho respeitando WIP.
• Trate bloqueios imediatamente, visível no quadro.
• Garanta revisão de código e testes contínuos.
• Mantenha o objetivo da iteração como bússola para decisões.

4. Validação e fechamento

• Verifique DoD de cada item e do incremento.
• Demonstre o que foi alcançado e o que foi aprendido.
• Atualize métricas de fluxo e outcomes do objetivo.
• Capture melhorias nas políticas e checklists.

5. Fatiamento e dependências: reduzindo risco

• Preferir fatias verticais: entregar valor do fim ao fim, ainda que pequeno.

• Técnicas de fatiamento:

  • Por cenário/segmento (ex.: 20% da base).
  • Por caminho feliz primeiro, depois exceções.
  • Por variação de interface (mobile/desktop).
  • Por integração simulada primeiro (contract tests), depois real.

• Tratamento de dependências:

  • Tornar visíveis no quadro.
  • Antecipar validações (contratos, chaves de API, janelas).
  • Planejar fallbacks e feature toggles.

6. Limites de WIP e classes de serviço

• Por que limitar WIP?

  • Reduz multitarefa, tempo de espera e contexto alternado.
  • Acelera feedback e descoberta de gargalos.

• Como escolher limites:

  • Comece pequeno (ex.: nº de pessoas - 1).
  • Ajuste com base em bloqueios e tempo de ciclo observado.

• Classes de serviço:

  • Urgente/Expedite: fura fila, exige pós-mortem.
  • Data Fixa: proteger antecedência mínima.
  • Padrão: fluxo normal.
  • Intangível: redução de débito técnico, melhorias internas.

7. Políticas claras por coluna: exemplos práticos

Exemplo detalhado de políticas escritas para um time web:

8. Modelos e checklists reutilizáveis

Checklist DoR (adaptável por equipe):

• Descrição clara orientada a usuário (quem, o quê, por quê).
• Critérios de aceite testáveis definidos.
• Protótipo/Contrato de API disponível (quando aplicável).
• Dados e privacidade endereçados (anonimização/mascara).
• Dependências e janelas confirmadas.
• Riscos e impacto mapeados.
• Tamanho adequado à iteração.

Checklist DoD (história):

• Código analisado por pares.
• Testes unitários e integração passando no CI.
• Linters/qualidade estática ok.
• Segurança básica verificada (SAST/deps).
• Documentação mínima atualizada.
• Telemetria e logs preparados.
• Deploy em validação aprovado.
• Critérios de aceite cumpridos com evidências.

Template de cartão de item:

# Título
Como "tipo de usuário", quero "capacidade" para "benefício".

## Contexto
- Link para visão/épico:

- Hipótese de valor:

## Critérios de Aceite
- [ ] ...

## Sinais de Pronto (DoR)
- [ ] Critérios de aceite
- [ ] Dependências tratadas
- [ ] Riscos mitigados
- [ ] Fatia cabe na iteração

## Evidências de Concluído (DoD)
- [ ] PRs aprovados
- [ ] Testes verdes
- [ ] Docs/logs/telemetria
- [ ] Deploy validado

9. Estudo de caso breve

Cenário: Time de 6 pessoas focado em aumentar conversão do checkout.

• Objetivo da iteração: aumentar conversão em 5% por meio de pagamento em 1 clique e redução de campos.

• Políticas:

  • WIP total em “Dev” = 4.
  • Expedite apenas para incidentes P1, com análise pós-incidente obrigatória.

• Seleção inicial:

  • HIST-231 Pagamento 1 clique (backend + frontend).
  • HIST-229 Redução de campos.
  • HIST-235 Telemetria.

• Riscos:

  • Integração com gateway externo em janela limitada.
  • Migração de esquema de cartão tokenizado.

• Mitigações:

  • Contratos de API validados e mocks prontos antes do desenvolvimento.
  • Feature toggle e rollout gradual de 20%.

Resultados esperados:

• Itens menores, fluxo mais rápido, validação de hipótese com telemetria e capacidade de rollback.

10. Exercícios práticos

🔗 Exercício 1

11. Boas práticas e armadilhas comuns

Boas práticas:

• Objetivos claros e mensuráveis conectados a outcomes.
• Itens pequenos e independentes; WIP baixo.
• Políticas escritas, visíveis e revisadas periodicamente.
• DoR/DoD co-criados pela equipe e auditáveis por evidências.

Armadilhas:

• Confundir “pronto” com “codado”: DoD pobre gera débitos.
• Puxar itens sem DoR: bloqueios e interrupções constantes.
• WIP alto: filas grandes e lead time imprevisível.
• Objetivos vagos: difícil avaliar sucesso e aprender.

Conclusão

Planejar uma iteração eficaz significa alinhar um objetivo claro a um conjunto enxuto de itens prontos para execução, sustentados por políticas de fluxo explícitas e por definições de pronto e concluído verificáveis. Quando DoR e DoD são aplicados com rigor e o WIP é limitado, o time reduz variabilidade, aumenta previsibilidade e consolida qualidade, criando as condições para aprender rapidamente e entregar valor de forma contínua.

Próxima aula

Ritos, comunicação e previsibilidade: exploraremos as cerimônias ágeis (refinamento, planejamento, dailies, review e retrospectiva), práticas de comunicação efetiva e técnicas de estimativas e previsibilidade para acompanhamento de projetos.