Cada equipe tem uma definição diferente do que significa "feito", mas é importante ter um e garantir que uma história atenda aos critérios definidos antes de ser aceita.
Alguns critérios normalmente especificados por equipes incluem:
Sem um DDO bem definido, é fácil chegar a uma situação em que muitas coisas estão a meio caminho e nada é verdadeiramente completo.
Coisas como níveis de recuo e espaço em branco podem não parecer importantes, mas ter um código corretamente formatado vai muito longe da legibilidade e da mantenibilidade. As convenções devem ser discutidas e acordadas como uma equipe e, em seguida, seguidas no código.
À medida que a implementação do projeto aumenta em tamanho, também aumenta a quantidade de tempo necessária para testá-la. Sem uma boa cobertura de teste, a equipe de testes não poderá ser dimensionada e os desenvolvedores acabarão se enterrando em insetos.
Os desenvolvedores devem praticar TDD, escrevendo testes de unidade com falha antes do código de produção que atenderá aos requisitos. O controle de qualidade deve criar um conjunto automatizado de testes de aceitação para garantir que o sistema funcione como esperado de um alto nível.
Há estruturas personalizadas disponíveis, como Jackalope e Prosper, para tornar a zombaria das APIs de JCR mais simples para garantir a produtividade dos desenvolvedores ao escrever testes de unidade.
O sistema deve estar disponível para demonstração à empresa no final de cada iteração. Ao manter o sistema em um estado pronto para demonstração, a equipe estará sempre dentro de uma iteração de estar pronta para produção e a dívida técnica poderá ser mantida em um nível sustentável.
A implementação de um ambiente de integração contínua permitirá que você execute testes de unidade e testes de integração de forma fácil e repetida. Também dissociará as implantações da equipe de desenvolvimento, permitindo que as outras partes da equipe sejam mais eficientes e permitindo implantações mais estáveis e previsíveis.
Se os testes de unidade levarem muito tempo para serem executados, os desenvolvedores evitarão executá-los e perderão seu valor. Se levar muito tempo para criar o código e implantá-lo, as pessoas farão isso com menos frequência. Tornar os tempos de compilação curtos uma prioridade garante que o tempo que investimos em nossa cobertura de teste e na infraestrutura de CI continuará a tornar a equipe mais produtiva.
As ferramentas de análise de código podem ser valiosas, mas somente se seus relatórios levarem à ação da equipe de desenvolvimento. Sem ajustar a análise que essas ferramentas fornecem, as recomendações geradas não serão relevantes e perderão seu valor.
Os Scout têm uma regra: "Deixe-o melhor do que você encontrou." Enquanto todos os membros da equipe de desenvolvimento aderirem a essa regra e limparem algo quando encontrarem uma bagunça, o código melhorará constantemente.
Os recursos de YAGNI (ou Você não vai precisar dele) são coisas que são implementadas quando esperamos que precisaremos de algo no futuro, mesmo que não precisemos disso agora. Idealmente, devemos implementar a coisa mais simples que funcionará hoje e usar a refatoração contínua para garantir que a arquitetura do sistema evolua com os requisitos ao longo do tempo. Isso nos permitirá focar no que importa e evitar o aumento do código e o aumento dos recursos.