Como Escrever Excelentes Critérios de Aceitação (Com Exemplos)

Quantas vezes já viu programadores e testadores discutirem sobre a forma como determinada funcionalidade deveria funcionar? E quanto às expressões de confusão dos programadores que não tinham a certeza de como criar a funcionalidade que tinha solicitado? Ambos são problemas bastante comuns no mundo do software e, felizmente, tem uma ferramenta poderosa no seu arsenal para os resolver — os critérios de aceitação.

Neste guia, vou explicar detalhadamente a natureza deste formato de registo de requisitos, explicar o seu papel na gestão de produto e mostrar-lhe como escrever excelentes critérios de aceitação.

Índice

O que são os critérios de aceitação?

Qual é o objetivo de escrever critérios de aceitação?

Como devem ser critérios de aceitação bem escritos?

Formatos comuns de critérios de aceitação

O que são os critérios de aceitação
(e onde se enquadram no Ágil/Scrum?)

Na metodologia ágil, um critério de aceitação é a menor unidade de um requisito funcional ou de conceção que os gestores de produto que seguem a metodologia ágil (ou analistas de negócio) adicionam às suas histórias para comunicar claramente os diferentes estados e comportamentos das funcionalidades que a equipa está a planear criar.

Em termos técnicos, pode utilizar critérios de aceitação onde quiser. No entanto, tradicionalmente, fazem parte das histórias de utilizador, que são componentes dos épicos ágeis.

Para compreender melhor os critérios de aceitação, vamos primeiro relembrar e analisar os elementos desta hierarquia, bem como perceber para que serve cada um deles.

Épicos

Os épicos são tarefas que contêm requisitos funcionais e não funcionais de alto nível relativos a uma funcionalidade de grandes dimensões ou a um grupo de funcionalidades relacionadas entre si. Normalmente, um épico abrange um caso de utilização completo para os seus clientes e contém todas as funcionalidades e capacidades subjacentes que precisa de implementar para abranger o referido caso de utilização.

Imagine que fazia parte da equipa de produto do Spotify e queria expandir a utilização da aplicação adicionando um novo caso de utilização para as pessoas que estão em movimento e não têm acesso à Internet.

Para abranger este caso de utilização, pode considerar adicionar uma nova funcionalidade de grandes dimensões denominada “modo sem ligação do Spotify”, que pode tornar-se num épico na sua lista de pendências do produto, contendo todos os requisitos gerais para permitir que os utilizadores ouçam música sem ligação à rede, bem como várias histórias de utilizador com os requisitos para partes específicas desta funcionalidade.

Histórias de utilizador

As histórias de utilizador são mais pequenas e representam uma parte única e distinta da funcionalidade dentro do épico. São unidades de trabalho de dimensão reduzida que a equipa ágil pode comprometer-se a entregar durante uma única iteração.

Uma das principais características de uma história de utilizador é o facto de a funcionalidade que representa dever ser completa e potencialmente utilizável.

Por exemplo, se estiver a criar uma aplicação de armazenamento de ficheiros em linha e quiser permitir que os seus utilizadores alterem o nome dos ficheiros que carregaram, terá de trabalhar na camada de apresentação (a interface de utilizador e a experiência de alteração do nome) e no lado do servidor (o armazenamento do novo nome).

Para que a funcionalidade esteja completa e seja utilizável, terá de concluir ambas as tarefas e ligar entre si as partes da camada de apresentação e do lado do servidor. A sua equipa faria tudo isto no âmbito de uma única história de utilizador.

Se realizasse apenas o trabalho do lado do servidor, a tarefa correspondente não seria uma história adequada, pois conteria um resultado que não estaria completo nem seria utilizável.

Para dar a conhecer à equipa de desenvolvimento o aspeto que a funcionalidade terá e a forma como deverá comportar-se, os responsáveis pelo produto escrevem critérios de aceitação para essa história.

Critérios de aceitação da história de utilizador

Por fim, temos os elementos mais pequenos da hierarquia dos requisitos de produtos de software — os critérios de aceitação. Representam cenários individuais de utilização dessa funcionalidade ou partes de informação que a equipa de engenharia considerará importantes ao implementar a história.

No exemplo acima, um critério de aceitação seria abrir um campo de texto com o nome do ficheiro já preenchido se o utilizador clicar no botão ✏️Mudar o nome do ficheiro que carregou.

Definição de concluído (sim, é diferente dos critérios de aceitação!)

Por vezes, os responsáveis pelo produto (especialmente os que são relativamente novos nesta função de Scrum) confundem a definição de concluído com os critérios de aceitação.

