¿Cómo gestionar en un marco ágil la mantenibilidad del software cuando hay rotación de miembros en el equipo?

Esta pregunta viene de un alumno que tiene un equipo dedicado al mantenimiento de un producto que se dedica a incidencias y pequeñas mejoras, equipo que tiene rotación y la compañía parte de la idea de que el mantenimiento no debe depender de una persona, debe poder hacerla cualquier persona que se vaya incorporando en el equipo.

La única ley de la naturaleza que aplica a la informática es la entropía, si no se dedican recursos, y no me refiero sólo a personas, específicamente a la mantenibilidad del producto, y este está pensado para operar a largo plazo, lo más probable es que se vuelva caótico. El problema de no tener un equipo propietario a cargo del producto es que la persona nueva no tiene sentimiento de propiedad de un código que no es suyo, y la persona que lo escribió ya no está, y si tuviera que hacer una modificación habrá perdido el sentimiento de propiedad porque ya no es suyo, su código original lo han modificado otros.

Hay que hacer gestión de cambio de personas:

Taller de transmisión de conocimiento facilitado por el coach ágil

• Más que nunca es necesario un Scrum Master o un coach ágil que forme y acompañe a los nuevos miembros en la incorporación al equipo, y al equipo a integrarlos.
• Cuidando del bus factor para mantener la base de conocimiento en todo el equipo. Se pueden realizar talleres de transmisión de conocimiento entre la gente del equipo, programación por parejas, actividades medio lúdicas de team-buidling... con cada persona que rote, con cada salida y cada incorporación, hay que hacer acciones que mantengan la motivación del equipo.

Hay que invertir en todo aquello que facilite la mantenibilidad:

Aplicar técnicas de desarrollo ágil
- cortesía de Raúl Herranz

• Tener una documentación del diseño del producto mínima y suficiente, y sobre todo mantenible. Crear una base de patrones de desarrollo y documentación en el código, desde dentro y para el equipo. Algo que sea fácil de hacer y usar, por ejemplo una wiki. Para ello hay que crear cultura wiki, el equipo ha sentir que la wiki es una herramienta para ellos, y que se sientan proactivos a enriquecerla continuamente.
• Refactorización frecuente, hacer que el equipo en curso revise el código crítico y refactorice si lo cree conveniente. Así se consigue sentimiento de propiedad mientras el equipo sea estable.
• Stop-and-fix, para los workarounds y problemas que surjan parar completamente el desarrollo, para que el equipo resuelva completamente la causa raíz y luego, una vez resuelta, siga desarrollando. Evitar caer en paliativos y en chapuzas, futuros miembros del equipo las desconocerán y el problema se convertirá en una bola de nieve.
• Si se adquiere deuda técnica, gestionarla, apuntar cada deuda en un post-it y dejarlo bien visible en algún área del scrumboard. De tanto en tanto hay que abordar una de estas tareas. 
• Situar un banner bien grande y visible con mensajes como "NO QUEREMOS CODIGO BASURA" y hacer partícipe al equipo en la motivación de mejorar el código cada vez que les parezca que algo no esté suficientemente bien.
• Implantar integración continua y pruebas automatizadas, ir a máximos, a BDD.

Todo esto sin duda tiene costes, pero no hacer nada tiene un coste mucho mayor. He vivido equipos que adquieren deuda técnica y se acaban ahogando en ella simplemente porque el software sobre el que trabajan está lleno de chapuzas y workarounds. En la naturaleza del ser humano está el síndrome de la ventana rota, si entramos en una habitación con una ventana rota no nos importa que se rompan otras cosas. Un vidrio roto transmite una idea de deterioro, desinterés, despreocupación que va destruyendo los códigos de convivencia, tales como la ausencia de ley, de normas, de reglas, dejando la sensación de que todo vale nada. Lo mismo pasa con el software, cuando te encuentras código basura generas código basura...

Quiero dar mi agradecimiento a los asistentes al curso que me dieron permiso para utilizar la foto del taller de transmisión de conocimiento, entre ellos Ovidio, Marcos, Antonio, Daniel y Patricia.