Definição de Feito - O quê, por quê e como crescer um

Team Management

Agile 101

Definição de Feito – O Que e Por Que e Como Criar Uma

Quando você olha para os cartões na coluna “Feito” de um quadro Kanban ou Scrum de uma equipe de desenvolvimento, você não pode evitar de se perguntar “o que ainda não foi feito?”. Afinal de contas, um produto de software não é apenas sobre o código. Se isso lhe soa familiar, você se beneficiará de uma Definição de Feito. DoD (Definition of Done) abreviado em inglês. Permita-me acompanhá-lo através do que você precisa saber.

Qual o Significado da Definição de Feito em Ágil?

Em Agile, você usa uma Definição de Feito para dizer o que fez com que padrão de qualidade quando você declara algo como feito. Em termos mais concretos, é enumerado os critérios que você cumprirá antes de declarar que uma história de usuário ou um relatório de bug pode ser entregue (lançado) a seus clientes. Você pode estar se perguntando qual é a diferença com os Critérios de Aceitação que também especificam os critérios que você precisa cumprir para implementar uma história de usuário ou consertar um bug.

Resolvendo o Problema: Definição de Feito vs. Critérios de Aceitação

É uma questão de escopo e foco.
  • A Definição de Feito se aplica a todo o seu trabalho. Os Critérios de Aceitação só se aplicam a um único item de seu backlog.
  • A Definição de Feito esclarece o que você faz como uma equipe. Os Critérios de Aceitação esclarecem o que o produto faz — sua funcionalidade.
  • A Definição de Feito pode conter critérios para aspectos “não-funcionais” e preocupações transversais. Os Critérios de Aceitação falam de aspectos funcionais de um único item de trabalho. Você apenas raramente encontrará aspectos não-funcionais neles.
Agora que isso está esclarecido, eis porque você quer clareza e transparência no que desenvolve como uma equipe.

Quais São os 5 Principais Benefícios de uma Boa Definição de Feito?

Dod
Os benefícios de criar e usar uma boa definição de feito são:
  • Transparência das responsabilidades
Você sabe o que precisa fazer e entende o que não precisa fazer. Por exemplo, você sabe que é seu trabalho implementar um comportamento correto, mas criar vídeos de treinamento não é. Você se tornará mais previsível no que você entrega.
  • Compromisso Realista do Sprint

Com uma lista detalhada de exatamente o que você precisa fazer para alcançar o “Feito”, você está mais apto a avaliar o quanto você pode realisticamente suportar em um Sprint. Você se tornará mais confiável.

  • Redução do risco de retrabalho
As listas de verificação funcionam. A aviação não seria tão segura sem elas. Quando você reduz o trabalho deixado por fazer ao declarar algo como feito, isso significa menos (risco de) retrabalho posteriormente. Você se tornará mais eficiente.
  • Maior qualidade, menor esforço em todos os lugares
À medida que você amadurecer em suas práticas de desenvolvimento, você elevará o patamar na qualidade que entrega e reduzirá a carga de trabalho de outros funcionários. Por exemplo, menos bugs que escapam significam menos exigências para a equipe de suporte. Você entregará melhor qualidade e ajudará sua empresa a se tornar mais eficiente.
  • Predictibilidade e Ritmo Sustentável

Menos defeitos evitados significa que você pode criar valor com toda a equipe ao invés de ter que redirecionar alguns de vocês para resolver bugs. Você se tornará mais produtivo e previsível e começará a trabalhar a um ritmo sustentável constante.

Tudo isso ajuda a aumentar a confiança que uma equipe sente no fornecimento de software valioso e a aumentar a confiança que outras equipes e partes interessadas depositarão em uma equipe.

Mas não se deixe levar por isso ainda. Há armadilhas.

Como Não Se Beneficiar de uma Definição de Feito

Definition Of Done

Como com tudo o que vale a pena ter, você só obtém os benefícios se evitar os erros comuns.

  • Fora da vista, fora da mente
Ter um DoD digital em algum lugar significa que não é provável que você faça disso uma prioridade. Não de propósito, mas porque há tantas coisas exigindo a sua atenção.
  • Muito, cedo demais
Colocar todas as suas aspirações em seu DoD significa que você é incapaz de realizar grande parte dela. Isso não é divertido. Você vai evitá-la ou tratar a maior parte dela como opcional, o que diminui a sua importância. Aposto que você está se perguntando o que pode fazer para evitar essas armadilhas.

Como Criar e Adotar uma Definição de Feito com Sucesso

Adotar uma Definição de Feito requer uma mudança de comportamento, uma mudança de hábitos. Para ser bem sucedido, você vai querer tratá-la como tal. O truque é mantê-la na mente, torná-la fácil — e divertida — de fazer, e reforçá-la até que se torne uma prática estabelecida. Então, qual é a solução?

Como Criar e Desenvolver uma Definição de Feito

Bem, vamos quebrar em partes:

  • Mantenha sempre à vista sua recém definida Definição de Feito à vista completa o tempo todo. Pendure-a em cada parede, cole-a na parte interna das portas do banheiro, pendure-a no balcão do café, etc. Você quer que seja difícil de não ver e de esquecer.
  • Consulte seu DoD com frequência durante as reuniões. Faça dele um tópico natural para discutir quando estiver discutindo sobre o progresso, revisando o trabalho e planejando o que virá em seguida.
  • Faça de sua definição inicial de Feito curta e doce, e fácil de encontrar. Você quer vitórias fáceis no início. Mesmo com um simples “Boa!”, celebrando cada uma delas é crucial para estabelecer novos hábitos.
  • Só eleve o nível quando você estiver cumprindo seu DoD consistentemente e reacenda as comemorações (se você as deixar escapar) quando o fizer.

