Voltar para Estratégia e planejamento

Templates de definição de pronto

Entregue com confiança e elimine ambiguidades. Use o template de definição de pronto para estabelecer um padrão compartilhado de qualidade, garantindo que cada funcionalidade esteja realmente 'concluída' antes de chegar aos seus usuários.

4 templates

Explore mais

O que é um template de Definition of Done?

Um template Definition of Done (DoD) é uma lista de verificação abrangente de critérios técnicos e funcionais que uma história de usuário ou tarefa deve atender antes de ser considerada "Concluída". Ao contrário dos "Critérios de Aceitação" (que são exclusivos de cada história), a DoD é um padrão global aplicado a todo trabalho. Isso evita a "dívida técnica" ao garantir que testes, documentação e conformidade nunca sejam pulados em nome da velocidade.

A auditoria de "Qualidade": 3 maneiras de garantir padrões "prontos para entrega"

Uma DoD só é tão boa quanto a disciplina do time. Antes de finalizar seu template, aplique essas três "checagens de saúde" de especialistas:

1. A auditoria "Trabalho Não Concluído"

A Auditoria: Você está movendo histórias para Concluído enquanto deixa a documentação ou os testes de integração para o próximo sprint? A Solução: Audite a Qualidade adiada. Um DoD profissional deve incluir Testes de regressão e Atualização da documentação. Se não estiver documentado e testado em todo o sistema, não está Concluído; está apenas Desenvolvido. Seu template deve listar explicitamente nenhuma nova dívida técnica como requisito.

2. Teste da Verdade Automatizada

A auditoria: Seu DoD se baseia em "promessas humanas" (por exemplo, "Eu revisei o código")? A correção: Faça uma auditoria para Verificação Binária. Sempre que possível, substitua verificações manuais por automatizadas. Em vez de "Código revisado", use "Pull Request aprovado por 2 colegas." Em vez de "Testado unitariamente", use "Cobertura de testes unitários > 80%." Isso elimina a subjetividade e garante que o status Pronto seja mensurável e indiscutível.

3. O conflito "Global vs. Local"

A auditoria: Seu DoD é tão longo que o time ignora metade dele para cumprir a meta da sprint? A solução: Audite com foco na realidade. Comece com um "DoD mínimo viável" e amplie-o à medida que o time amadurece. Se o time não consegue realizar, de forma realista, uma auditoria de segurança completa a cada sprint, não a inclua no DoD de nível da história. Em vez disso, mova-a para a "Definição de lançamento". Isso mantém o DoD diário alcançável e respeitado.

Estruturas estratégicas: os três níveis do "Done"

Uma organização profissional costuma usar três templates distintos para gerenciar diferentes estágios de conclusão:

  • Nível 1: DoD da história de usuário (nível de sprint)

    • Foco: Qualidade do código, revisão por pares e atendimento a critérios de aceitação específicos.

    • Exemplo: "Testes unitários aprovados", "Aprovado pelo PO", "Testes funcionais aprovados."

  • Nível 2: DoD de sprint/funcionalidade (nível de integração)

    • Foco: Como a funcionalidade interage com o restante do app.

    • Exemplo: "Sem bugs de regressão", "Métricas de desempenho estáveis", "Ambiente de staging atualizado."

  • Nível 3: DoD de release (nível de mercado)

    • Foco: Conformidade legal, de marketing e de segurança.

    • Exemplo: "Teste de penetração de segurança aprovado", "Tradução concluída", "Manual do usuário atualizado."

Componentes principais de um template de Definition of Done

Um DoD de alto desempenho exige estas cinco categorias principais:

  • Padrões de desenvolvimento: Código comentado, refatorado e integrado ao branch principal.

  • Testes e qualidade: Testes unitários, de integração e manuais "smoke tests" concluídos e aprovados.

  • Ambiente e DevOps: Código implantado em um ambiente de staging e passa pelo pipeline de build.

  • Revisão e aprovação: Revisão por pares concluída e o Product Owner (PO) aprovou a funcionalidade.

  • Requisitos não funcionais: A funcionalidade atende a metas específicas de desempenho, acessibilidade e segurança.