O que é a definição de concluído?

Atlassian Por Atlassian
Buscar tópicos

"Essa tarefa está concluída?"

Para responder essa pergunta, que parece simples, é necessário verificar se um item ou incremento de produto está concluído ou em progresso. Mas isso só funciona quando uma equipe e as partes interessadas definem de fato o item como "concluído".

Nas metodologias de gestão ágil de projetos que usam o Kanban ou a estrutura do Scrum, "concluído" é uma coluna em um quadro visual com itens concluídos. Uma definição clara de concluído (DoD) permite que equipes ágeis, incluindo equipes de DevOps e Scrum, concluam itens com mais eficiência.

Cronograma do JSW

Este guia explica o significado de DoD nas metodologias ágeis e como criar uma para tornar os projetos mais eficazes e valiosos.

Noções básicas sobre a DOD no método ágil

DoD é um conjunto de critérios que o incremento de um produto deve atender para que seja considerado concluído e pronto para os clientes. É um entendimento compartilhado entre os membros da equipe sobre quando o incremento de um produto está pronto para ser lançado, mesmo quando esse incremento for grande e tiver muitos itens. Ao definir com clareza o que "concluído" significa no projeto, uma equipe ágil pode se concentrar em agregar valor a cada sprint e minimizar o retrabalho.

É importante observar que a definição de concluído não é criada por uma única pessoa. Em vez disso, ela é um acordo feito por toda a equipe do projeto, que inclui desenvolvedores, testadores, proprietários de produtos e outras partes interessadas. Assim, há a garantia de um processo mais tranquilo durante os sprints, já que todos estão usando a DoD como guia junto com qualquer checklist antes de marcar um item como concluído.

Exemplos de definição de concluído

A DoD de um projeto varia conforme o tipo de projeto e a equipe envolvida. Os exemplos de DoD a seguir ilustram como essas definições diferem entre os tipos de projeto:

Em um projeto de desenvolvimento de apps móveis, a DoD pode incluir:

  • Todas as imagens são compactadas.
  • Todo o código é reduzido e compactado com gzip.

Em um projeto de desenvolvimento de software, exemplos de critérios na DoD podem incluir:

  • Todo o código foi testado por completo com testes de unidade, de integração e de ponta a ponta.
  • O incremento do produto foi implementado em um ambiente de staging e testado pela equipe.

Um projeto genérico pode ter os seguintes itens como parte da DoD:

  • Todos os erros foram resolvidos.
  • Toda a documentação da versão foi escrita e editada.

Definição de concluído versus definição de pronto

A DoD é um conjunto de critérios de alto nível que define quando o incremento de um produto é concluído. Ela garante a qualidade e a consistência de um produto. As equipes costumam usar a DoD no final de um sprint ao verificar a qualidade do incremento de um produto.

Por outro lado, a definição de pronto (DoR) é um conjunto de critérios específicos e de baixo nível que se aplica apenas aos itens do backlog do produto. A DoR define quando um item do backlog está pronto para uma equipe trabalhar em um próximo sprint. Uma equipe usa a DoR durante o processo de refinamento do backlog no início de um sprint.

Por que a definição de concluído é importante?

Ter uma DoD é vital para preparar um produto de qualidade que os clientes querem, pois esclarece quando um item pode ser marcado como concluído e está pronto para ser incluído no incremento de um produto. Uma DoD bem elaborada traz os seguintes benefícios:

Aumenta a qualidade: verificar cada incremento de produto em relação aos critérios da DoD garante que as equipes ágeis tenham em mente as metas de qualidade durante todo o desenvolvimento de um produto. É a garantia de que elas vão atender às normas de qualidade exigidas para a versão.

Minimiza o risco: seguir a DoD minimiza o risco de retrabalho ou os consequentes atrasos, pois a equipe sabe muito bem quais critérios um item deve seguir antes de ser marcado como concluído. É uma garantia de qualidade em todas as etapas do projeto.

Melhora o alinhamento da equipe: como a DoD é um entendimento compartilhado do que significa "concluído" no contexto do projeto, as equipes podem se concentrar com mais facilidade nos requisitos do cliente e em agregar valor a cada sprint.

Mede o progresso: ter uma DoD clara permite que as equipes acompanhem o número de incrementos de produtos que atendem aos critérios de "concluído". Por exemplo, as métricas do Scrum podem incluir velocidade, que mostra quantos incrementos de produto concluídos uma pessoa entrega dentro de um prazo definido.

Etapas para criar uma definição de concluído

Embora as etapas exatas para criar uma definição de concluído variem conforme a equipe e o projeto, o processo segue um padrão semelhante. Estas são as etapas para criar uma DOD:

1. Trabalhe com a equipe certa

É importante trabalhar com os membros da equipe certos ao criar uma DoD, pois os critérios decididos formam um entendimento compartilhado entre todos os participantes. Ou seja, inclua todos os que tiverem algo importante a dizer sobre o que é "concluído" no projeto: proprietários do produto, o mestre do Scrum, membros da equipe do Scrum, testadores, gerentes de produto, patrocinadores e outras partes interessadas relevantes.

