Agile vs. Cascada (Parte 3 de 5). Costo, funcionalidad y tiempo
Le damos la bienvenida a la parte 3 de Agile vs Cascada. Nuestra primera parte presentó el Modelo de Cascada y la segunda presentó el modelo Agile. En esta parte describiré la relación entre el costo, funcionalidad y aspectos de tiempo de la ejecución de un proyecto.
Si no ha leído la parte 1, la puede encontrar aquí.
Si no ha leído la parte 2, la puede encontrar aquí.
¡Continuemos!
Costo, funcionalidad y tiempo
Como cualquier otra operación humana, los proyectos necesitan se realizados y entregados bajo ciertas restricciones. Tradicionalmente, estas restricciones han sido listadas como costo, funcionalidad y tiempo. Estas también son referidas como el Triángulo de Administración de Proyectos (PMT), donde cada lado representa una restricción. Un lado del triángulo no puede ser cambiado sin afectar los demás. Esta relación se ilustra a continuación.
La restricción de tiempo/horario se refiere a la cantidad de tiempo disponible para completar un proyecto. La restricción de costo se refiere al presupuesto disponible para el proyecto. La restricción de funcionalidad/alcance se refiere a lo que debe hacerse para llegar al resultado final del proyecto. Estas tres restricciones suelen ser restricciones competitivas: aumentar la funcionalidad típicamente significa costos y tiempos incrementados, y un presupuesto ajustado podría significar mayor tiempo y un alcance reducido.
Dependiendo en el tipo de empresa/proyecto en el que está trabajando, dos de estas restricciones serán las más importantes. Si es un precio fijo, entonces el costo del proyecto es una restricción que no podrá ser cambiada. En ese caso, la funcionalidad o el tiempo serán las que sufrirán.
En otras palabras, usted tiene 3 opciones:
- Desarrollar un producto rápidamente y con gran calidad o muchas funcionalidades, pero a un alto precio.
- Desarrollar un producto rápidamente y a bajo costo, pero sin muchas funcionalidades o calidad.
- Desarrollar un producto de alta calidad y muchas funcionalidades y a bajo costo, pero con un tiempo relativamente más largo.
La calidad no es una parte del PMT, pero es el objetivo final de cada entrega. Por lo tanto, el PMT implica calidad.
Muchos gestores de proyectos están bajo la noción de que una alta calidad implica altos costos, lo que de cierta manera es verdad, a menos que la cantidad de funcionalidades sea el parámetro que sufre. En todos los casos, usar recursos de baja calidad para cumplir los tiempos de un proyecto no lleva al éxito general del proyecto.
Al igual que con el alcance, la calidad también debe ser una parte importante para el proyecto.
En Agile, la funcionalidad o costo son los que usualmente sufren. El tiempo es usualmente un factor menor debido a que las iteraciones continúan hasta que el equipo/proyecto/cliente cree que el producto está listo para ir al mercado. Es más acerca de continuamente sacar funcionalidades para que el proyecto pueda detenerse en cualquier momento y aun así se pueda tener un producto terminado.
Este es el final de la tercera parte. Espero haya sido esclarecedora y usted siga pendiente.
Vuelva y lea la parte 4: Agile vs. Cascada. Por Qué la Cascada Puede ser el mejor enfoque.
