Critérios de Qualidade

Que padrões de qualidade o trabalho precisa atender para estar pronto?

Todo o código foi revisado e aprovado por pelo menos um outro desenvolvedor.
A cobertura de testes unitários atinge o limite combinado de 80% ou mais.
Não há nenhum bug crítico ou de alta severidade em aberto.
Documentação e Comunicação

O que precisa ser documentado ou comunicado antes de estar pronto?

A documentação para o usuário foi atualizada para refletir a mudança.
As notas de release e as entradas do changelog estão completas.
A documentação da API reflete os endpoints novos ou alterados.
Testes e Validação

Como verificamos que o trabalho realmente funciona?

Todos os critérios de aceitação da história de usuário foram atendidos.
Testes manuais concluídos em todos os navegadores e dispositivos suportados.
Funcionalidade validada pelo product owner antes do fechamento.
Implantação e Prontidão

O que precisa estar garantido para liberar o trabalho com segurança?

A funcionalidade está implantada em produção ou protegida por uma feature flag.
Monitoramento e alertas estão configurados para a nova funcionalidade.
Existe um plano de rollback ou recuperação caso algo dê errado.

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.

Perguntas frequentes

O que é a Definição de Pronto no ágil?
É uma lista compartilhada de critérios que todo trabalho precisa atender antes que o time o considere concluído. Ela dá a todos o mesmo padrão de qualidade e acaba com as discussões sobre o que significa estar pronto.
Qual a diferença entre a Definição de Pronto e os critérios de aceitação?
A Definição de Pronto vale para todos os itens de trabalho. Os critérios de aceitação pertencem a uma história de usuário e descrevem o que ela precisa fazer. O trabalho só está concluído quando atende aos dois.
Quem deve participar da criação da Definição de Pronto?
O time inteiro, incluindo desenvolvedores, testadores, designers e o product owner. As pessoas seguem um padrão que ajudaram a escrever, e cada papel sabe o que costuma ser pulado na sua área.
Com que frequência devemos atualizar nossa Definição de Pronto?
Revise-a a cada poucas sprints, muitas vezes em uma retrospectiva, ou quando suas ferramentas ou habilidades mudarem. Adicione critérios à medida que o time se tornar capaz de cumpri-los.
Quanto tempo leva para criar uma Definição de Pronto?
Uma primeira sessão costuma levar de 45 a 90 minutos, dependendo do tamanho do time e do quanto ele já está alinhado. As revisões seguintes são bem mais curtas.
Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva