Definition of Done no Jira: combine o que significa “concluído”

Um engenheiro termina uma alteração e avança o item do Jira. Uma pessoa de testes descobre que a nova tela funciona, mas um fluxo existente parou de funcionar. O suporte fica sabendo da mudança por meio de um cliente confuso. Todos usaram a palavra concluído, mas cada pessoa quis dizer algo diferente.

Uma Definition of Done dá à equipe um padrão compartilhado de conclusão. Ela torna visíveis as verificações de qualidade esperadas antes do início do trabalho, para que a revisão dependa menos de quem lembra de fazer a pergunta certa.

Neste guia, criaremos um exemplo para uma equipe fictícia de portal do cliente, distinguiremos verificações compartilhadas de qualidade dos critérios de aceitação específicos de uma funcionalidade e colocaremos ambos junto a um item do Jira usando a ferramenta Definition of Done & AC do Power Pack.

O que é uma Definition of Done?

O Scrum Guide descreve a Definition of Done como o padrão de qualidade que um Incremento deve cumprir. Ela oferece um entendimento compartilhado do trabalho concluído. Quando uma organização estabelece um padrão, ele é o mínimo para seus times Scrum. Consulte o Scrum Guide oficial.

Para nosso exemplo prático, pense nela como um pequeno conjunto de perguntas que a equipe faz sobre cada alteração relevante. A implementação foi revisada? As verificações combinadas passaram? As informações necessárias para dar suporte à alteração estão disponíveis?

As perguntas exatas dependem do produto e dos riscos. Um portal público de clientes, um relatório interno e um sistema crítico para a segurança precisam de padrões diferentes. Copiar a lista de outra equipe sem discussão pode deixar lacunas importantes e acrescentar trabalho sem propósito.

Um padrão útil descreve um resultado observável. “Alta qualidade” expressa uma ambição. “As verificações de regressão combinadas passaram, com resultados vinculados ao item do Jira” descreve algo que uma pessoa pode inspecionar.

Separe a qualidade compartilhada do comportamento da funcionalidade

Nossa equipe fictícia está adicionando preferências de notificação. Os clientes poderão ativar ou desativar um e-mail de resumo semanal. Mensagens importantes da conta ficam fora dessa preferência.

A funcionalidade precisa de seus próprios critérios de aceitação. Por exemplo, uma escolha salva deve continuar aparecendo depois que o cliente sai da conta e retorna. Esse requisito pertence à funcionalidade porque descreve a experiência esperada do cliente.

A Definition of Done abrange o padrão mais amplo de conclusão. Revisar a implementação, verificar comportamentos existentes afetados e atualizar as orientações de suporte pode se aplicar a muitas alterações diferentes.

As duas listas importam. Uma funcionalidade pode se comportar como solicitado e ainda carecer de trabalho essencial de qualidade. Da mesma forma, código revisado e verificações de regressão aprovadas não demonstram que a funcionalidade solicitada se comporta corretamente.

Comece pelas lacunas que sua equipe realmente encontra

Reúna as pessoas que desenvolvem, verificam e dão suporte ao produto para uma conversa breve. Use um exemplo recente de trabalho que parecia concluído, mas exigiu acompanhamento inesperado.

Nossa equipe do portal identifica três problemas recorrentes. Comentários de revisão às vezes ficam sem resolução. Configurações existentes da conta recebem pouca cobertura de regressão. As instruções de suporte chegam depois que a funcionalidade está disponível.

Esses problemas sugerem verificações úteis. Também dão à equipe um motivo para manter o padrão curto: cada entrada deve evitar uma falha reconhecível ou estabelecer uma condição necessária de qualidade.

Pergunte como alguém verificará cada entrada proposta. Se ninguém conseguir descrever a evidência, melhore a redação antes de adotá-la. “Documentação concluída” pode se referir a notas da versão, notas internas de projeto ou um artigo de ajuda para clientes. Combine quais informações são necessárias e onde devem ficar.

Também combine quem normalmente executa as verificações. Essa conversa pode acontecer no processo habitual de planejamento. Uma lista, sozinha, não atribui uma pessoa à revisão nem reserva tempo na agenda.

Esboce uma lista prática e compartilhada

Esta é a primeira versão da equipe do portal. É um acordo de trabalho ilustrativo, não um padrão universal.

• A revisão da implementação está concluída e os comentários obrigatórios foram resolvidos.
• Os critérios de aceitação combinados para o item foram verificados.
• As verificações de regressão combinadas para os fluxos de conta afetados passaram.
• As verificações de acessibilidade combinadas para as telas alteradas passaram.
• As orientações de suporte refletem o comportamento alterado para o cliente.
• Os resultados de verificação e links relevantes de revisão estão registrados no item do Jira.

Antes de usar essa lista, a equipe registra o que as verificações de regressão e acessibilidade incluem. Caso contrário, duas pessoas poderiam marcar a mesma frase depois de executar trabalhos diferentes.

Para o portal, o conjunto de regressão combinado inclui entrar na conta, abrir as configurações e atualizar um campo existente do perfil. A revisão de acessibilidade dos controles alterados inclui operação por teclado, foco visível e rótulos compreensíveis. Esses são exemplos das verificações escolhidas pela equipe, não um padrão completo de acessibilidade.

A entrada de suporte também precisa de uma interpretação prática. Se uma alteração não afeta a experiência do cliente, a equipe deve estabelecer previamente um padrão adequado para esse tipo de trabalho. Evite obrigar as pessoas a improvisar exceções apenas para deixar a lista verde.