Sinceramente, também foi bastante confuso para mim no início, porque ambos são “critérios para verificar se a funcionalidade está concluída.”

A única diferença é que a definição de concluído representa a conclusão em termos dos processos de desenvolvimento da equipa.

Enquanto os critérios de aceitação representam os requisitos funcionais (o aspeto e o comportamento que a funcionalidade deve ter).

Isto significa que a definição de concluído permanecerá igual para todas as histórias que a equipa está a implementar, a menos que decidam alterá-la durante as retrospetivas. Os critérios de aceitação, por outro lado, são únicos para cada história, uma vez que explicam a forma como essa funcionalidade deve funcionar.

Nota: Algumas ferramentas de gestão de produtos permitem-lhe ter tanto a definição de concluído como os critérios de aceitação nas suas histórias.

Agora que relembrámos em que consistem os épicos e as histórias, e de que forma os critérios de aceitação se relacionam com eles, avancemos para compreender por que razão os gestores de produto escrevem critérios de aceitação.

Qual é o objetivo de escrever critérios de aceitação?

Posso simplesmente escrever uma descrição de uma história de utilizador da forma que quiser, sem incluir quaisquer critérios de aceitação? Qual é, afinal, a vantagem de escrever critérios de aceitação?

Claro que pode escrever as suas histórias da forma que quiser. No entanto, recomendo que utilize os critérios de aceitação como forma de formular os seus requisitos, uma vez que este formato oferece uma grande variedade de vantagens. Eis algumas que deve considerar.

Incentivam o pensamento orientado pelo comportamento

Se optar pelo formato BDD para os critérios de aceitação (falaremos mais sobre isso adiante), então os seus critérios de aceitação descreverão o percurso dos seus clientes quando utilizam a funcionalidade em questão.

A beleza desta abordagem é que deixa de pensar em requisitos técnicos áridos e começa a analisar a funcionalidade do ponto de vista do utilizador. Desta forma, consegue visualizar aquilo que este experiencia e sente ao interagir com a sua funcionalidade.

É muito comum o gestor de produto perceber que a funcionalidade que idealizou não é a melhor quando a observa do ponto de vista dos seus utilizadores.

Também passei por isso em várias ocasiões. Por exemplo, quando estava a criar requisitos para um editor de fórmulas matemáticas (que fazia parte de um produto SaaS de análise financeira que estávamos a desenvolver na altura), queria que o processo de edição tivesse o seguinte aspeto:

• Um botão de edição junto à fórmula.
• Clicar no botão de edição tornaria o campo da fórmula editável e apresentaria os botões ✅ Guardar e ❎ Cancelar .
• Clicar em qualquer um deles sairia do modo de edição e faria aparecer a nova versão guardada ou a versão antiga da fórmula, consoante a seleção do utilizador.

Este comportamento parece lógico, certo?

Bem, não até começar a escrever cenários de analistas a utilizá-lo e descobrir uma falha significativa de usabilidade. Normalmente, os analistas fazem pequenas alterações à fórmula e observam o resultado do cálculo até obterem a fórmula que pretendem.

A forma como tinha imaginado o funcionamento da edição seria extremamente incómoda para os meus utilizadores-alvo, pois teriam de entrar e sair do modo de edição 20-30 vezes seguidas. Por isso, assim que percebi o erro, alterei rapidamente os critérios de aceitação e solicitei a criação de um editor de fórmulas no qual fosse possível fazer alterações em tempo real.

Ajudam a criar uma fonte única de verdade

Enquanto gestor de produto “novato”, a minha maior dificuldade era comunicar os requisitos do produto a pessoas de diferentes profissões ou até de diferentes equipas. O problema era que cada uma delas interpretava os requisitos de forma diferente e a comunicação entre elas se tornava uma confusão pouco clara.

Foi então que um gestor de produto experiente sugeriu que aplicasse o conceito de uma fonte única de verdade, formulando os meus requisitos de produto de forma muito clara (algo em que a IA na recolha de requisitos pode ajudar), comunicando-os a todos e pedindo-lhes que baseassem o seu trabalho apenas no que estivesse escrito nesse documento.

Foi um enorme sucesso, uma vez que todos passaram a ter a mesma compreensão de como a funcionalidade deveria funcionar e, quando surgiam divergências, consultavam novamente o requisito.

