Introdução
Muitas pessoas que estão começando sua jornada como Scrum Master ou estão dentro de Scrum Teams, possuem dificuldade para entender o que é o Definition of Done (DoD), e a sua verdadeira importância. Na maioria das vezes, acabam confundido com critérios de aceite, ou limitam o compromisso a um simples check list, que após sua criação raramente é revisado pelo time. O desconhecimento sobre o assunto, faz com que essas pessoas tenham dificuldades na hora de realizar a prova e tirar a tão sonhada PSMI. Então resolvi escrever esse artigo para desmistificar o que é a Definition of Done e trazer exemplos da sua aplicação em diferentes situações.
Nesse artigo você vai encontrar:
1. Como contexto, vamos entender o conceito de DONE antes
2. Exemplo de algumas DoD
2.1 Exemplo de DoD para um Produto de Software
2.2 Exemplo de DoD para um Time de Marketing
2.3 Exemplo de DoD para um Time de Transformação Ágil
3. Onde encontramos a DoD segundo o Scrum Guide
4. Quem cria a DoD?
5. Como a DoD é usada em cada Evento Scrum
6. O que não é uma DoD
7. Outros pontos a se considerar
8. Criando uma DoD
1. Como contexto, vamos entender o conceito de DONE antes
Antes de explicar o que é DoD, gostaria de estabelecer o entendimento sobre o que é algo estar "Done", ou Pronto em português, e a importância disso para times que utilizam o Scrum.
Se fossemos resumir o Scrum em poucas palavras, podemos dizer que o "Ponto central do Scrum é criar Incrementos Done (entregas prontas) a cada Sprint". Reflitam bem sobre essa frase, pois ela é o coração do Scrum - é através desse conceito que o Scrum pratica o processo empírico, entregando Incrementos Done de valor a cada Sprint.
Em outras palavras, o Scrum busca maximizar a entrega de valor, através de Incrementos Done (“pedacinhos do produto”), enquanto trata e mitiga os riscos, utilizando ciclos curtos (Sprints) que promovem a inspeção e adaptação, construindo a essência da agilidade e promovendo a capacidade de mudarmos de direção, sempre que necessário.
Então determinar que um item do Sprint Backlog está Done (Pronto), não é simplesmente passar por um checklist e dizer que tudo foi feito - é garantir que aquele item atingiu o nível de qualidade ideal com o ponto desejado para que ele possa ser lançado (publicado) caso faça sentido para o negócio.
Talvez agora você esteja se perguntando, mas como eu garanto que um item atingiu o nível de qualidade ideal para se tornar um incremento do produto? Com a Definition of Done.
2. Exemplo de algumas DoD
Antes de mostrar alguns exemplos, vale lembrar que a DoD é única para um Produto / Time, independente do PBI (Product Backlog Item) que está sendo criado.
DoD é um check list usado pelo time - muitas vezes "colado na parede" para dar uma alta transparência do padrão de qualidade.
2.1 Exemplo de DoD para um Produto de Software
Para um time que desenvolve Software, segue um exemplo de uma DoD (padrão de qualidade para o Incremento)
- Todo código produzido foi revisado por um segundo Desenvolvedor (code review)
- O código foi versionado e disponibilizado (integrado) no branch principal
- Foi feito testes de regressão, para garantir que nada do que já existia foi danificado
- Foi seguido o padrão de estilo (cores e padrões de design) estabelecido pela empresa
- A funcionalidade desenvolvida atende aos padrões de acessibilidade
- Garantir que as políticas de segurança de software foram atendidas
Percebam como, independentemente se estou fazendo uma "tela de login", uma "tela de cadastro", um "carrinho de vendas" ou um "cálculo de imposto", eu consigo validar o check list acima, se meu desenvolvimento levou em consideração todo o padrão de qualidade estabelecido.
2.2 Exemplo de DoD para um Time de Marketing
Agora para um produto de Marketing, segue um exemplo de uma DoD (padrão de qualidade):
- Todo trabalho que possua textos, deve ser revisado por uma segunda pessoa, visando a qualidade da escrita
- Os entregáveis devem seguir o guia da marca
- Todos os critérios de aceite (requisitos) levantados pelo Product Owner devem ser atendidos
- Analisar sempre impactos no orçamento, quando alterar configurações de Ads
2.3 Exemplo de DoD para um Time de Transformação Ágil
Eu Antonio, possuo um time atualmente responsável pela Transformação Ágil de uma empresa. Usamos o Scrum para organizar nosso produto de transformação, e essa é nossa DoD.
- Todo item deve ser apresentado para os demais membros do time analisarem impactos nos seus trabalhos
- Deve possuir uma entrega simplificada em inglês, para demonstração para pessoas da Matriz
- Deve estar salvo em nosso sharepoint/intranet
- Deve ser validado pelo Product Owner, e analisado a necessidade de validação executiva
Levando em consideração esse último exemplo (de time Scrum responsável por uma transformação ágil), veja como esse Scrum Team se beneficia de ter uma DoD bem robusta:
- Fica claro para todos os membros do Scrum Team quando um item está Done
- Esse padrão reflete nossa qualidade como time
- Quando alguém fala que está Done, eu como Product Owner sei que posso publicar (lançar) o item, caso eu queira
- O time cria seu Sprint Backlog mais apurado, pois sabe o padrão de qualidade para colocar um item para Done
3. Onde encontramos a DoD segundo o Scrum Guide
Seguem alguns pontos do Scrum Guide onde a DoD é citada e pode ajudar no nosso entendimento.
Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco em relação ao qual o progresso pode ser medido:
- Para o Incremento é a Definição de Pronto.
O Scrum possui 3 artefatos - Product Backlog, Sprint Backlog e Incremento, e cada um deles possui um Compromisso. A DoD é um Compromisso ligado ao Incremento. Conseguimos saber se o trabalho que os Developers fizeram, pode ser considerado parte do Incremento, se atingiu a DoD, que é o compromisso do Incremento.
A Definição de Pronto é uma descrição formal do estado do Incremento quando atende às medidas de qualidade exigidas para o produto.
No momento em que um item do Product Backlog atende à Definição de Pronto, nasce um Incremento.
A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado de qual trabalho foi concluído como parte do Incremento
Com uma DoD corretamente criada, conseguimos atingir 3 objetivos super importantes para o Scrum.:
- Criar o mesmo entendimento entre todos, sobre o que é Done (Pronto): Quantas vezes, ainda mais no mundo de Software, algum Developer fala assim: "Está pronto o sistema, só falta testar", ou "Está pronto sim, na minha máquina funciona!". Oras, está pronto (Done) ou não, só falta testar? Com uma DoD criamos um entendimento comum de quando está pronto realmente.
- Saber se o Incremento está Done Seguindo nosso padrão de qualidade: Por exemplo, um time pode definir que um produto não pode ser lançado, se tiver erros de português. Então "verificar se todos os textos estão escritos corretamente" é um item da nossa DoD. Logo, quando alguém falar que um Item está Done, todos vão saber que o padrão de qualidade foi atingido para aquele item.
- Auxilia o time no planejamento do Sprint, em como eles vão criar o plano de trabalho para criação do Incremento: No exemplo acima, onde o padrão de qualidade leva em consideração se o Incremento não possui erros de português, se isso é um padrão de qualidade do Produto, o time deve saber disso desde o Planejamento do Sprint, pois assim, eles poderão planejar tarefas para garantir esse nível de qualidade. Quanto mais robusta e completa for a DoD, mais o planejamento do Sprint vai ser influenciado.
4. Quem cria a DoD?
Segundo o Scrum Guide, vemos que:
Se a Definição de Pronto para um incremento fizer parte dos padrões da organização, todos os Times Scrum devem segui-la no mínimo. Se não for um padrão organizacional, o Time Scrum deve criar uma Definição de Pronto apropriada para o produto.
Em muitas empresas, a DoD é criada como um padrão organizacional, e todos os times devem seguir ela. E é normal os times acrescentarem itens a esse padrão organizacional, criando uma DoD mais apurada.
Em outras empresas, onde não existe esse padrão organizacional, o Scrum Team define a DoD.
Além disso, é importante destacar, que havendo mais de um Scrum Team trabalhando no mesmo produto, eles devem usar a mesma DoD.
5. Como a DoD é usada em cada Evento Scrum
Vamos ver a influência de cada evento na DoD.
- Sprint Planning: A DoD é uma entrada da Planning, pois isso impacta diretamente em como os Developers vão transformar um Product Backlog Item em plano de trabalho. Exemplo, se na minha DoD eu falo que preciso testar com mil usuários, logo, no Sprint Planning, vou precisar tratar isso, criar algo no plano para testar com mil usuários.
- Daily: Com a DoD em mente, os Developers inspecionam seu progresso ao Sprint Goal, e criam plano para o próximo dia - plano esse com o foco em fazer com que o item atinja a DoD.
- Sprint Review: Durante a inspeção da Sprint Review, tanto o Scrum Team quanto Stakeholders sabem que o Incremento apresentado está realmente Done (seguindo a DoD).
- Retrospective: Aqui que o Scrum Team pode adaptar a Definition of Done para aumento de qualidade. Nesse evento, além do time analisar como eles estão trabalhando com relação a pessoas, ferramentas, e além de identificar itens para sua melhoria contínua, o Scrum Team pode também analisar a DoD, buscando entender como está a qualidade das entregas.
- Sprint: Os Developers usam o Sprint para entrega de Incrementos Done, com a qualidade combinada, mirando o atingimento do Sprint Goal. Por isso, durante todo o Sprint o time precisa ter o DoD em mente, sempre. A cada Sprint o time deve entregar um Incremento Done com a qualidade necessária para poder ser lançado e que não tenha mais trabalho restante para que atinja a DoD.
6. O que não é uma DoD
Não é um critério de aceite: muitos confundem DoD com critério de aceite. O critério de aceite opcional no Scrum, e é uma definição funcional de requisitos de um item.
Por exemplo: quero fazer uma "Tela de login" e uma "Tela de cadastro" - o critério de aceite vai me dizer detalhes funcionais sobre como deve funcionar a "Tela de login", que vão ser diferentes do critério de aceite da "Tela de cadastro". Mas para ambos os itens mencionados, vamos utilizar a mesma DoD, por exemplo "os itens precisam ser validados pelo cliente, e responder em até 1 segundo".
7. Outros pontos a se considerar
O fato de dizermos que o Incremento tem que estar Done, e seja potencialmente lançável, não quer dizer que o Incremento deve ser SEMPRE lançado. Ele deve estar sempre em ponto de lançamento, mas lançar só vai fazer sentido se o Product Owner assim achar.
A DoD auxilia também na previsibilidade do projeto - ou podemos dizer que não ter uma boa DoD pode atrapalhar na previsibilidade do projeto. Isso acontece por que, muitas vezes um Scrum Team com uma DoD fraca, "trabalha trabalha trabalha" para criar um item Done, e quando o Product Owner fala "vamos lançar", os Developers falam "Espera um pouco, pois não testei tudo ainda, e ainda falta integrar x, y e z". E com isso, lá se vão mais horas para terminar algumas tarefas, antes de poder lançar. Isso afeta a forma de monitorar o progresso do time, pois quando pensávamos que já estava tudo pronto a ponto de uso, na verdade não estava. Tanto que um item do manifesto ágil é "Software funcional é a medida primária de progresso", ou seja, a medida mais importante para medir o progresso de um desenvolvimento é o produto Done - mas isso é assunto para outro post.
8. Criando uma DoD
Antes de criar uma DoD, verifique na sua organização, se já não existe um padrão estabelecido, caso exista valide se atende as necessidades do time e o padrão de qualidade desejado para o produto.
Para criar a DoD, é extremamente importante reunir o time e realizar um brainstorm, desta forma todos terão a oportunidade de informar tudo o que acreditam ser necessário, para garantir que um item dentro da Sprint seja considerado Done, e possa ser liberado pelo Product Owner.
Após realizar o Brainstorm, discuta cada um dos itens levantados através dos integrantes do time. Esse é um passo muito importante, pois geralmente ocorrem divergências nesta etapa, e será um momento valioso para garantir o alinhamento sobre o que está sendo construído.
Uma vez validadas todas as ações necessárias para garantir que um item esteja Done, crie uma separação identificando as ações já praticadas pelo time (AS IS), das ações identificadas e que o time ainda não aplica por algum motivo, mas que deveria aplicar (TO BE).
Após finalizar essa etapa, o time terá estabelecido seu DoD atual, e terá visibilidade das ações que deverão ser adicionadas a DoD desejada, para aumentar o padrão de qualidade do produto.
Crie um plano para adicionar as ações ainda não cobertas na DoD atual, e utilize a retrospectiva para inspecionar se o time está evoluindo no tema.
Mesmo que o time já tenha uma DoD, se você estiver chegando no time agora utilize essa dinâmica para realizar uma revisão, e garantir se não falta nada na cobertura da DoD atual
9. Conclusão
O grande ponto do Scrum é a entrega de Incremento Done a cada Sprint, e a DoD é a forma de garantir que o time esteja alinhado sobre o que é esse padrão de qualidade a ser atingido.
Co-Autor
A escrita desse artigo foi feita em conjunto com o apoio do meu amigo Raphael De Souza Godoi - obrigado ;)