Como é uma boa “definição de pronto” para uma equipe madura?

Ao examinar exemplos de definições de feito em várias fontes, eles geralmente incluem pontos como

• código completo
• testes de unidade executados
• código revisto por pares ou emparelhado
• código registrado
• documentação atualizada
• …

Em nossa equipe, temos uma lista semelhante, mas ninguém nunca a examina, porque esses pontos parecem tão óbvios que não ocorreria a ninguém pular nenhuma dessas etapas. Então, estávamos nos perguntando se isso é principalmente uma ferramenta para as equipes fazerem a transição para um processo ágil e se não devemos nos livrar dele.

Por outro lado, muita literatura afirma que todas as equipes de alto desempenho têm uma forte definição de feito. Esse tipo de sugestão de que podemos perder uma oportunidade de melhorar aqui.

Então, quais são exemplos de fortes definições de feito de uma equipe madura? Que tipo de pontos eles incluem normalmente?

As diretrizes estão lá para todos. Em uma equipe madura, como você mencionou, todo mundo está fazendo isso, então isso não significa que não há lugar para isso. Suponha que um novo membro se junte, que não tenha sido exposto a essa metodologia antes. Ter a estrutura no lugar seria vital para ele. Ele não precisaria incomodar outros membros ou não "esqueceria" uma entrega.

Na minha opinião, liste tudo, incluindo o óbvio. Talvez, tenha uma "lista curta de trapaças" para as não óbvias, se isso ajudar aqueles que desejam uma lista mais curta, mas considere o caso de novos membros entrando.

É um processo iterativo, toda vez que você vê algo que pode melhorar, adicione-o na definição de done. Horas extras, você desenvolverá uma lista relevante para sua empresa. Anann já mencionou alguns que valem a pena.

Só porque os pontos são flagrantemente óbvios não significa que as pessoas sempre os realizem. Vamos dar outros dois exemplos - pilotos e cirurgiões. O cockpit de um avião comercial ou de uma sala de operações tem várias pessoas, com muita educação e experiência entre elas. No entanto, as coisas ainda dão errado - as etapas são feitas fora de ordem, algo é esquecido, algo é feito incorretamente. Vi várias fontes no site que um grande número (até 70%) de incidentes de aeronaves atribuídos a erro do piloto poderia ter sido evitado com uma lista de verificação . No mundo da medicina, até 29% dos processos por negligência na Holanda poderiam ter sido evitados com o uso de uma lista de verificação, de acordo com pesquisadores. Embora essas pessoas tenham sido treinadas e, em retrospectiva, provavelmente identificassem facilmente o que fizeram de errado, algo aconteceu que as levou a caducar. Ainda não li, mas o Manifesto da Lista de Verificação deve ser relevante. Ele foi escrito de uma profissão médica, mas as vantagens de tornar uma lista de verificação ou fluxograma visível como um lembrete do que fazer são aplicáveis ​​a qualquer profissão.

Portanto, o primeiro passo seria criar uma lista de coisas que fazem parte da sua definição de concluído e torná-la visível. Não importa o quão óbvia essa tarefa seja, se ela precisar estar completa para que a história seja considerada concluída, ela precisa estar nessa lista. A lista precisa estar em algum lugar visível para a equipe. Observe que não precisa ser nada extravagante ou formal - talvez apenas uma série de perguntas que todos precisam se perguntar antes que uma história possa ser concluída.

O segundo passo é decidir o que se passa nessa lista de verificação para sua definição de concluído. Tudo o que você precisa fazer para concluir uma tarefa deve ser específico, inequívoco, aceitável e realista. Também precisa estar dentro de um contexto de tempo para a consideração do feito. Por exemplo, você não precisa incluir "modificar código" ou "modificar design" em uma definição de concluído - se você não precisou alterar um produto de trabalho, não havia necessidade da história.

Eu suspeitaria que uma boa lista de verificação para servir como base para uma definição de concluído seria:

• Todos os testes de unidade, integração, sistema e aceitação associados foram atualizados?
• O produto de trabalho foi transformado em sua forma liberável? Por exemplo, código criado, documentação no formato de arquivo exportável etc.
• Todos os produtos de trabalho associados foram revisados ​​por pares? Exemplos de produtos de trabalho incluem código fonte (produção e teste), comentários, documentos de design, procedimentos de teste e manuais do usuário.
• Todos os testes associados (em todos os níveis de teste) foram executados e passaram?
• O código foi mesclado no repositório de integração?

Obviamente, você precisará criar uma boa definição de feito, incluindo outras atividades que sua equipe e seu cliente agregam valor. Se estiver na lista de verificação, deve ser algo que precisa ser feito para agregar valor a alguém (a equipe, o cliente, o usuário). Enumerando claramente o que você faz, você também pode identificar e eliminar atividades estranhas para melhorar o processo.

Isso realmente parece que você é um cara de sorte:

Em nossa equipe, temos uma lista semelhante, mas ninguém nunca olha para ela porque esses pontos parecem tão óbvios

Sua equipe já está "madura" ;-). Mas sempre há espaço para melhorias!

Para sua pergunta:

Então, quais são exemplos de fortes definições de feito de uma equipe madura? Que tipo de pontos eles incluem normalmente?

No topo da sua lista, você pode adicionar:

Várias métricas de qualidade de código: - Instabilidade, Abstração - LOC vs DLOC (documentado) - etc ...

A regra geral é que a métrica não deve piorar com o seu commit. No topo, você pode formular um "pronto: com excelência" se alguém realmente melhorar as métricas. Embora isso (métricas melhorando) geralmente não faça parte das fases de desenvolvimento (novos recursos), mas das fases de refatoração.

Em uma das minhas empresas anteriores, tínhamos uma definição de "concluído" que dizia que suas métricas precisam permanecer abaixo de certos limites; se você ultrapassar, ainda não terminou. (A complexidade ciclomática nunca deve ultrapassar os 15, a menos que você tenha uma desculpa muito, muito boa, como cálculos complicados.)

O mesmo vale para as violações do tipo Checkstyle, especialmente se você tiver um conjunto de regras personalizado para verificar o estilo de código de suas equipes. Se você violar o padrão de codificação, ainda não o fez.

Então você não poderia apenas executar o UnitTest, mas também medir a cobertura do código. Se pelo menos 50% são cobertos, você não está pronto. Embora essa seja uma definição superficial de concluída, você deve ter testes para os métodos principal / principal / crítico e não necessariamente para 100% da sua base de código.

Ah, sim ... e se você tiver (você deveria) um servidor de IC com integração automática de filial ... isso só será feito se a confirmação na ramificação DEV se fundir com a ramificação LIVE atual e não causar erros. (Testes de unidade, etc.)

hmmm ... é tudo o que me lembro direito de empresas / projetos anteriores, que não foram mencionados em sua lista.

Espero que tenha lhe dado algumas idéias ;-)

Felicidades,

anann

Em um ambiente TDD / BDD, a definição de "done" (tecnicamente "Code Complete", como a definição de Matt S de "really 'done'" está correta) é bastante simples:

• Todos os testes automatizados são aprovados (esses testes automatizados devem incluir novos escritos para a matéria em questão para verificar se a funcionalidade ou o comportamento necessário existe e funciona)
• Revisão de código aprovada (pelo menos um desenvolvedor sênior da equipe está contente em deixar seu trabalho se tornar parte da base de código e que você não "trapaceou" ou "invadiu" sua história)
• Confirme com êxito (incluindo o robô de compilação que passa em todos os testes automatizados, métricas de cobertura de código, verificações de estilo de policiais etc.)

Neste ponto, você pode seguir em frente. Esses três pontos são críticos, mas são tudo o que o codificador de equipe médio deve se preocupar. Escritas ou não escritas, elas são invioláveis ​​em um ambiente TDD. A documentação, quando os codificadores são os responsáveis ​​pela documentação, é um ponto adicional. Na minha última equipe do Agile, a documentação foi tratada pelos BAs / QAs; eles sabiam o que o cliente queria, executavam os UATs e, portanto, podiam documentar o novo recurso de uma maneira que fosse significativa para o cliente; portanto, a documentação não fazia parte da definição de "concluído" do codificador, embora fizesse parte da definição da equipe.