Em concursos para a área de TI, especialmente em cargos que exigem conhecimento em gerenciamento de projetos, as metodologias ágeis são um tema recorrente e de alta relevância. Entender a fundo seus conceitos é crucial, pois bancas como a FGV adoram explorar as nuances que diferenciam termos aparentemente similares. A questão que originou esta aula é um exemplo clássico: a distinção entre “Definição de Pronto” (Definition of Ready – DoR) e “Definição de Feito” (Definition of Done – DoD). Embora ambos sejam essenciais para garantir a qualidade e a fluidez do trabalho, eles atuam em momentos completamente distintos do ciclo de vida de uma entrega. Dominar essa diferença não só garantiria o acerto na questão, mas prepara você para um entendimento mais robusto do framework Scrum e de práticas ágeis em geral.
O Alicerce do Sprint: Entendendo o Backlog e as User Stories
Antes de mergulharmos em DoR e DoD, precisamos firmar um conceito central: a História de Usuário (User Story). No universo ágil, uma User Story é uma descrição curta, simples e em linguagem natural de uma funcionalidade sob a perspectiva de quem a deseja. Ela é o “o quê” e o “porquê”, mas não o “como”. Elas geralmente residem no Product Backlog, uma lista priorizada de tudo o que é desejado no produto.
Definition of Ready (DoR): O Portão de Entrada para o Trabalho
A Definição de Pronto (DoR) é um conjunto de critérios que uma História de Usuário deve atender antes de ser considerada pronta para ser selecionada para um Sprint. Pense na DoR como um checklist de qualidade para o planejamento. Ela é a garantia para a equipe de desenvolvimento de que uma história está clara, factível e testável o suficiente para que eles possam se comprometer a entregá-la.
Critérios Comuns em uma DoR:
- Clareza: A história de usuário está bem escrita e compreendida por toda a equipe.
- Critérios de Aceitação Definidos: As condições que a funcionalidade deve satisfazer para ser aceita pelo Product Owner estão claras.
- Dependências Identificadas: Quaisquer dependências de outras equipes ou tarefas foram mapeadas.
- Estimativa Realizada: A equipe fez uma estimativa do esforço necessário para completar a história.
- Valor de Negócio: O propósito da história e seu valor para o cliente estão claros.
Em resumo, a DoR atua no “início” do processo, garantindo que apenas trabalho bem preparado entre no fluxo de desenvolvimento.
Definition of Done (DoD): O Portão de Saída para a Entrega de Valor
A Definição de Feito (DoD), por outro lado, é um acordo compartilhado pela equipe sobre o que significa o trabalho estar completo. É uma lista de critérios que uma História de Usuário deve atender ao final do desenvolvimento para ser considerada concluída e potencialmente entregável. A DoD é o selo de qualidade da equipe.
Critérios Comuns em uma DoD:
- Código Completo e Revisado: O código foi escrito, segue os padrões de qualidade e foi revisado por pares (peer review).
- Testes Unitários e de Integração Aprovados: Todos os testes automatizados relevantes foram criados e estão passando.
- Testes de Aceitação Realizados: A funcionalidade foi validada em relação aos critérios de aceitação.
- Documentação Atualizada: A documentação técnica e de usuário necessária foi criada ou atualizada.
- Funcionalidade Integrada: O código foi integrado à base principal do produto (main branch) sem quebrar a build.
A DoD garante que, ao final do Sprint, a equipe entregue um incremento de produto que seja de alta qualidade e potencialmente utilizável. Ela atua no “fim” do processo.
Análise das Alternativas da Questão Original
Vamos dissecar a questão que nos trouxe aqui para solidificar o conhecimento:
- Alternativa A e B (Incorretas): Usam termos genéricos como “tarefa” e “recurso”. Embora DoR/DoD possam ser adaptados, a unidade padrão no Scrum para planejamento de Sprint é a “história de usuário”. A alternativa “E” é mais precisa.
- Alternativa C (Incorreta): Afirma que a DoR define “critérios de aceitação para uma tarefa”. Isso é uma confusão. A DoR verifica se os critérios de aceitação já foram definidos, mas não os define em si. Além disso, confunde DoD com “critérios de aceitação para uma história de usuário”, o que, como vimos, são coisas diferentes.
- Alternativa D (Incorreta): Comete um erro grave ao associar a DoD a “critérios de aceitação para um lançamento”. A DoD se aplica a cada incremento do produto (cada história ou item de backlog), não ao lançamento inteiro, que é um evento muito mais amplo.
- Alternativa E (Correta): Captura perfeitamente a essência. A DoR define quando uma história de usuário pode ser trabalhada (entrar no Sprint), e a DoD define quando ela é concluída (atingiu o padrão de qualidade da equipe).
Conclusão
Compreender a diferença entre Definition of Ready e Definition of Done é fundamental para qualquer profissional que atue com métodos ágeis. A DoR é um filtro de entrada, garantindo que a equipe trabalhe em itens bem definidos e evitando desperdício. A DoD é um selo de qualidade de saída, garantindo que o que é entregue agrega valor real e não gera débito técnico. Para sua prova, lembre-se sempre: DoR é sobre estar PRONTO para começar, DoD é sobre estar FEITO de verdade.
Mapa da Aprovação: Resumo Esquematizado
| Critério de Análise | Definition of Ready (DoR) – “Pronto para Começar” | Definition of Done (DoD) – “Realmente Feito” |
|---|---|---|
| Propósito Principal | Garantir que uma história de usuário está madura e clara o suficiente para ser incluída em um Sprint. | Garantir que um incremento do produto atende a um padrão de qualidade consistente e está potencialmente entregável. |
| Quando é Aplicado? | Antes do Sprint Planning (durante o refinamento do backlog). | Ao final do desenvolvimento de uma história, antes de considerá-la concluída no Sprint. |
| Foco | Na preparação e clareza dos requisitos (input). Foco no futuro. | Na qualidade e completude do trabalho realizado (output). Foco no presente/passado. |
| Quem se Beneficia Principalmente? | A Equipe de Desenvolvimento, que recebe trabalho claro e sem ambiguidades. | O Product Owner e os Stakeholders, que recebem um incremento de produto de alta qualidade. |
| Exemplo de Item do Checklist | “Critérios de aceitação estão escritos e foram revisados pelo Product Owner.” | “Código foi revisado por outro desenvolvedor (peer review).” |
| Analogia | Receita de bolo revisada: Verificar se todos os ingredientes estão listados e as instruções estão claras antes de começar a cozinhar. | Bolo pronto para servir: Verificar se o bolo assou, esfriou, foi confeitado e passou no “teste do palito” antes de servir aos convidados. |
| Status no Scrum Guide | Não é uma prática oficial do Scrum, mas uma prática complementar comum. | É um artefato mandatório e parte formal do framework Scrum. |
Teste Seus Conhecimentos: Questões de Fixação
Referências
- Definition of Done vs Definition of Ready: Key Milestones in Agile Project Execution
- Definition of Done(DoD) vs Definition of Ready(DoR) – GeeksforGeeks
- Definition of Done vs Definition of Ready: Key Differences – Dee Project Manager
- What Is the Difference Between the Definition of Done (DoD) and the Definition of Ready (DoR)? | Scrum.org
- Understanding the Workflow: Definition of Done vs. Definition of Ready – Medium