Cada membro da equipe traz o próprio conhecimento para o projeto e pode avaliar quais critérios fazem sentido para a área em que trabalham. Se você tiver os membros da equipe errados ou omitir os principais membros da equipe, os critérios da DoD podem não ser tão abrangentes, resultando em um produto abaixo do padrão.

2. Estabeleça os critérios

A maior tarefa ao definir "concluído" é estabelecer os critérios que a equipe vai usar no projeto. Definir os critérios da DoD é crucial porque vai afetar a qualidade do trabalho feito.

Como vão saber se cada componente do projeto está completo? Que condições vão indicar que o incremento desse produto foi concluído? Os critérios devem ser específicos, mensuráveis, atingíveis, relevantes e com prazo determinado. Para escolher os critérios apropriados, a equipe deve se fazer duas perguntas principais:

  1. Os critérios são específicos o suficiente? Não seja vago (todo o código foi testado); seja específico (todo o código foi testado por completo com de testes de unidade, de integração e de ponta a ponta).
  2. Os critérios são focados no cliente? Um bom exemplo disso é "Toda a documentação foi escrita e atualizada", o que deve facilitar para o usuário final encontrar orientação ao usar o produto.

3. Crie uma checklist de conclusão

Embora os critérios da DoD possam parecer senso comum ao preparar o lançamento de incrementos maiores de produtos, eles também devem ser aplicados a tarefas, itens ou erros menores nos quais a equipe trabalha durante o sprint. Uma checklist de conclusão para cada tarefa ou item pode garantir que a equipe faça um trabalho de alta qualidade e consistente.

4. Atribua critérios de aceitação às histórias de usuários

Os critérios de aceitação (AC) se referem às condições que as histórias de usuários devem atender para se tornarem aceitáveis para os clientes. Eles diferem dos critérios da DoD porque lidam com histórias ou funções de usuários, em vez de incrementos de produtos.

Mas, como a DoD, o AC também é um critério acordado para determinar se uma história do usuário ou uma tarefa individual foi concluída. Se, por exemplo, uma história do usuário for: "Como usuário, quero poder usar um campo de pesquisa para encontrar o produto que estou procurando". Os critérios de aceitação podem incluir:

  • O campo de pesquisa está na barra de navegação superior.
  • A pesquisa começa depois de tocar no botão "Pesquisar".
  • O campo de pesquisa contém texto cinza de espaço reservado que diz "O que você está procurando?"

5. Revise e atualize a DoD

A DoD não é um documento estático. Cada bug ou erro encontrado durante um sprint é um problema de qualidade que uma definição pouco clara de concluído pode ter causado. Portanto, atualizar a DoD é crucial para que o bug não ocorra outra vez.

Revise e atualize a DoD durante as análises de sprint para se manter relevante para o projeto. À medida que os projetos evoluem e as equipes aprendem mais sobre os requisitos do cliente, a DoD também pode precisar ser revisada para ser viável. Garanta que haja oportunidades para os membros da equipe sugerirem alterações na DoD durante as revisões de sprint ou reuniões de refinamento do backlog.

Garanta uma DoD bem definida com o Jira Software

A Atlassian e o Jira Software facilitam a criação da definição de concluído. Para criar uma DoD com o Jira Software, basta adicionar os critérios da DoD em um menu. Se quiser, você pode limitar os critérios por tipo do item. Crie checklists usando caixas de seleção ou listas com marcadores e escolha onde exibir essas checklists.

O Jira Software também tem outras ferramentas para todas as necessidades de gestão de programas e projetos, desde o planejamento ágil até as reuniões rápidas de sprint e tudo mais. Teste grátis.

Definição de concluído: perguntas mais frequentes

Quem é responsável por criar a definição de concluído?

Em geral, é a equipe de desenvolvimento, liderada pelo mestre do Scrum, que cria a DoD. No entanto, ela deve buscar informações de proprietários de produtos, testadores e outras partes interessadas.

Qual é a diferença entre definição de concluído e critérios de aceitação?

A DoD é um conjunto de critérios de alto nível para determinar se o incremento de um produto está completo. Ela se aplica a todos os incrementos do produto e define a qualidade geral de um produto.

Por outro lado, os critérios de aceitação são condições de baixo nível que se aplicam apenas a histórias ou funções específicas de usuários. O AC define se uma história do usuário é aceitável para um cliente. Um exemplo de DoD poderia ser "Toda a documentação foi escrita e atualizada". Um exemplo de AC poderia ser "O link para a documentação do usuário pode ser acessado no menu de navegação".

Quais são algumas das práticas recomendadas para criar uma definição de concluído?

Defina os critérios com a equipe: definir a DoD deve ser um esforço colaborativo que envolva toda a equipe, incluindo desenvolvedores, testadores, proprietários de produtos e partes interessadas relevantes. A criação de uma DoD garante uma compreensão compartilhada do que significa a conclusão de um incremento de produto.

Mantenha visível: a DoD deve estar disponível e visível durante o planejamento de sprints ou quando houver discussões sobre a estimativa de itens do backlog do produto. Ela deve estar acessível para consultas regulares. Imprima e fixe-a na parede, ou a inclua em uma wiki ou no plano do projeto.

Seja prático e realista: a DoD deve ser viável dentro do prazo e com os recursos disponíveis. Mais importante: deve ser relevante para aquilo que os clientes de fato precisam.