Aula 10 — Planejamento de iteração, políticas de fluxo e acordos de trabalho (DoR/DoD)

Planejamento de iteração e gestão de fluxo

Curso: CST em Análise e Desenvolvimento de Sistemas
Disciplina: Gerenciamento de Software Ágil
Tema: Planejamento de iteração, limitação de WIP, DoR e DoD com foco em fluxo contínuo

1. Cenário

Dando continuidade às melhorias no checkout mobile da loja virtual, a equipe de desenvolvimento inicia o planejamento da próxima iteração (Sprint de 2 semanas). Na iteração anterior, observou-se acúmulo de tarefas em validação, atrasos por falta de informações claras antes do início do desenvolvimento e bugs detectados apenas após a entrega em produção.

Para organizar o trabalho, a equipe precisa definir o fluxo de trabalho no quadro Kanban/Scrum, pactuar os critérios de entrada (DoR) e saída (DoD) de cada item e selecionar a capacidade de trabalho ideal para garantir previsibilidade e qualidade.

Todos os dados apresentados neste exercício são hipotéticos.

2. Dados iniciais

A equipe é composta por 4 desenvolvedores e 1 profissional de QA. A capacidade máxima de esforço estimada para a iteração é de 30 pontos de história (story points).

O histórico das últimas 3 iterações registra o seguinte desempenho:

3. Atividade 1 — Limites de Trabalho em Progresso (WIP) e Políticas de Fluxo

Analise o quadro de tarefas atual da equipe durante o meio da iteração:

Responda:

1. Qual é o WIP total atual da equipe (tarefas em andamento entre “Em Desenvolvimento” e “Em Testes”)?
2. Sabendo que há 5 pessoas na equipe de execução, avalie se o WIP atual favorece ou prejudica a eficiência do fluxo de trabalho. Justifique.
3. Proponha um limite de WIP adequado para cada uma das colunas: Em Desenvolvimento, Em Code Review e Em Testes.
4. Explique a Lei de Little ($Tempo\ de\ Ciclo = \frac{WIP}{Vaz\tilde{a}o}$) e como a redução do WIP impacta o tempo de entrega (Lead Time) das histórias de usuário.

4. Atividade 2 — Construção da Definition of Ready (DoR)

Durante o refinamento do backlog, a seguinte história de usuário foi apresentada para estimativa:

“Como cliente mobile, quero poder pagar via Pix usando ‘Copia e Cola’ ou QR Code, para concluir meu pedido mais rapidamente.”

No entanto, a equipe identificou que não há protótipo de tela, os contratos da API de pagamento Pix não estão definidos e não foram alinhados os critérios para exceções de tempo limite (timeout).

Com base nessa situação:

1. Defina o conceito de Definition of Ready (DoR) e sua importância para a gestão de fluxo.
2. Escreva um checklist de DoR composto por pelo menos 4 critérios objetivos que uma história de usuário deve atender antes de ser puxada para o desenvolvimento.
3. Avalie se a história do pagamento via Pix apresentada acima atende à DoR proposta e determine se ela pode entrar no planejamento da iteração.

5. Atividade 3 — Construção da Definition of Done (DoD)

Na iteração anterior, uma história de alteração nos campos de pagamento foi marcada como concluída pelo desenvolvedor, mas gerou falhas em produção por falta de testes automatizados e por não ter passado por homologação em dispositivos iOS.

Responda:

1. Defina o conceito de Definition of Done (DoD) e diferencie DoD de Critérios de Aceite de uma história específica.
2. Elabore uma lista com pelo menos 5 critérios indispensáveis que façam parte da DoD da equipe (abrangendo código, testes, documentação e implantação).
3. Explique como uma DoD fraca ou negligenciada afeta o acúmulo de débito técnico e a confiabilidade das entregas.

6. Atividade 4 — Planejamento da Iteração (Sprint Backlog)

Considere a lista de histórias priorizadas disponíveis no Product Backlog:

Com base na velocidade média histórica da equipe e na capacidade planejada (25 a 30 pontos):

1. Selecione as histórias de usuário que devem compor o backlog da iteração.
2. Justifique a inclusão e a exclusão dos itens com base na capacidade da equipe, na prioridade e no status de pronto (DoR).
3. Qual é o total de pontos planejados para a iteração selecionada?
4. Se o Product Owner solicitar a inclusão imediata da história H3 no meio do planejamento, qual deve ser a postura da equipe de desenvolvimento?

7. Atividade 5 — Resolução de Gargalos durante a Iteração

Durante o 5º dia da iteração, a equipe observa o seguinte status no quadro Kanban:

• Em Desenvolvimento: 2 tarefas
• Em Code Review: 1 tarefa
• Em Testes / QA: 6 tarefas (acumuladas)

Sabe-se que há apenas 1 profissional dedicado exclusivamente ao QA, criando um gargalo evidente.

Responda:

1. Qual é o impacto do gargalo na etapa de testes para a meta da iteração?
2. Cite duas ações imediatas que os desenvolvedores podem tomar (aplicando o conceito de equipe multidisciplinar / Swarming) para destravar o fluxo.
3. Como as políticas explícitas de fluxo ajudam a evitar que essa situação volte a acontecer nas próximas iterações?

8. Entrega

Cada grupo deverá apresentar:

• Análise de WIP e limites propostos para o fluxo de trabalho.
• Checklist oficial de Definition of Ready (DoR).
• Checklist oficial de Definition of Done (DoD).
• Seleção final do Backlog da Iteração com a devida justificativa de capacidade.
• Plano de ação para resolução de gargalos de fluxo.

Critério de avaliação: consistência na aplicação dos limites de WIP, clareza e objetividade nos critérios de DoR/DoD, realismo no planejamento de capacidade e coerência nas decisões de fluxo de trabalho.

Conceitos importantes para o exercício

1. Definition of Ready (DoR)

A Definition of Ready (DoR) é um acordo de trabalho entre a equipe de desenvolvimento e o Product Owner. Ela estabelece as condições mínimas necessárias para que um item do backlog seja considerado pronto para ser puxado para uma iteração de desenvolvimento.

Objetivo: Evitar interrupções e impedimentos durante o desenvolvimento causados por falta de clareza, dependências não resolvidas ou especificações incompletas.

2. Definition of Done (DoD)

A Definition of Done (DoD) é um checklist compartilhado que declara a qualidade e o estado de conclusão exigi dos para que qualquer funcionalidade seja considerada pronta para release em produção.

Ao contrário dos Critérios de Aceite (que são específicos de uma história), a DoD se aplica universalmente a todos os itens entregues pela equipe.

3. Trabalho em Progresso (WIP - Work in Progress)

O WIP representa a quantidade de tarefas iniciadas que ainda não foram concluídas. Limitar o WIP é uma prática fundamental do Kanban para manter o fluxo contínuo, reduzir a alternância de contexto (context switching) e diminuir o Lead Time.

Regra prática: “Pare de começar e comece a terminar.”

4. Velocidade (Velocity)

A Velocidade é uma métrica que indica a quantidade média de trabalho (geralmente medida em pontos de história) que uma equipe conclui como “Done” durante uma iteração. É uma métrica histórica e empírica utilizada para prever a capacidade de entrega em iterações futuras.

Resumo dos conceitos