¿Sabías que muchos proyectos se entregan en tiempo, dentro del presupuesto y con el alcance prometido… y aún así se...
Leyes del Software
Las Leyes del Software: Duras Lecciones que Dieron Origen a la Agilidad
y por qué deberías prestarles atención¿Sabías que muchos proyectos se entregan en tiempo, dentro del presupuesto y con el alcance prometido… y aún así se consideran un fracaso?
Eso pasa porque no satisfacen al usuario. Y ese desfase es justo lo que muchas leyes del software llevan décadas advirtiéndonos.
Las Reglas No Escritas del Software
Mucho antes de que la agilidad se volviera popular, quienes desarrollaban software ya venían documentando las realidades duras del oficio.
No eran estándares oficiales ni procesos formales. Eran verdades empíricas, aprendidas a golpes y repetidas tantas veces que terminaron por reconocerse como leyes del software. Algunas de las más conocidas:
-
Ley de Conway – La arquitectura del software refleja la estructura de comunicación de la organización.
-
Ley de Ziv – Nunca se entienden completamente los requerimientos hasta que hay una versión funcionando.
-
Ley de Humphrey – La gente no sabe lo que quiere… hasta que ve algo que no quiere.
-
Ley de Brooks – Agregar más personas a un proyecto retrasado solo lo retrasa más.
No son frases para decorar presentaciones. Son reflejo de la realidad de trabajar en entornos complejos, donde lo que funciona en papel no necesariamente funciona en la práctica.
¿Por qué existen estas leyes?
Porque el desarrollo de software no es predecible como la ingeniería tradicional. El software:
-
Cambia constantemente.
-
Es altamente abstracto.
-
Se construye con reglas que nosotros mismos vamos inventando.
-
Está profundamente influido por la comunicación, el contexto y las expectativas humanas.
Y por eso, cada decisión tiene efectos secundarios. Las malas prácticas no solo retrasan el calendario: desgastan la confianza, consumen recursos y queman a los equipos.
¿Para qué sirven estas leyes?
En el día a día, nos ayudan a:
-
Evitar errores que ya han sido cometidos muchas veces.
-
Justificar buenas prácticas técnicas y de equipo.
-
Entender mejor el caos en el que a veces trabajamos.
-
Guiar a equipos y líderes en medio de la incertidumbre.
Y a nivel más estratégico, permiten:
-
Transferir conocimiento aprendido a pulso entre generaciones.
-
Evitar fallas sistémicas desde el diseño.
-
Justificar por qué las “buenas prácticas” no son opcionales… son de supervivencia.
“Los principios ágiles son la expresión más completa que se ha logrado de las leyes del software.”
Cuando el management las ignora… se nota
Según el CHAOS Report 2015:
-
Solo el 11% de los proyectos gestionados con enfoque Waterfall fueron exitosos.
-
El 29% fracasaron completamente (cancelados o sin entregar nada útil).
-
El 60% restante tuvo sobrecostos, retrasos o incumplimiento de alcance.
¿La razón? El management tradicional actúa como si el software fuera un sistema simple o complicado, cuando en realidad es complejo. Intentan controlarlo, cuando en realidad deberían aprender a colaborar con la incertidumbre.
El punto de inflexión: los 12 principios que lo cambiaron todo
En 2001, después de ver cómo estas leyes se violaban una y otra vez, un grupo de profesionales se reunió para codificar una especie de antídoto.
Así nació el Manifiesto Ágil… y, más importante aún, sus 12 principios.
No vinieron de la teoría. Vinieron de la práctica.
De Conway, Ziv, Humphrey, Brooks… y de miles de fracasos sin nombre.
Los 12 principios y los 4 valores son un compendio destilado de observaciones del campo real. Reconocen que:
-
El cambio es constante.
-
El valor importa más que el alcance.
-
El software funcionando vale más que los planes detallados.
-
La colaboración supera la negociación de contratos.
-
La reflexión y la adaptación no son negociables.
Y eso es solo una parte.
Cada principio encapsula capas de sabiduría acumulada a partir de la experiencia directa con la complejidad.
Conclusion
Las leyes del software son brújulas, no mapas.
No te dicen paso a paso qué hacer, pero sí te avisan dónde están los pantanos.
En un entorno donde la incertidumbre es la norma y los planes perfectos son una ilusión, estas leyes y principios nos ayudan a tomar mejores decisiones, con humildad, claridad e intención.
Así que no: la agilidad no inventó nada nuevo.
Simplemente escuchó las leyes que el mundo del software llevaba décadas gritando.
No son reglas para seguir al pie de la letra, sino señales que nos ayudan a navegar la incertidumbre con más humanidad y sentido.
Después de ver que es un MVP, por qué no mejor vemos ¿Qué es un MVP?
Sí, trataremos de aclararlo un poco más.
Un MVP es nuestro producto, aún no está terminado, pero es una versión mínima pero funcional que ya realiza el objetivo que perseguimos con él. (no perder de vista la V en MVP)
El ejemplo clásico que verán en todos lados, (aunque se puede hacer con cualquier producto) es que tenemos un producto nuevo, una especie de vehículo para transportarnos de un lugar cercano a otro. Se me antoja llamarlo automóvil. Innovador, donde no tenga la necesidad de caminar. La idea es que pueda tener radio y aire acondicionado, que tenga lucecitas y esté forrado en piel, a lo mejor que venga en 43 diferentes colores radiantes y que sea descapotable.
¿Podría decir que una llanta es parte de mi producto? Sí, inobjetablemente.
¿Es mínimo? Sí, definitivamente
¿Es viable? No, no cumple con el primer propósito
Mi proyecto automóvil tiene muchas características, sin embargo. Tiene un primer propósito único: llevarme de un lado a otro sin necesidad de caminar.
Es entonces que la opción de algo mínimo y viable es la opción de una tabla con ruedas, que básicamente es una patineta, que cumple con la definición de MVP. Que ya puede transportarme, evitar que camine y si tengo 17 años me va a encantar.
Por favor tomémoslo como es, un ejemplo. Yo también veo algunos detalles, pero si quieren discutirlo, escríbanme.
Después de este brevísimo pero ilustrativo ejemplo veamos otros puntos de vista.
El MVP como método científico
Eric Ries(3) Menciona que se puede ver a través del método científico. Y seamos honestos, ese argumento sí que podría ser definitivo.
De manera muy general, el método científico se resume en los siguientes pasos: