Hace «miles de años» (concretamente en el año 1996), antes incluso de la aparición de la palabra Ágil en lo nuestro, dos personas poco populares y que casi nadie conoce, Hadar Ziv y Debra J. Richardson, publicaron un artículo titulado «The uncertainty principle«, al que ya había hecho mención en algún antiguo post (y que hoy he vuelto a él, porque estaba preparando una cosa para la próxima edición del curso de Agilidad Avanzada de junio).
En aquel artículo, los autores, exponían un tema que, por más de 25 años que hayan pasado, el tiempo nos dice que sigue sin entenderse… la incertidumbre en el proceso de crear software es innata al software. Y por eso los intentos de predictibilidad, la gestión de proyectos clásica, los cascadas, etc., fallan tanto.
Los autores exponían, concretamente, cuatro dominios donde esa incertidumbre es más evidente: los requisitos, la transición de los requisitos al diseño y el código, en la re-ingeniería y en la reutilización.
Y añadían a lo anterior, que la incertidumbre tenía fuentes diversas, pero concretamente había 3 causas destacadas: el dominio del problema (modelamos mundo real y el mundo real está lleno de incertidumbre), el dominio de la solución (por la complejidad de la tecnología) y la participación de personas en el proceso (impredecibles de por si).
También citan, como tantos (de hecho en este blog tienes muchos post sobre el tema, como este) el error de la míticas conferencias de los años 60, organizadas por la OTAN, en las que se intentó comparar la antiguamente llamada ingeniería del software a las ingenierías clásicas, mucho más predecibles en el proceso de creación, y que se asientan sobre leyes y principios que no aplican al software.
Para los que buscáis referencias robustas, de algo que realmente es obvio, el artículo también hace una demostración de la incertidumbre con probabilidades Bayesianas, en la que aquí no voy a entrar, porque se sale un poco del objetivo de lectura rápida que tienen los post.
Espero que con esta referencia os apoye en algo obvio, estudiado desde hace muchos años, y que es, una vez más, que crear software no es como crear coches o casas, por mucho que los modelos de gestión de proyectos tradicionales se empeñen en ello (casi 30 años después)
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024