Te voy a contar lo que le pasó hace años al equipo de Mr. Nobody (pseudónimo, ya sabes). Sin extenderme en detalles, pasó de una estructura clásica, de equipos especializados, jefes de proyecto tradicionales, ciclos de vida en cascada, etc., a una estructura ágil, equipos multifuncionales, más auto-organizados, etc., y, en lo que quería centrarme… paso a usar ciclos de vida iterativos e incrementales con iteraciones cortas.
Hasta ahí todo bien, pero nadie dijo que esto fuera fácil. Si eres de los que frecuenta el blog, recordarás que en varias ocasiones he escrito sobre los detalles del ciclo de vida iterativo e incremental, aunque es del 2012, te recomendaría leer aquí este post el ciclo de vida iterativo e incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental.
También muy resumidamente, en cada bloque de tiempo (por ejemplo, en cada Sprint), aparte de incrementar el valor del producto (por ejemplo, añadiéndole nuevas funcionalidades) se dedica tiempo a actividades que permitan mantener, o aumentar, la velocidad en los siguientes bloques de tiempo. Típicamente, estas actividades suelen ser refactorizaciones, eliminación de deda técnica (Yo que tú vigilaría la deuda técnica (y sus intereses) que puedes estar pagando durante mucho tiempo), etc.
En este punto aplica aquel viejo patrón de Scrum llamado “equipos que terminan antes aceleran más rápido”, que habla de no cargar al 100% a los equipos con objetivos de la parte incremental, dejando hueco para esa mejora de la velocidad, limpiezas, refactorizaciones, control de deuda técnica, etc.
El equipo de Mr. Nobody se aplicó aquello, dedicó concienzudamente una parte del tiempo de cada Sprint a tareas de «limpieza», luchando contra todos los que no creían que aquello fuera a funcionar… y que no funcionó. Los Sprint pasaban y la velocidad no se incrementaba, aquello parecía ir peor que antes de la «transformación» ágil… ¿qué estaba fallando?
Ahora viene el punto donde hay que dejarse las neuronas… ¿dónde compensa dedicar ese tiempo? ¿en qué refactorizaciones? ¿qué deuda técnica compensa eliminar?
La triste realidad, llegado este punto, es que muchos equipos no saben el mejor sitio al que dedicar ese preciado tiempo y en muchas ocasiones lo dedican a mejorar cosas, quitar deuda técnica, etc., pero, y sobre todo pasa en equipos que trabajan con código «legacy», como hay tanto que hacer no todas las mejoras tienen el mismo «retorno de inversión» y muchas veces ese tiempo cae en mejoras que no aumentan la velocidad.
Es decir, de 1000 sitios en los que quitar deuda técnica, el que peor está, por poner un ejemplo, no necesariamente es el que una vez arreglado nos mejora más la vida. Puede parecer difícil de entender pero es así, por ejemplo, la clase peor programada del mundo, que lleva ahí 7 años y cumple su función, y que nadie ha vuelto a tocar desde hace años, será muy fea, sí, pero arreglarla y dejarla bonita no necesariamente nos hará ir más rápido, porque, aun siendo tan fea, nadie la tocaba desde hace años, y dejarla bonita nos ayuda en el mantenimiento… pero ¿y si nadie toca va a tocar ya su código?
Esto que te estoy contado es un caso más del efecto Invertir en mejorar la clase con peores métricas de calidad puede ser un error, que te recomiendo leer para entender mejor este punto.
Es imposible que yo desde este post te pueda decir dónde es mejor que inviertas el valioso tiempo que te dejas en un Sprint para quitar deuda técnica, pero piensa una cosa, tienes que orientar ese tiempo a hacerte más veloz en próximos Sprints o a no frenarte. Y esto no es algo trivial. Mueve el cerebro.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Move your brain! Como muy bien comenta Javier Garzás, hay que medir donde se refactoriza. Los técnicos tienden/tendemos a querer cambiarlo todo en orden en el que nos lo vamos encontrando, y a veces, vale la pena mirar para otro lado y centrar esfuerzos en cambiar (primero) el código que se revisa frecuentemente. También creo que se puede aplicar la ley del Boyscout y mejorar aunque sea «un poco» la funcionalidad/legibilidad si entendemos que el tiempo aplicado a ello es asumible; ya se sabe que poco a poco…
En mi época en la universidad nos decían que un mal ingeniero de software con una herramienta CASE hacia software de mala calidad muy rápidamente.
Scrum, kamban, cascada… No es lo más importante. Lo importante es tener criterio para saber que es lo mejor en cada momento.