Não é muito complicado, certo?

Mas, aposto que você ainda tem algumas perguntas.

Como, quem escreve ou define a Definição de Feito, ou quando é mais apropriado para uma equipe de desenvolvimento mudar a definição de feito, e o que colocar nela.

Quem Escreve ou Define a Definição de Feito

O Guia do Scrum diz:

Se “Feito” para um incremento não for uma convenção da organização de desenvolvimento, a Equipe de Desenvolvimento da Equipe Scrum deve definir uma definição de “Feito” apropriada para o produto. Se houver diversas equipes Scrum trabalhando no lançamento do sistema ou produto, as equipes de desenvolvimento em todas as equipes Scrum devem definir mutuamente a definição de “Feito”.

E também:

A Equipe Scrum consiste de um Product Owner (PO), a Equipe de Desenvolvimento e um Scrum Master.

A partir daí, é bastante claro que uma Equipe de Desenvolvimento decide seu DoD. Não o Product Owner, não o Scrum Master, não um gerente de projeto, não o gerente de desenvolvimento, mas sim a equipe de desenvolvimento.

Você quer definir seu DoD antes de trabalhar em um produto como uma equipe (ou você corre o risco de não trabalhar como equipe). Mas quando você atualiza o DoD?

Quando Mudar o que Está em Uma Definição de Feito

Kanban Team
Muitos dirão, “em uma retrospectiva”. Mas as Retrospectivas são destinadas a lidar com mais do que as ações para completar um item de trabalho. E mais, sua Definição de Feito serve como sua lista de verificação de qualidade. Isso faz dela um esforço de melhoria contínua (CI) que merece seu próprio ciclo de melhoria. E lembre-se, uma mudança não é necessariamente uma melhoria. Colocar uma ação de uma Retrospectiva diretamente em seu DoD pode significar que você estará mudando o DoD com mais frequência do que é aconselhável. Mudanças frequentes — especialmente tirando o que você adicionou há pouco tempo — diminuem a percepção que os outros têm de sua confiabilidade. Portanto, de onde quer que seus pontos para seu DoD venham — uma Retrospectiva ou algum outro esforço de melhoria, teste-os primeiro. Ajuste e modifique até que eles ofereçam o que você almejava. Agora, vamos ver o que está em um bom DoD.

Exemplo do Que Está em Uma Boa Definição de Feito para Uma Equipe de Desenvolvimento

Você personaliza uma boa Definição de Feito para a maturidade de suas práticas de desenvolvimento. Portanto, eu lhe darei o básico e seguirei com o que você pode acrescentar à medida que você amadurecer.

O Básico do Básico

  • Implementação avaliada por um segundo par de olhos? Revisado por pares ou desenvolvido em pair programming.
  • Todos os critérios de aceitação foram cumpridos?
  • Código integrado (merged)?
  • Nenhum defeito conhecido?
  • Testes com macacos executados?
  • Guia do Usuário (documentação do cliente) atualizado ou input fornecido aos outros?

Qualidade de Código

  • Livre de erros de compilação, alerta e indícios?
  • Padrão de programação seguido?
  • Métricas de análise estática no alvo ou acima dele?
  • Dependências minimizadas?
  • Código refatorado para atender aos princípios SOLID e outros princípios de design de código?

Staging

  • Livre de erros de construção integrada, alertas e indícios?
  • Smoke test bem-sucedido?
  • Livre de erros de criação de pacotes, alertas e indícios?
  • Pacote implantado para o(s) ambiente(s) de teste?

Testes de Regressão Funcionais

  • Cada item nos Critérios de Aceitação está coberto por pelo menos um teste de aceitação?
  • Testes unitários bem-sucedidos?
  • Testes de integração bem-sucedidos?
  • Testes funcionais ou de sistema bem-sucedidos?
  • Testes de aceitação bem-sucedidos?
  • Testes executados em todas as plataformas suportadas?

Para todos testes automatizados:

  • Cobertura sobre ou acima da norma? (Por exemplo, 85%)
  • Todas as novas unidades / integrações / funcionalidades cobertas por testes?
Para sistemas legados (aplicações onde os testes automatizados não cobrem grandes pedaços de códigos):
  • Golden Master atualizado com cenários para novas e atualizadas funcionalidades?
  • Sem diferenças ou apenas diferenças previstas quando se comparam os resultados do teste Golden Master com os dados do código de produção atual e
Isso é muito, certo? E seguir as práticas CI/CD e DevOps pode acrescentar ainda mais. Mas tenho certeza de que você entendeu o ponto e pode assumir a partir daqui. E… Chegar ao Feito em Sua Definição de Feito Agora você pode parar de se sentir incerto. Você sabe tudo o que precisa saber sobre uma Definição de Feito para que ela funcione a seu favor. Para ter certeza de que quando um cartão está na coluna “Feito”, você realmente concluiu todo o trabalho e sua qualidade é a mais alta que você é capaz de atingir atualmente. Portanto, dê o primeiro passo. Reúna sua equipe e crie sua primeira versão de Definição de Feito.
Medha Case Study

A vida é boa quando suas equipes Agile estão sincronizadas!

Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.

Solicitar Demonstração