Escribiendo el post de ayer, me di cuenta de que entre los más de 2100 post que hay en este blog… no hay ninguno (o no lo he encontrado, y eso que he buscado bien) sobre las curvas del coste del cambio.
Las curvas del coste del cambio son uno de esos clasicazos en la «antigua» ingeniería del software (¿Dónde quedó la ingeniería software? Y porque vas a escuchar la palabra Agilidad muchos años) y también en Agilidad, aunque, obviamente, con distintos enfoques según quien las interprete.
La propuesta de que el coste del cambio crece exponencialmente cuando empieza a programarse
De las distintas propuestas de curvas del coste del cambio, que viene a ser lo que hipotéticamente costaría hacer un cambio en el software según avanza el tiempo, de las más antiguas y, quizá, la más influyente, es la de Boehm, la que propuso en un libro muy viejuno, del 81, un clásico en ingeniería el software, que ya está descatalogado, el Software Engineering Economics (un libro muy denso de leer, aviso).
Aquí te dejo esa curva, y verás que el dibujo tiene mucha pinta (bueno, es que lo es) de cascada…
La anterior ha sido usada desde hace muchos años para apoyar los ciclos de vida en cascada, prescriptivos, etc., que intentan evitar el cambio en las últimas «fases» (te dejo post Gestionas proyectos por fases… o por tareas) del desarrollo.
Que todo esté bien cerrado en fases «de papel», en requisitos y diseño, para que no se tenga que cambiar nada de lo previsto en desarrollo. Cosa que se ha intentado (algunos aún lo intentan) millones de veces con bastantes malos resultados.
De la anterior gráfica se deduce que el coste del cambio crece exponencial, y de ahí que hay que evitar hacer cambios en las fases de desarrollo y test, lo cual, eso de «no hacer cambios», ya no huele muy ágil, cuando una de las premisas ágiles es… bienvenido el cambio, «incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente».
La propuesta de que la curva podría terminar plana
En el extremo opuesto a la anterior curva tenemos la propuesta que hizo Kent Beck, años después, en Extreme Programming Explained: Embrace Change: Embracing Change, donde proponía que la famosa curva del coste del cambio podía ser plana (abajo tienes una foto de esa curva, sacada de mi copia del libro).
Kent Beck proponía que, si bien puede ser más económico solucionar un error antes de tirar una línea de código, una vez que comienza el desarrollo en coste del cambio, ya con código… es constante.
¿Cuál es la verdadera curva?
Pues no se sabe, porque los dos enfoques anteriores no dejan de tener su toque teórico e ideal, no hay validaciones aplicables a todos los casos, cada caso es diferente, etc.
Claramente, la de Boehm es una propuesta antigua y peligrosa, ya que lleva a pensar en cerrar requisitos, y a justificar los ciclos en cascada y la predictibilidad frente al cambio, algo obsoleto hoy en día.
Pero la de Beck se basa en una premisa que no es algo trivial… asume que el desarrollo está haciendo uso de buenas prácticas técnicas, todas aquellas… «muy eXtreme Programming», como TDD, integración continua, etc.
Y si nos vamos sistemas legacy, que es lo que más nos podemos encontrar, independientemente, y dejando atrás esas «fases» de requisitos y diseño, si que algo de exponencial (o subida, no sé si exponencial) puede tener el cambio según pasa el tiempo, ya que, sin pruebas unitarias, buen control de versiones, etc., nos costará más cambiar viejas líneas de código que… las que hicimos ayer.
Cockburn planteó una tercera propuesta, más cercana a la de Beck pero que, en vez de ser plana, propone que cuando ha pasado mucho tiempo el coste del cambio sube, no exponencial, pero sube.
No es cuestión, no creo que sea posible, sacar la curva definitiva, pero sí que reflexiones sobre ello, si que pienses cómo las buenas prácticas técnicas, quizá no te dejen la curva plana pero… si que evitarán que termine en algo cercano a lo exponencial.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Siempre hemos oído que cuanto más tarde se encuentra un defecto o se quiere cambiar algo más caro resulta arreglarlo.
Y yo la verdad creo que es una buena aproximación, ya que cuanto más tiempo pasa más se puede haber desarrollado y avanzado sobre esa implementación y más lío es revertirla … Pero claro… Cómo bien comentas, depende mucho de cada caso…
Yo desde luego, sin tener mucha experiencia en metodologías ágiles creo que una curva plana es poco realista…
Gran artículo. Gracias.
Lo de boch lo conocía como la catarata de mizuno (creo que es del 94 o por ahí) donde daba expotencialidad entre cada etapa del sldc.
Pues yo uso esta gráfica en vez de para evaluar el costo del cambio, para evaluar el costo de detectar errores, ya que dentro de cada sprint/iteración se pasa de alguna forma por estas fases o similares ( no precisamente una después de la otra con antes, pero se pasa por ahí).
Por ejemplo si se detecta el error desde que estás escribiendo la historia de usuario, o desde que estás diseñando (TDD) el costo es mucho menor a que si el error lo encuentra el cliente en producción.
El problema es que cualquiera de los dos enfoques es erróneo. Un sistema que construyes de cero necesita unos mínimos requisitos ‘cerrados’, ‘acordados’ o ‘asumidos’. Con eso se define una estrategia, que por muy buena técnicamente que sea y que permita modificaciones, ampliaciones y demás, siempre habrá cambios que impliquen rediseñar la propia base porque no se puede desarrollar de forma tan genérica sin pagar el precio de la complejidad ‘por si acaso’ y de la ineficiencia. Por tanto un sistema bien diseñado posiblemente soporte un buen número de modificaciones y ampliaciones cuyo coste sería más o menos constante e idealmente bajo, pero si es un cambio ‘de base’ se disparará el coste ya que implicaría rehacer el sistema.
De hecho, por eso se mantienen muchos sistemas ‘legacy’, porque mal que bien, pueden seguir aguantando modificaciones, más o menos costosas, pero que se sabe lo que cuestan y no se arriesgan a montar un sistema nuevo con la promesa de que futuras ampliaciones serán menos costosas. Ahí estamos muchos lidiando con renovar sistemas compatibilizando con el código legacy para facilitar esa transición sin hacer ‘de golpe’ el sistema nuevo de cero.