Critério de aceite e definição de pronto, não é tudo a mesma coisa??
Não! Ainda que os nomes sejam semelhantes, o critério de aceite (acceptance criteria) e a definição de pronto (definition of done) possuem conceitos diferentes.
Para explicá-los, hoje quem assume a autoria do nosso Blog é o André Andrade, Analista de Projetos (PO) aqui na nata.house.
Vem conferir!
No geral, a definição de pronto é comum a todo o projeto (esta se torna intrínseca para todas as tarefas) e são definidas no início de um projeto. Já os critérios de aceitação são específicos a cada história de usuário, sendo este definido, normalmente, em uma planning – podendo ser definido antes e estar no backlog. Mas é na planning onde todos alinham esses critérios de aceite.
Desse modo, todas as tarefas precisam atender as definições de pronto (quando se aplicarem) e cada tarefa específica deve atender os seus critérios de aceite específicos.
Exemplos de definição de pronto:
- 80% de cobertura de testes em todo o projeto;
- 100% de code smells;
- SSDs(documentação de cada incremento) a cada 3 meses;
- A transição de uma página para outra não levar mais do que 1s;
- CI/CD build aceito para subir;
- Code Review em todas as tarefas.
Benefícios da DOD (Definition of done):
- Alinhamento de expectativas no início do projeto;
- Clareza no que é esperado;
- Assegura padrões de qualidade.
Exemplo de Critérios de Aceite:
- A rota X retorna o balance do usuário;
- Ao clicar imprimir recibo um recibo é impresso;
- Ao efetuar uma transação os dados são salvos no banco.
Benefícios Critérios de Aceite:
- Entendimento do time sobre o que é esperado de uma tarefa;
- Evita retrabalho;
- Facilita nos testes do desenvolvedor e do QA;
- Foco.
Como introduzir na cultura
Conforme dito acima, geralmente, o PO define as Definições de Pronto com o cliente no início de um projeto, para ter um alinhamento de expectativas e as deixam transparentes para todos os membros do time. Ademais, as definições de pronto podem ser revistas regularmente para mantê-las relevantes e atualizadas.
Já em relação aos critérios de aceite, o PO deve defini-los na construção das suas histórias de usuário e fazer o time entendê-los nas plannings.
Uma boa prática para assegurar que cada tarefa tenha um critério de aceite, é a inserção de um campo específico para isso no seu gerenciador de tarefas, no meu caso o Jira, como mostra o exemplo abaixo:
Exemplo de campo de critério de aceite no Jira.
Como checar se ambos estão sendo seguidos pelo time?
Todo o time tem a responsabilidade de realizar as definições de pronto, como um acordo de cavalheiros. Em relação aos critérios de aceite, o PO só considera e aceita uma tarefa como finalizada se todos os critérios de aceite foram contemplados.
Conclusão
Ambos são opções poderosas para assegurar que você está entregando valor para o seu cliente. Não importa o nome dado, entregar VALOR é sempre o nosso foco.
Inspiração: Age of product; Boost