Os critérios de aceitação são uma excelente forma de criar uma fonte única de verdade, uma vez que descrevem a funcionalidade de forma clara e fácil de ler e têm um elevado nível de granularidade (como devem ter, pois devem abranger todos os detalhes principais da funcionalidade).

Melhoram a qualidade dos testes de aceitação

Para os engenheiros de software, os critérios de aceitação funcionam como os requisitos do produto que irão seguir ao desenvolver a funcionalidade. Para a sua equipa de qualidade, por outro lado, os critérios de aceitação têm algumas funcionalidades adicionais:

Ajudam a dar prioridade aos casos de teste. Se a sua equipa de testes de software tiver muitos casos de teste para essa funcionalidade e não houver tempo suficiente para os analisar a todos, dará prioridade e executará primeiro os cenários de teste que correspondem aos critérios de aceitação, uma vez que estes descrevem os fluxos de utilizador mais críticos.

Funcionam como uma lista de verificação de aceitação. Este ponto aplica-se tanto às equipas de QA como aos responsáveis pelo produto que precisam de aceitar a funcionalidade. Os critérios de aceitação, tal como o nome indica, funcionam como uma lista de verificação para determinar o estado de aprovação/reprovação da funcionalidade. Se um ou mais critérios de aceitação não forem cumpridos, a equipa de QA reabrirá a história e pedirá à equipa de engenharia que adicione a funcionalidade em falta.

Em suma, os critérios de aceitação são ferramentas indispensáveis nas mãos dos responsáveis pelo produto para comunicar corretamente os requisitos do produto. Mas como se escrevem bons critérios de aceitação? Vou ajudá-lo com isso de seguida.

Qual deve ser o aspeto de critérios de aceitação bem escritos?

A qualidade dos critérios de aceitação que escreve terá um impacto direto na qualidade das funcionalidades que a sua equipa entrega. Com uma compreensão clara do que deve ser desenvolvido e de como o testar, a sua equipa desenvolverá a funcionalidade da forma que imaginou, com o mínimo de problemas.

Para se destacar na escrita de critérios de aceitação, terá de prestar atenção aos seguintes aspetos.

Clareza

O pecado n.º 1 que um responsável pelo produto pode cometer é escrever critérios de aceitação pouco claros e vagos. Pode esquecer a ideia de uma compreensão partilhada quando as pessoas podem interpretar o que escreveu de várias formas.

Para ver exatamente a diferença que isso faz, deixe-me mostrar-lhe um exemplo.

O que entendeu desta frase? Consegue dizer-me como o multibanco utilizará o tipo de cartão para decidir se deve autenticar o utilizador ou não? O multibanco autenticará o utilizador se todos estes critérios forem cumpridos ao mesmo tempo ou basta cumprir apenas um deles?

Se entregar este critério de aceitação aos seus engenheiros, eles irão inundá-lo de perguntas e pedir-lhe-ão que seja mais claro nos seus requisitos. Agora vamos melhorá-lo.

Está muito melhor, não acha? Com este critério de aceitação, também demos as respostas a todas as perguntas acima. O multibanco tem de suportar o tipo de cartão que o utilizador inseriu e os três critérios devem ser cumpridos ao mesmo tempo para que o multibanco proceda à autenticação.

Dica profissional: Torne os seus critérios de aceitação SMART (específicos, mensuráveis, alcançáveis, relevantes e testáveis). Sim, alterei o último para testável, uma vez que é uma característica importante de critérios de aceitação eficazes.

Legibilidade

Para além de evitar a falta de clareza nos seus critérios de aceitação, deve também mantê-los simples e evitar termos sofisticados ou inglês complexo.

Tenho a certeza de que tem uma equipa de superestrelas altamente instruídas, capazes de ler e compreender facilmente as palavras e frases mais sofisticadas e complexas da língua inglesa, mas não quer realmente desperdiçar a sua capacidade cognitiva a descodificar os seus textos.

Por isso, em vez disto.

Diga isto.

Presumo que nem sequer se tenha dado ao trabalho de ler completamente o primeiro critério de aceitação, pois também não queria desperdiçar o seu tempo e a sua capacidade mental!

Cobertura dos casos

O diabo está nos detalhes. Por vezes, apercebemo-nos de que deixámos escapar um caso problemático numa funcionalidade quando já estamos numa fase muito avançada do desenvolvimento e temos de criar uma tarefa de melhoria de acompanhamento ou até refazer tudo.

Parece-lhe familiar, não é?

Quanto mais casos considerar antecipadamente nos seus critérios de aceitação, menor será a probabilidade de se deparar com esse cenário nos itens do seu backlog.

