Planes cambiantes… productos preparados para el cambio, pero con cuidado

Habrá decenas de maneras de definir y explicar qué significa trabajar de manera ágil, que si contando el manifiesto ágil, que si tirando de algún framework más reciente, como el «modern agile» o el «heart of agile» y sus cuatro partes, etc. Yo mismo te lo habré contado desde muchos puntos y maneras distintas. Bueno, y de entre todas ellas, hay una, de la que seguro también te habré hablado, que muestra las principales diferencias entre la visión tradicional y la ágil, comparando qué anteponen cada una de ellas.
Una característica de la visión tradicional es que antepone los planes predictivos con objeto de una vez lanzados no ser modificados, frente a la visión ágil, que habla de planes adaptativos. Sólo la línea anterior da para escribir un libro, y de ahí entraríamos en el papel de la estimación, del #noestimaes, y decenas de cosas más que no son el objetivo de hoy.
Una segunda gran característica de la visión tradicional es que antepone los procesos (y proyectos) a las personas, frente a la visión ágil, que pone a las personas como lo primero. Igualmente, la frase anterior daría para mucho hablar y escribir que si peopleware, management 3.0, #noprojects y hasta para tirarse un rato dibujando como en aquel en vídeo y dibujando… Gestión de Proyectos vs Equipos.
Lo anterior, así dicho, puede parecer simple de entender, pero, ya sabes… no lo es. Y el lado oscuro muchas veces es muy difícil de detectar. Y quería hablarte de algo relativo al lado oscuro, que suele salir cada vez que expongo lo de «planes cambiantes». La cosa es que «planes cambiantes», adaptables, requieren productos, software, o lo que sea que sea tu producto, preparados para el cambio… y ahí está, ahí viene el lío, el reverso tenebroso.
Lo de preparar productos para el cambio se parece mucho a lo de ojo con frenar la velocidad a corto plazo por, supuestamente, ganarla a largo plazo, se dice rápido pero requiere de muchas neuronas. ¿Dónde está el problema? Que preparar para el cambio puede incurrir en algo poco Lean y poco Ágil… desperdicio.
Recuerdo que en uno de mis primeros trabajos de desarrollo había que hacer la siguiente versión del principal producto de aquella empresa, y se planteó que para reducir el coste de los futuros cambios, para prepararse para el cambio, lo mejor era hacer un meta-meta diseño de la BBDD. Si has estado en una de estas seguro que te suena, en vez de hacer el modelo, realmente hacer un modelo de modelos para poder hacer cambios rápidamente… cambios que nunca se llegaron a pedir y que, por la complejidad de entender el modelo, no eran nada rápidos.
Es lo mismo que paso mucho en los 90 cuando se sobre usaron patrones de diseño para aumentar la velocidad de posibles, futuros, cambios, pero que se acabó con el efecto contrario, al aumentar el número de cases y la dificultad de entender el sistema.
Así que el paso entre preparar para el cambio y hacer cosas que no van a valer para nada (desperdicio) es muy pequeño.
Por eso que hay varias prácticas ágiles, muy de eXtreme Programming, que alertan de ello, como el YAGNI (You Aren’t Gonna Need It), “No lo vas a necesitar”, haz las cosas sólo cuando realmente las necesites, el KISS (Keep It Simple, Stupid) o retrasa las decisiones hasta lo más tarde posible.
Quizá la única prescripción ampliamente recomendada para «preparar para el cambio» es el uso máximo de pruebas unitarias, necesarias para posibles refactorizaciones y que llevan a mejores diseños. El resto… ojo y con cuidado y con cabeza.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba