El triángulo de hierro delimita la calidad final del producto software siempre y cuando las variables que lo componen den la oportunidad de que por lo menos el proyecto tenga alguna oportunidad.
Los enfoques clásicos de desarrollo están orientados al cumplimiento de una agenda, lo que no quita que en los enfoques ágiles se tengan en cuenta también esos parámetros, la diferencia se encuentra principalmente en el grado de flexibilidad que se aplica a los mismos.
Una de las variables es el alcance. Conforme se va avanzando en el proceso de desarrollo, el usuario se empezará a dar cuenta de especificaciones que ha realizado y que son incorrectas o mejorables, así como de nuevas funcionalidades que entienden que serán necesarias. El usuario presionará para que se incorporen todas, incluso en aquellos casos en los que se tenga que «tirar» desarrollo ya realizado.
Si no se gestiona adecuadamente el alcance y en consecuencias, las expectativas, del usuario, el proyecto correrá un riesgo importante. Si se dice a todo que sí y no se ajusta la carga de trabajo a la capacidad que se puede asumir: tanto en tiempo como en presupuesto, el producto se resentirá (reducción de la calidad) y las relaciones entre las partes también (desgaste como consecuencia de condiciones impuestas sin negociación, como consecuencia de expectativas insatisfechas, como consecuencia de la presión, etc…).
De tanto tensar la cuerda termina por romperse lo que puede dar lugar a un proyecto que se quede a medias en el que funcionalidades importantes se han quedado fuera o sin rematar, motivado principalmente por el hecho de no haberse realizado una adecuada gestión de prioridades, ya que el cliente daba por hecho de que todo lo que estaba pidiendo iba a entrar.
Este es un antipatrón para clientes y proveedores. Ambos pierden, los primeros por no buscar un equilibrio entre lo que se quiere y lo que se puede y los segundos por no saber o querer gestionar estas situaciones.
Jummp 