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 pelas equipes incluem:
Sem um Dd bem definido, é fácil acabar numa 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 devidamente formatado vai muito longe para a legibilidade e a manutenibilidade. As convenções devem ser discutidas e acordadas como uma equipe e então seguidas no código.
À medida que a implementação de um projeto cresce em tamanho, o mesmo acontecerá com o tempo necessário para testá-la. Sem uma boa cobertura de teste, a equipe de teste não poderá ser dimensionada e os desenvolvedores acabarão enterrados em insetos.
Os desenvolvedores devem praticar o TDD, gravando testes de unidade com falha antes do código de produção que atenderá aos seus requisitos. O controle de qualidade deve criar um conjunto automatizado de testes de aceitação para garantir que o sistema funcione como esperado a partir de um nível alto.
Há estruturas personalizadas disponíveis, como Jackalope e Prosper, para tornar o zombaria das APIs em JCR mais simples para garantir a produtividade dos desenvolvedores enquanto escrevem 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 em uma iteração de prontidão para a produção e a dívida técnica pode ser mantida em um nível sustentável.
A implementação de um ambiente de integração contínua permitirá a execução fácil e repetida de testes de unidade e testes de integração. 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 construção curtos uma prioridade garante que o tempo que investimos na nossa cobertura de testes e na infraestrutura de IC continuarão 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 oferecem, as recomendações que geram não serão relevantes e perderão seu valor.
Os Scout Boy têm uma regra: "Deixe melhor do que você encontrou." Desde que todos os membros da equipe de desenvolvimento adiram a esta regra e limpam algo quando eles se deparam com uma bagunça, o código vai melhorar constantemente.
Os recursos do YAGNI (ou Você não vai precisar dele) são coisas que são implementadas quando esperamos que precisemos de algo no futuro, mesmo que não precisemos disso agora. Idealmente, devemos implementar a coisa mais simples que vai 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 borrão do código e o deslizamento de recursos.