Vejamos agora os critérios de aceitação abaixo.

Vê alguma coisa estranha aqui? À primeira vista, o requisito é claro: adiciona o endereço de e-mail, prime enviar e a pessoa obtém acesso. Na realidade, não considerámos aqui muitos casos:

• Se o endereço de e-mail já estiver na lista de utilizadores que têm acesso ao documento, talvez deva apresentar uma mensagem de erro a informar o utilizador.
• Será enviado um e-mail de convite ao utilizador, por isso talvez valha a pena mostrar, na lista partilhada, se este aceitou ou não o convite.
• Se não tiver aceitado o convite, talvez valha a pena adicionar um botão “reenviar convite”.

Também existem casos negativos, quando esclarece o comportamento da sua funcionalidade perante algo vazio ou quando ocorre um erro.

Utilização ativa de recursos visuais

Os critérios de aceitação que partilhei acima foram totalmente claros para si? Quando falei no campo “Adicionar pessoas e grupos”, percebeu claramente do que se tratava?

Por vezes, as palavras não são suficientes para esclarecer os requisitos à sua equipa e é melhor mostrá-los em vez de falar sobre eles. Agora, deixe-me melhorar um pouco estes critérios de aceitação.

Será correto assumir que teria percebido facilmente aquilo de que estava a falar com estes critérios de aceitação se visse a imagem e os meus comentários lado a lado? Aposto que sim.

Assim, ficam abrangidos os “critérios de aceitação” dos critérios de aceitação — vamos agora abordar os diferentes tipos e formatos que as equipas de produto utilizam para os definir.

Formatos comuns de critérios de aceitação

Tenho de ser franco consigo. Raramente utilizo o mesmo formato em todas as minhas histórias de utilizador. A razão é que diferentes formatos de critérios de aceitação são adequados a diferentes casos de utilização e nem sempre é boa ideia obrigar-se a utilizar sempre o mesmo formato.

Por isso, escolho o formato com base na história e no tipo de informação que quero incluir nos seus critérios de aceitação.

Vejamos agora alguns dos formatos mais comuns e os respetivos exemplos de critérios de aceitação.

Formato BDD

BDD significa Desenvolvimento orientado pelo comportamento e é uma estrutura que incentiva os membros das equipas de desenvolvimento de software e de produto a definirem requisitos com base na forma como os utilizadores finais irão interagir com a funcionalidade.

Enquanto forma de escrever requisitos com base no comportamento do utilizador, os critérios de aceitação para BDD seguem este modelo específico:

Dado: A pré-condição para o cenário específico do comportamento do utilizador.

Quando: A ação realizada pelo utilizador.

Então: O resultado da ação.

Assim, se quisesse explicar como funciona a funcionalidade de levantamento de dinheiro de uma caixa multibanco, os seus critérios de aceitação seriam os seguintes:

O tipo de critérios de aceitação dado/quando/então é excelente quando pretende criar empatia pelas necessidades dos utilizadores dentro da sua equipa, colocando a ênfase na perspetiva do utilizador.

Formato de lista de verificação

Ao contrário do BDD (também conhecido como formato “orientado para cenários”), este formato não apresenta o ponto de vista do utilizador final. Em vez disso, centra-se mais na explicação das regras específicas que a lógica de negócio da funcionalidade deve seguir (a designação alternativa para este formato é “orientado para regras”). Eis o seu aspeto.

Este formato será o mais adequado quando a lógica que pretende explicar é complexa, pois ajuda a dividi-la em várias regras pequenas, mais fáceis de compreender e implementar. 

Formato de fluxo

Este é provavelmente o formato que mais utilizo.

O formato de fluxo é semelhante ao formato BDD, uma vez que também mostra o ponto de vista do utilizador. No entanto, ao contrário do BDD, não impõe uma estrutura rígida (Dado/Quando/Então). Assim, pode narrar os passos que o utilizador executa da forma que quiser.

Eis o aspeto que o processo de registo teria com este formato.

O formato de fluxo será a melhor opção se quiser criar empatia com o utilizador (tal como acontece com o BDD), mas não quiser realmente seguir uma estrutura rígida.

Mantenha todos alinhados com critérios de aceitação

Os critérios de aceitação são ferramentas poderosas nas mãos dos responsáveis pelo produto, permitindo-lhes criar uma fonte única de verdade e manter os colegas de equipa alinhados com a sua visão para essa funcionalidade.

Para obter mais guias como este e outros excelentes recursos para profissionais de produto, subscreva a nossa newsletter!