Adicione o padrão a um item do Jira

Abra o item relevante do Jira e encontre o cartão Definition of Done & AC do Power Pack. Ele contém abas separadas de Acceptance Criteria e Definition of Done. Selecione Definition of Done antes de adicionar as verificações compartilhadas.

Para uma lista pequena, digite o título de uma verificação e selecione Add ou pressione Enter. Mantenha cada título focado em uma condição que possa ser revisada. Uma frase longa contendo três verificações sem relação dificulta representar a conclusão parcial.

Você também pode selecionar Bulk Import e colar uma lista Markdown. Por exemplo, cole as seis entradas acima com um hífen e um espaço no início de cada linha. Entradas comuns de caixas de seleção Markdown também são aceitas.

A importação adiciona entradas à aba selecionada. Confira a aba antes de confirmar e inspecione a lista resultante depois. Importar o mesmo conteúdo novamente pode adicionar entradas que já existem; use a ação deliberadamente, não como uma atualização.

Use entradas desmarcadas para trabalho ainda não verificado. Caixas de seleção Markdown marcadas são importadas como concluídas; marcas copiadas de um item anterior não devem substituir a revisão da alteração atual.

O padrão combinado precisa ser colocado manualmente em cada item relevante. Mantenha uma cópia de referência na documentação normal da equipe e cole as verificações apropriadas nos novos itens. Esse processo é uma prática da equipe, não uma conexão automática entre um padrão central e todos os itens.

Percorra uma revisão real

Suponha que a funcionalidade de preferências de notificação esteja pronta para revisão. Maya verifica os resultados para o cliente enquanto Priya verifica o conjunto de regressão combinado. Leo resolve os comentários restantes da revisão da implementação e vincula o registro da revisão.

A primeira análise revela que a preferência é salva corretamente, mas o foco do teclado desaparece ao selecionar Save. A equipe deixa a verificação de acessibilidade incompleta, registra o problema na discussão normal do Jira e o corrige antes de repetir a verificação relevante.

As orientações de suporte também não estão prontas. Isso permanece visível mesmo com os critérios de aceitação específicos da funcionalidade concluídos. As listas separadas ajudam a explicar por que a equipe ainda tem trabalho a fazer.

Depois que uma verificação realmente passar, selecione seu botão Done. Selecione-o novamente se novas informações indicarem que a entrada deve voltar a pendente. Registre resultados de testes, links de revisão e decisões importantes pelo processo normal de documentação ou do Jira da equipe.

Uma entrada concluída registra a avaliação da equipe. Ela não executa a verificação, coleta suas evidências nem estabelece quem a realizou. Se a identidade de quem revisou ou o momento forem importantes, registre essas informações explicitamente no processo habitual de revisão.

Leia o indicador de prontidão com atenção

A ferramenta mostra as quantidades concluídas e totais de cada aba. Seu indicador exibe Ready for Release somente quando as duas listas contêm pelo menos uma entrada e todas as entradas de ambas estão concluídas. Caso contrário, exibe In Verification.

Essa regra torna o indicador útil para identificar entradas inacabadas. Também explica por que uma lista Definition of Done concluída não produz o estado de conclusão total enquanto Acceptance Criteria permanece vazia.

Trate o texto como um resumo do estado das listas. Ele não prova que as verificações foram suficientes, que as evidências foram convincentes ou que o produto pode ser lançado com segurança. Uma equipe consegue marcar uma verificação mal escrita como concluída tão facilmente quanto uma útil.

A lista também não bloqueia uma transição no Jira nem a integração de um pull request. Continue usando o processo normal de entrega e lançamento da equipe para tomar essas decisões.

Mantenha o padrão útil conforme o trabalho muda

Revise o padrão quando um defeito recorrente revelar uma verificação ausente, quando o produto mudar de forma significativa ou quando uma verificação existente deixar de fornecer informações úteis.

Por exemplo, a equipe do portal pode descobrir que as alterações de preferências funcionam imediatamente, mas falham após uma sincronização posterior. Essa descoberta pode levar a uma regra mais ampla de verificação para funcionalidades que dependem de processamento adiado. Primeiro, a equipe deve decidir a quais alterações a regra se aplica e quais evidências demonstrarão sucesso.

Atualize o padrão de referência e discuta como aplicar a mudança ao trabalho já em andamento. As listas dos itens existentes não herdam essa revisão automaticamente. Inspecione os itens afetados e adicione manualmente as novas verificações combinadas onde for apropriado.

Evite ampliar a lista depois de cada erro isolado. Às vezes, a resposta melhor é um critério de aceitação específico, uma tarefa de implementação mais clara ou uma alteração no processo de revisão. O padrão compartilhado deve continuar sendo algo que a equipe consegue entender e realmente aplicar.

Experimente em um item atual

Escolha um item próximo da revisão. Combine um padrão compartilhado e curto de qualidade, coloque-o na aba Definition of Done e adicione os resultados específicos para o cliente em Acceptance Criteria.

Percorra as verificações em conjunto e vincule as evidências onde a equipe normalmente as registra. Marque as entradas como concluídas somente após a verificação e revise o trabalho restante pelo processo habitual de entrega.

O resultado útil é uma conversa mais clara. Quando alguém disser que a alteração de preferências de notificação está concluída, a equipe poderá explicar quais resultados funcionam, quais verificações de qualidade passaram e de onde veio essa conclusão.

• Scrum Guide — Definition of Done