O que é a Definição de Pronto?
Já entregou algo e depois descobriu que não estava realmente pronto? A Definição de Pronto (Definition of Done, ou DoD) é a lista compartilhada de critérios que todo trabalho do time precisa atender antes que alguém o considere concluído. Ela vale para toda história de usuário, funcionalidade e incremento, para que "pronto" signifique a mesma coisa, não importa quem fez o trabalho. No Scrum, a Definição de Pronto é o padrão de qualidade de cada incremento. Colocá-la por escrito acaba com as discussões do tipo "isso está pronto?" na hora da revisão e impede que trabalho escondido, como testes ou documentação faltando, passe para a próxima sprint. Esta sessão reúne desenvolvedores, testadores, designers e product owners para montar a lista juntos, de modo que ela inclua as etapas que cada um sabe que costumam ser puladas. O quadro tem quatro colunas: Critérios de Qualidade, Documentação e Comunicação, Testes e Validação, e Implantação e Prontidão. Todos adicionam critérios e, em seguida, o time agrupa e vota neles para chegar a um acordo sobre a lista. Trate o resultado como um documento vivo e revise-o conforme suas ferramentas e padrões mudarem. Para saber mais, consulte o guia da Scrum.org sobre a Definição de Pronto.
Formato de colaboração da Definição de Pronto
Critérios de Qualidade
Que padrões de qualidade o trabalho precisa atender para estar pronto?
Liste as verificações técnicas e de qualidade pelas quais todo trabalho precisa passar, como revisão de código, cobertura de testes, desempenho e padrões de codificação. Pergunte "O que nos daria confiança de que isso não vai quebrar em produção?" para trazer à tona expectativas que ninguém escreveu e torná-las mensuráveis.
Documentação e Comunicação
O que precisa ser documentado ou comunicado antes de estar pronto?
Aborde o que precisa ser registrado por escrito, ou comunicado às pessoas, antes que o trabalho conte como pronto. Pergunte quem precisa saber de uma mudança e o que deve existir depois dela. Os times costumam pular essa parte, então pergunte sobre falhas que já aconteceram.
Testes e Validação
Como verificamos que o trabalho realmente funciona?
Combine com o time as verificações que comprovam que o trabalho faz o que deveria. Vá além dos testes automatizados, incluindo testes manuais, exploratórios e de aceitação, e decida quem aprova e em qual ambiente.
Implantação e Prontidão
O que precisa estar garantido para liberar o trabalho com segurança?
Defina o que precisa estar garantido antes de o trabalho ir para produção. Converse sobre implantação, monitoramento, planos de rollback e quem dá suporte depois que ele estiver no ar. Isso fecha a lacuna entre um código terminado e uma funcionalidade que as pessoas realmente conseguem usar.
Quando utilizar esta análise retrospectiva
- Quando um novo time está se formando e precisa combinar padrões de qualidade desde o início.
- Quando o trabalho é reaberto com frequência ou bugs estão chegando à produção, o que geralmente indica que as pessoas discordam sobre o que é estar pronto.
- Antes do início de um novo projeto, para que o time combine o padrão antes de o trabalho começar.
- Ao integrar novos membros que precisam conhecer as expectativas de qualidade do time.
- Quando uma retrospectiva mostra que as pessoas do time entendem a conclusão do trabalho de formas diferentes.
Perguntas sugeridas para quebra-gelo
- Se o 'pronto' tivesse personalidade, como ele seria: perfeccionista, pragmático ou herói de última hora?
- Qual foi a coisa mais surpreendente que você já descobriu que não estava realmente terminada?
Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →
Ideias e dicas para sua reunião de retrospectiva
- Construa a Definição de Pronto com o time inteiro para que todos se sintam donos dela. Não deixe uma única pessoa escrevê-la sozinha.
- Mantenha os critérios realistas. Uma DoD que o time nunca cumpre acaba sendo ignorada.
- Torne cada critério específico o bastante para ser verificado, para que não haja discussão sobre se ele foi atendido.
- Revise-a a cada poucas sprints, conforme seus padrões e ferramentas mudarem.
- Dê a todos um tempo para adicionar ideias individualmente antes da discussão em grupo, para que as pessoas mais quietas também contribuam.
- Mantenha-a separada dos critérios de aceitação. A DoD vale para todo o trabalho, enquanto os critérios de aceitação pertencem a uma história específica.