Definition of Done: Simples e ainda assim complexo

A Definition of Done (DoD) é uma ferramenta ágil importante que ajuda as equipes a planejar e executar seu trabalho. Basicamente, a Definition of Done é apenas um conjunto de critérios que o produto precisa atender para ser considerado pronto. Mas, embora o conceito seja simples, colocá-lo em prática não é tão fácil assim. O contexto e as possibilidades de interpretação criam uma zona cinzenta.

Contexto e critérios de aceitação

O primeiro nível de complexidade consiste no fato de que a Definition of Done deve sempre ser vista no contexto do ambiente, o que se refere à completude técnica e funcional e à aceitação pelo Product Owner . O fato de o Product Owner aceitar o produto representa o valor do produto. Critérios de aceitação – ou como quer que sejam chamados – refletem se o código consegue resolver um determinado problema de negócio que foi definido pela User Story ou por um requisito. Critérios de aceitação devem confirmar que a story realmente faz aquilo para o que foi pensada, e podem ser usados para a criação de testes de aceitação.

Do ponto de vista formal, a Definition of Done é frequentemente um reflexo dos padrões técnicos e de processos de uma organização. Por exemplo, organizações costumam ter padrões para escrever código e testes unitários, e por isso a Definition of Done pode conter requisitos para a estrutura do código, documentação e testes. Ela também pode incluir componentes relacionados à funcionalidade. No entanto, a funcionalidade está fundamentalmente incluída na definição através dos critérios de aceitação etc. Em alguns casos, já vi declarações na Definition of Done indicando que os critérios de aceitação devem ser cumpridos. Depois de superar a dupla barreira da Definition of Done e dos critérios de aceitação, o Product Owner deve fazer a avaliação do valor entregue pela solução. Em seguida, ocorre a avaliação final, na qual ele aceita ou rejeita a solução. O resultado desse processo também é descrito como done-done ou até done-done-done.

Obstáculos e perguntas importantes sobre a DoD

Para implementar o conceito de "Done" de forma sólida, é preciso superar três obstáculos: os critérios da Definition of Done, os critérios de aceitação (como parte de uma User Story) e a aceitação pelo Product Owner. Além disso, é necessário ponderar algumas questões que tornam o processo, de outra forma relativamente simples, um pouco mais difícil. Entre elas estão:

1. Quem decide o que significa Done?
   Em muitas organizações, os critérios de Done são frequentemente deixados a cargo das equipes individuais. Isso normalmente acontece dentro dos limites dos padrões técnicos e de processo definidos pela organização. Há alguns anos, por exemplo, fui questionado por uma equipe de desenvolvimento com padrões rigorosos de codificação e testes unitários se poderiam dispensar os requisitos de testes unitários para seu código. Testes unitários eram um critério na Definition of Done deles. A justificativa era que os testadores descobririam mais tarde no processo se funcionava, e que o Product Owner não gostava dos testes dos programadores. No entanto, a equipe precisava seguir os padrões estabelecidos pela organização, e simplesmente dispensar os requisitos de testes unitários não estava em discussão.

2. É aceitável quando os critérios não são totalmente atendidos?
   Toda equipe com a qual já trabalhei se perguntou, mais cedo ou mais tarde, se seria aceitável interpretar a Definition of Done de forma diferente e assim contorná-la. Muitas vezes a resposta é "Sim". Porém, isso geralmente significa uma discussão sobre a zona cinzenta, a aceitação de dívida técnica e quando essa dívida deve ser paga.

3. As necessidades da organização podem ser mais importantes que as do Product Owner?
   Este é o alter ego da pergunta anterior. Todos na equipe, incluindo o Product Owner, precisam saber quando e onde os padrões e/ou necessidades da organização são mais importantes que a aceitação pelo Product Owner. A pressão para entregar pode levar equipes e Product Owners a avançar com o código para refatorá-lo em Sprints posteriores, levando os padrões e a arquitetura ao limite. A maioria das organizações mais maduras estabelece limites claros, para que todos saibam quando as necessidades e padrões da organização devem ser respeitados.

Conclusão sobre a Definição de Pronto (DoD)

Todas as definições da palavra "Pronto" incluem um certo grau de finalidade e completude. No desenvolvimento, melhoria e manutenção de software, o conceito de Pronto pode ser muito complexo. Cada uma dessas camadas pode ter suas próprias nuances técnicas, funcionais e relacionadas a valor. As equipes aprendem rapidamente que um trabalho precisa estar realmente pronto, pronto e pronto para estar de fato finalizado.

Este texto é do blog do SPaMCAST e foi traduzido por nós para o alemão.