Nesse mundo da agilidade temos algumas confusões com as nomenclaturas de alguns artefatos. DoD, DoR, DoT, Critérios de Aceitação. Nós gostaríamos de trazer neste artigo algumas definições importantes para ajudar o seu time.
Neste artigo
Definition of Ready(DoR) – Definição de Preparado
Esse é um artefato comum para muitos times que utilizam o Scrum, porém não é apresentado no Guia do Scrum. Ele é um item único para todos os itens de trabalho. Funciona como uma checklist criada pelo Time Scrum. Ele avalia o item para verificar se ele pode ou não entrar na etapa de construção de incrementos na Sprint.
Exemplo:
- A demanda está escrita no formato de História de Usuário
- O tamanho estimado da demanda é de no máximo 20 pontos de história
- Há orçamento disponível para a execução da demanda
- Os recursos de acesso aos dados foram concedidos para os desenvolvedores
Definition of Done (DoD) – Definição de Pronto
Esse é um artefato Scrum e no Guia do Scrum é definido como: “uma descrição formal do estado do Incremento quando ela atende às medidas de qualidade exigidas para o produto.
No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce”
Ken Schwaber e Jeff Sutherland, O Guia do Scrum 2020, p.13.
Assim como a Definição de Preparado, o DoD funciona como uma checklist que avalia se os itens de trabalho entregues pelo Time Scrum estão realmente prontos. O objetivo é evitar o famoso: Está pronto, só falta testar!
Algumas empresas ou unidades da organização estabeleçam um DoD único para garantir a qualidade do item que está sendo entregue. Nesse caso, os times devem respeitar esse DoD e podem acrescentar itens que acharem pertinentes.
Exemplo:
- Os testes automatizados não apresentaram erros
- A cobertura de testes em funcionalidades críticas é de 100%
- O item está disponível para uso do cliente
- A documentação do incremento está guardada no repositório
- O gerente da área foi avisado sobre a liberação do incremento
Definition of Transition (DoT) – Definição de Transição
Uma das práticas do Kanban é tornar as políticas explícitas. Como ele não necessariamente tem uma Sprint, como podemos garantir que estamos entregando um produto com a qualidade desejada? Através da Definição da Transição. Ela é um checklist que está em cada transição de etapa. Veja o quadro abaixo
Um exemplo de DoT de Detalhamento para refinamento poderia ser: A demanda está escrita no formato de História de Usuário. De refinamento para orçamentação: O tamanho estimado da demanda é de no máximo 20 pontos de história. De Testes e Qualidade para Disponibilização:
- Os testes automatizados não apresentaram erros
- A cobertura de testes em funcionalidades críticas é de 100%
- A documentação do incremento está guardada no repositório
Perceba que o DoT funciona como se eu pegasse o DoR e o DoD e diluísse nas diversas etapas do meu fluxo de valor.
Critérios de Aceitação
Os critérios de aceitação são diferentes. Eles são únicos para cada item de trabalho que estamos criando. A responsabilidade de criação dele, assim como todos os outros combinados, é do Time Scrum. Muitas vezes vemos essa atividade “delargada” para o Product Owner ou para o Testador / Quality Assurance (QA) do time. Essa não era a intenção de Mike Cohn quando escreveu sobre o tema em User Story Applied. O objetivo é criar de forma colaborativa um combinado entre desenvolvedores, testadores e Product Owner que garanta que todos compreendam se espera quando o item de trabalho for concluído.
Imagine a seguinte história de usuário: Eu, enquanto Bernardo Bibliotecário, desejo cadastrar um novo livro na biblioteca, para poder disponibilizá-lo para empréstimo.
A princípio parece algo trivial. Entretanto, o que acontece caso o livro já exista, cadastra mais um exemplar ou dá uma mensagem de erro? O que acontece se o bibliotecário informar dois títulos iguais com ISBN diferentes? O autor deve estar cadastrado previamente ou pode cadastrar na hora? Essas perguntas podem ser respondidas justamente através dos critérios de aceitação, dessa forma não ficará nada subentendido e as expectativas serão explicitadas.
Não existe uma única forma de escrever critérios de aceitação, mas uma bem popular é o Desenvolvimento Guiado por Comportamento, mais conhecido pelo nome inglês Behavior-driven development (BDD) proposto por Dan North. O formato é bem simples. Cada item de trabalho (história de usuário) pode ter diversos cenários. Leve em consideração apenas cenários relevantes para o negócio. Coisas do tipo testar se 31 de fevereiro é uma data válida, verificar se o nome possui mais de 2 letras, embora importantíssimos, não farão parte dos critérios de aceitação para não ficar algo muito extenso e cansativo. O formato é:
Cenário: <O que desejamos avaliar>
Dado <condições necessárias para que possamos realizar a ação>
Quando <evento que dispara a ação>
Então <resultado esperado da ação>
Um exemplo:
Cenário: Cadastrar o mesmo livro duas vezes
Dado que já há um livro com o ISBN 979884700493-0 cadastrado
Quando o bibliotecário cadastrar outro livro com o mesmo ISBN
Então o sistema informará que esse livro já está cadastrado.
Há inclusive ferramentas que automatizam os testes com BDD como Cucumber e Specflow caso você queira e tenha conhecimento para tal.
Quem é o responsável?
O responsável por todos esses artefatos é o time. Todos são acordos e como qualquer acordo, a colaboração é essencial. De todos esses, a maior confusão acontece com os critérios de aceitação. Muitos acham que o Product Owner é o único responsável por criá-los. Isso não é verdade. Mesmo porque quem desenvolve acaba percebendo critérios que alguém com foco no negócio não percebe. O contrário também é verdade. Por isso é necessário uma discussão em conjunto para uma boa construção desses critérios.
Quer saber mais sobre isso, veja o nosso treinamento de Certified Scrum Product Owner® (CSPO).
