Qual a diferença entre critérios de aceitação e Definição de Pronto (Definition of Done)?

Para quem já teve seu contato com criação de produtos já esbarrou pelo menos uma vez no problema do: “está pronto, só falta…”. Esse “só falta” consumirá os próximos 3 meses de trabalho do time. Para evitar esse problema, o Scrum recomenda o uso de dois artefatos: Critérios de Aceitação e Definição de Pronto (do inglês Definition of Done, sigla DoD). Todavia há uma confusão quanto ao uso do termo que vamos explicar neste artigo.

Critério de Aceitação

Como o próprio nome diz, é uma lista de combinados que descrevem os critérios se um item do backlog, comumente escrito no formato de história de usuário (User Story), será aceito pelo cliente. Cada item tem o seu. Eles podem estar no formato de lista. Por exemplo, um serviço de empréstimo financeiro para pessoas físicas.

  • Clientes devem ter mais de 18 anos
  • Não autorizar empréstimos superiores a $10.000 se o Score do cliente for inferior a 70.
  • Empréstimos acima de $1.000.000 não são auto aprovados

Outro item, outros critérios.

É comum que os critérios de aceitação sejam escritos no formato que se popularizou com o Behavior Driven Development (BDD), em português: Desenvolvimento Dirigido ao Comportamento.

Contexto do item

Começa com um contexto que é uma descrição sucinta da necessidade. Por exemplo, uma história de usuário que segue o modelo:

Eu, enquanto <Persona>,
Desejo <Necessidade>
Para que <Propósito>

Exemplo 

Eu, enquanto Avelino Paizão,
Desejo tomar um empréstimo financeiro
Para que eu possa adquirir um apartamento para minha família.

Outro formato que se popularizou com o framework: Job to be Done (Trabalho a ser feito) de Clayton Christense foi:

Enquanto <papel>
Eu desejo <necessidade>
Para que <resultado>

Utilizando no mesmo exemplo seria:

Enquanto Cliente do Banco 
Eu desejo um empréstimo financeiro
Para que possa comprar um apartamento.

Esses modelos de contexto não são obrigatórios, poderia ser um texto livre. Ainda no mesmo exemplo: Cliente deseja tomar um empréstimo para adquirir imóvel.

Cenário 

Os cenários são possíveis situações que podem acontecer com uma pessoa ao utilizar o produto, serviço ou funcionalidade que estamos construindo. Vamos permanecer no exemplo do empréstimo. Possíveis cenários poderiam ser

  • Cliente não possui renda para o valor que solicitou
  • Cliente possui um Score Serasa abaixo de 70
  • Cliente menor de 18 anos não pode solicitar empréstimo
  • Cliente deseja tomar empréstimo acima de $ 1.000.000
  • Cliente está apto a tomar o empréstimo em valor inferior a $1.000.000

Agora, podemos utilizar o formato sugerido no BDD para cada cenário.

O formato é

Dado que <estado inicial>
E <caso haja necessidade de mais informações>
Quando <Evento>
Então <resultado>
E <caso haja necessidade de mais informações sobre o resultado>

Agora podemos dar um exemplo completo de critérios de aceitação utilizando BDD para o item que estamos tratando até o momento.

Título: Empréstimo para pessoa física

ID: 123

Contexto:

Eu, enquanto Avelino Paizão,
Desejo tomar um empréstimo financeiro
Para que eu possa adquirir um apartamento para minha família.

Critérios de Aceitação:

Cenário 1: Cliente não possui renda para o valor que solicitou

Dado que o cliente com renda conhecida
Quando ele solicitar um empréstimo que ultrapasse sua renda anual em 30 vezes
Então será informado que o empréstimo foi negado.

Cenário 2: Cliente possui um Score Serasa abaixo de 70

Dado que o cliente possui um Score 69
Quando ele solicitar um empréstimo
Então será informado que o empréstimo foi negado.

Cenário 3: Cliente menor de 18 anos não pode solicitar empréstimo

Dado que o cliente possui 17 anos
Quando ele solicitar um empréstimo 
Então será informado que o empréstimo foi negado.

Cenário 4: Cliente deseja tomar empréstimo acima de $ 1.000.000

Dado que o cliente possui renda compatível com o empréstimo
Quando ele solicitar um empréstimo no valor de $1.000.000,01
Então o gerente da conta será avisado da solicitação E o cliente será avisado de que o empréstimo está aguardando a avaliação do gerente.

Cenário 5: Cliente está apto a tomar o empréstimo em valor inferior a $1.000.000

Dado que o cliente possui renda compatível com o empréstimo
Quando ele solicitar um empréstimo no valor de $999.999,99
Então o dinheiro é depositado em sua conta.

Se houver um item, história para empréstimo de pessoas físicas, então teremos outra história, critérios e cenários.

Definição de Pronto (Definition of Done)

A Definição de Pronto são critérios de qualidade que servem para todos os itens que serão entregues pelo time. Uma espécie de Lista de Verificação (checklist).

Continuamos imaginando que estamos no time que desenvolve soluções de empréstimo financeiro e que temos vários itens que nós construiremos: empréstimo para pessoa física; empréstimo para pessoa jurídica, cobrança de parcela de dívida, cálculo de atrasados etc. Cada um desses itens tem os seus critérios de aceitação. Porém todos, antes de serem entregues, devem passar pela única Definição de Pronto. Ela poderia ser:

  • Por causa da alteração que estamos fazendo, o manual de serviços deve ser atualizado.
  • Novos contratos devem referenciar as alterações realizadas.
  • Emitir avisos pertinentes para os clientes impactados
  • Aguardar o prazo estabelecido pela legislação local

Em um time de desenvolvimento de software poderia ser:

  • O código-fonte está disponível no sistema de Controle de Versões
  • O cliente homologou a entrega
  • A entrega teve zero falhas de testes automatizados
  • A cobertura de teste nas classes de negócio é igual ou superior a 90%.
  • Os testes de vulnerabilidades identificaram zero falhas de nível crítico ou alto.

Não importa qual item seja. Todos são avaliados de acordo com a mesma Definição de Pronto.

Conclusão 

Critérios de Aceitação são individuais e estão relacionados com o funcionamento do produto ou serviço. O ponto de vista é do consumidor do produto ou serviço, ou, se preferir, Qualidade Externa, percebida pelo cliente. A Definição de Pronto é coletiva. Uma para todos os itens. O ponto de vista é do time que desenvolve. Se preferir, a Qualidade Interna do produto ou serviço.

Quer ver isso na prática, veja os nossos treinamentos para aprender mais sobre o tema

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Um pouco do que foi o evento Product to Rescue em 9 de Julho 2024   Foco no problema Manter o foco no problema pode ser Old School mas ainda está em alta. Ficamos muito presos em problemas inexistentes ou…

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…