C
on el tiempo, uno se da cada vez más cuenta de la gran cantidad de mitos arraigados que se pueden encontrar en esta nuestra profesión del desarrollo / ingeniería del software. Tantos que hasta da para una serie post.
Por empezar por alguno, uno de estos mitos arraigados en ciertos grupos y colectivos es aquel que habla de que “los procesos implican ciclos de vida en cascada”. Mito que también podemos encontrar sustituyendo la palabra “procesos” por algún modelo de procesos concreto, principalmente CMMI o ISO 15504 / ISO 12207. “No implantamos CMMI porque implica ciclo de vida en cascada”. “ISO 15504 / ISO 12207 no funciona porque trabajamos de manera ágil, iterativa, y el cv en cascada no funciona”.
Para comprobar si hay veracidad detrás de este mito, y ya que “aparentemente” los procesos implican tanto al ciclo de vida en cascada, fui al documento que describe uno de los modelos de procesos más famoso, el CMMI, e hice una búsqueda por la palabra “waterfall”, para contar las apariciones de la misma en el documento.
Y sí, efectivamente aparece… pero una sola vez. Algo tan aparentemente importante para implantar procesos, solo aparece una vez en las 482 páginas. Y como ejemplo de ciclo de vida, y junto al iterativo y el incremental.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Me imagino que con todos los inconvenientes que tiene el ciclo de vida en cascada alguna «ventaja» tendrá. Si no, esta discusión sólo se tendría en los foros de historia de la informática ;-).
Y efectivamente, el ciclo en cascada tiene al menos una ventaja aparente, y es que es un ciclo de vida que está ligado al proceso productivo clásico, que tan bien entienden los gestores y directivos de la vieja escuela. Y que por desgracia se resisten a abandonar.
Sin ir más lejos en mi empresa hemos implementado el nivel 2 de CMMI basándonos en un modelo iterativo tipo RUP.
@vellebue: No debemos olvidar que hay organizaciones que lo utilizan Y LES VA BIEN, sí. Yo lo he visto, doy fe. Organizaciones con requisitos estables, que típicamente hacen software empotrado, sistemas de control, software militar, etc. En este mundo del software hay mucho tipo de software a construir, y no todo es blanco negro
Saludos Vellbue!
@Eduardo Riol: …y si os funciona pues perfecto. Esa es entonces para vosotros la mejor opción. Aquí lo que vale es lo que funciona y ayuda al negocio.
@Eduardo Riol: No sabía de alguien a quien le funcionase el RUP 😉
@Fern: Hubo que hacer adaptaciones, por eso lo de «tipo» RUP 🙂
@jgarzas Totalmente de acuerdo. De hecho el único escenario en el que el ciclo de desarrollo en cascada tiene alguna posibilidad es en escenarios en los que el entorno en el que se plantea el sistema software es un entorno cerrado por definición.
El principal problema es que se tiende a abusar del modelo en cascada porque es muy «cómodo» desde el punto de vista contractual y de alto nivel de gestión, y se termina usando en escenarios en los que el cliente no tiene claro qué es lo que necesita, hay que ir refinando y corrigiendo sobre la marcha, y en cuanto empiezan a llegar los cambios inevitablemente salta por los aires.
Pingback: No es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO - Javier Garzás, sobre calidad software y otros temas relacionados
interesante post. seria chevere que subas el link del documento que comparaste para leerlo. saludos