Qual a diferença entre critérios de aceitação e Definição de Pronto?

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

 

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

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

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Há algum tempo escrevemos o artigo sobre o Cemitério Mexicano. Ele fala sobre a importância de comemorar quando descartamos ideias ruins antes que elas entrem no nosso fluxo de trabalho como projetos, iniciativas, novos produtos ou serviços. Naquele artigo citamos…

Introdução Muitas empresas confundem a Gestão de Objetivos Estratégicos (OKR) com as operações diárias, conhecidas como (BAU), gerando desalinhamento de expectativas, excesso de Objetivos e KRs e iniciativas que na verdade são tarefas do dia a dia. Em parceria com…