Lista de mejores prácticas ágiles [cerrado]

Estoy tratando de definir qué prácticas ágiles vamos a utilizar, y tengo dificultades para definir la lista de mejores prácticas ágiles. Me gustaría que mi lista sea más desde un punto de vista técnico (el ángulo de visión del ingeniero), y debería definir cómo los ingenieros de SW deben abordar el desarrollo. La lista debe estar relacionada con la gestión lo menos posible.

Si es importante, estamos programando en c ++.

Es bastante fácil encontrar muchas mejores prácticas, y esta es la lista que logré formar hasta ahora:

RefactorizaciónPequeños ciclos de liberaciónEstándar de codificaciónPropiedad colectivaMetáfora del sistemaJuego de planeamientoTodo el equipoScrum reuniones diariasProgramación en parejaDiseño conducido por pruebaDesarrollo impulsado por el comportamiento.Integración continuaCódigo y revisiones de diseñoInteresados activosDocumento tardeUso extensivo de patrones de diseño.

Ya estamos utilizando algunas de las prácticas de la lista. Algunos no los vamos a utilizar.

¿Hay buenas prácticas ágiles que podría agregar a la lista?

PD: Puedo agregar una pequeña descripción de las prácticas, si así lo solicita.

EDITAR

Como dije, ya estamos usando algunas prácticas ágiles (principalmente las prácticas que demuestran ser las mejores):

Integración continua: esta es una muy buena práctica. Obtener comentarios rápidos sobre los últimos registros es muy útil. Tener un tiempo de inactividad porque alguien rompió una construcción puede ser muy frustrante, especialmente si dura más.Metáfora del sistema: ayuda poco, porque tener nombres descriptivos de clase y función ayuda a comprender mejor el códigoEstándar de código: creamos el estándar de codificación antes de entrar en la codificación. Usar un estilo de código uniforme es bueno, porque cualquiera puede tomar el código de otro y trabajar en él como si fuera propio.TDD: antes de comenzar a codificar, configuramos el entorno para crear fácilmente pruebas unitarias, pero solo hasta hace poco comenzamos a adoptar los principios de TDD. Personalmente lo intenté hace varios años, y no me fue tan bien, pero ahora me encanta. Desafortunadamente, no todos los miembros del equipo lo están haciendo, solo la mitad del equipo.Reuniones diarias de Scrum: intentamos reuniones diarias y no funcionaron tan bien. Además de en mi trabajo anterior, las reuniones diarias generalmente se convierten en discusiones de más de 30 minutos. Supongo que nos perdimos un buen scrum master (o líder, ¿cómo se llama?)Refactorización: realizamos una refactorización, pero solo si alguien del equipo crea una solicitud de cambio. No lo hicimos a propósito: "Vamos a sentarnos ahora y reducir nuestra deuda técnica".Pequeños ciclos de lanzamiento: en este momento tenemos enormes ciclos de lanzamiento (6 meses), y para el próximo lanzamiento estamos planeando dividir el ciclo en 4-6 lanzamientos internos.Revisiones de código y diseño: realizamos la revisión de diseño inicial (como hace 5 años) y pocas revisiones de diseños de algunos subcomponentes menores durante este período. Hicimos revisiones de código de algunas clases.Documento tarde: lo hicimos para este lanzamiento. Solo la documentación requerida significa escribir documentación con una codificación cada vez menos divertida. Los desarrolladores lo adoran :)Uso de patrones de diseño: ya estamos utilizando patrones de diseño cuando corresponde.

Debido a la estructura de nuestra organización, no podemos utilizar otras prácticas, pero como puede ver, la lista es larga y no puede elegir todo. Además, ahora solo somos 4 desarrolladores de software, cada uno de los cuales mantiene aproximadamente 80 kLOC y trabaja en cosas nuevas. Por lo tanto, no podemos hacer, por ejemplo, programación de pares o propiedad colectiva.