Estou tentando definir quais práticas ágeis vamos usar e estou tendo dificuldade para definir a lista de práticas recomendadas. Gostaria que minha lista fosse mais do ponto de vista técnico (o ângulo de visão do engenheiro) e defina como os engenheiros de SW devem abordar o desenvolvimento. A lista deve estar relacionada ao gerenciamento o menos possível.

Se isso importa, estamos programando em c ++.

É bastante fácil encontrar muitas práticas recomendadas, e esta é a lista que consegui formar até agora:

RefatoraçãoPequenos ciclos de liberaçãoPadrão de codificaçãoPropriedade coletivaMetáfora do sistemaJogo de aplainarEquipe inteiraReuniões diárias do ScrumProgramação em parProjeto Orientado a TestesDesenvolvimento orientado ao comportamentoIntegração contínuaRevisões de código e designPartes interessadas ativasDocumento atrasadoUso extensivo de padrões de design

Já estamos usando algumas das práticas da lista. Alguns não vamos usar.

Existem boas práticas ágeis que eu poderia adicionar à lista?

PS: posso adicionar uma pequena descrição das práticas, se solicitado.

EDITAR

Como eu disse, já estamos usando algumas práticas ágeis (principalmente as práticas que provam ser as melhores):

Integração contínua - essa é uma prática muito boa. Obter um feedback rápido sobre os check-ins mais recentes é muito útil. Ter um tempo de inatividade porque alguém quebrou uma compilação pode ser muito frustrante, especialmente se durar mais.Metáfora do sistema - ajuda pouco, porque ter nomes descritivos de classe e função ajuda a entender melhor o códigoCódigo padrão - criamos o padrão de codificação antes de entrar na codificação. Usar um estilo de código uniforme é bom, porque qualquer um pode pegar o código de outro e trabalhar nele como ele próprio.TDD - antes de iniciar a codificação, configuramos o ambiente para criar facilmente testes de unidade, mas somente até recentemente começamos a adotar os princípios de TDD. Eu pessoalmente tentei há vários anos, e não correu tão bem, mas agora eu amo isso. Infelizmente, nem todos os membros da equipe estão fazendo isso - apenas metade da equipe.Reuniões diárias do Scrum - tentamos reuniões diárias e elas não foram tão bem. Assim como no meu trabalho anterior, as reuniões diárias geralmente se transformam em discussões com mais de 30 minutos. Acho que perdemos o bom scrum master (ou líder, como é chamado?)Refatoração - fizemos a refatoração, mas apenas se alguém da equipe criar uma solicitação de alteração. Não fizemos isso de propósito: "Vamos sentar agora e reduzir nossa dívida técnica".Pequenos ciclos de lançamento - no momento, temos enormes ciclos de lançamento (6 meses) e, para o próximo lançamento, planejamos dividir o ciclo em 4 a 6 lançamentos internos.Revisões de código e design - fizemos a revisão inicial do design (há 5 anos) e algumas revisões de design de alguns subcomponentes menores durante esse período. Fizemos análises de código de algumas classesDocumente tarde - fizemos isso para este lançamento. Somente a documentação necessária significa escrever documentação cada vez mais divertida. Os desenvolvedores estão adorando :)Uso de padrões de design - já estamos usando padrões de design quando apropriado.

Devido à estrutura de nossa organização, não podemos usar outras práticas, mas como você pode ver, a lista é longa e você não pode escolher tudo. Além disso, agora somos apenas 4 desenvolvedores de SW, cada um mantendo aproximadamente 80 kLOC e trabalhando em novas coisas. Portanto, não podemos fazer, por exemplo, programação em pares ou propriedade coletiva.