Todos los proyectos de software ágil tienen objetivos: qué es lo que el proyecto debe entregar, cuándo se debe entregar y con qué presupuesto. Sin embargo, la gestión de estas tres limitaciones puede ser un complejo acto de malabarismo. Así que tomemos un ejemplo del triángulo de hierro de planificación de hace décadas y aprendamos cómo el equilibrio de las diferentes variables puede ayudar a los equipos de software ágil a alcanzar el nirvana de la gestión de proyectos ágiles.
El triángulo de hierro tradicional
La gestión de proyectos de triángulo de hierro tiene unas restricciones que se consideran "de hierro" porque no se puede cambiar una de ellas sin que afecte a las demás. La gestión de proyectos de triángulo de hierro original, propuesta por el Dr. Martin Barnes en 1969, sigue un enfoque en cascada para el desarrollo de productos: el alcance es fijo y los recursos y el tiempo son variables. Para un equipo de software, esto significaría que los equipos comienzan un proyecto definiendo los requisitos del producto para determinar el alcance del proyecto (una lista de elementos de trabajo). Los recursos y la planificación son variables y se estiman en función del alcance fijo.
- El alcance es el trabajo que queda por hacer, como funciones o funcionalidades, para entregar un producto que funcione.
- Los recursos incluyen el presupuesto y a los miembros del equipo que trabajan para la entrega y la ejecución.
- El tiempo es el momento en que los equipos lanzarán al mercado, como publicaciones e hitos.
El propósito de la gestión de proyectos de triángulo de hierro es dar a los equipos de productos la información necesaria para hacer compensaciones que ayuden al negocio. Por ejemplo, si los equipos se enfrentan a un alcance fijo, pueden estar a mitad de un proyecto y darse cuenta de que no llegarán a la fecha de publicación. Las únicas variables con las que pueden jugar son: 1) Tiempo: pueden aceptar una fecha de publicación posterior o 2) Recursos: pueden añadir a algunas personas más al proyecto, lo que aumentará los costes. A medida que el desarrollo de software ha evolucionado en el siglo XXI, la necesidad de una mejor colaboración y la capacidad de responder rápidamente a los comentarios de los clientes se ha hecho fundamental, y para ello se creó la metodología ágil.
Asignación del triángulo de hierro a la metodología ágil
Si tu equipo practica la gestión de proyectos en cascada o no hace mucho que trabajáis con el desarrollo ágil, lo importante es recordar la diferencia entre lo que es fijo y lo que es estimado. A diferencia del desarrollo en cascada, los proyectos ágiles tienen una planificación y recursos fijos, mientras que el alcance varía. Y, aunque en el desarrollo ágil el alcance de un proyecto puede cambiar, los equipos se comprometen a iteraciones de trabajo fijas: sprints, si utilizas un marco scrum, y límites de trabajo en curso, si utilizas un marco kanban. También es una buena práctica mantener fijos los equipos durante todo el proceso de desarrollo. Al mantener a los mismos equipos para un producto o proyecto, estos se vuelven más eficaces gracias a la confianza y la continuidad desarrolladas.
La idea de alcance es la misma en el desarrollo ágil: qué software compilar y entregar. Sin embargo, la metodología ágil se centra en los requisitos de alto nivel en lugar de tratar de incluir requisitos profundos y detallados por adelantado. El gestor de productos gestiona y prepara (prioriza) el alcance de un proyecto de forma periódica en una herramienta como Jira. El gestor de productos decide qué trabajo debe realizarse en el siguiente sprint basándose en comentarios sobre metodología ágil cualitativos y cuantitativos procedentes de diversos canales (condiciones del mercado, comentarios de los clientes, concursos, etc.). Y, dado que los recursos y el tiempo son fijos, es más fácil para los equipos de desarrollo reaccionar a los cambios del mercado y entregar valor a los clientes más rápidamente. Esta transparencia de las limitaciones mantiene la honestidad de los equipos en relación con una cadencia de publicación coherente y rápida, la cual es un factor clave del desarrollo ágil. Además, al mirar los proyectos a través de la lente del triángulo de hierro, los equipos son capaces de adaptarse sin abandonar un plan.
Planificación ágil a largo plazo y gestión de proyectos de triángulo de hierro
A medida que los proyectos se hacen más grandes, se necesitan más equipos y el recuadro de tiempo se alarga. Por lo tanto, la noción de fijar los recursos y el tiempo, aunque el alcance varíe, no es un enfoque válido para todos los proyectos ágiles. La planificación ágil a largo plazo requiere un triángulo de hierro más flexible que permita a los equipos planificar con antelación y garantice que se están cumpliendo los objetivos de negocio. Piensa, por ejemplo, en el movimiento Lean Startup y en la noción de producto viable mínimo (MVP, del inglés "Minimum Viable Product"). Un MVP, por definición, es un pequeño conjunto de funciones (alcance) que ofrece valor al cliente. Para llegar a ese MVP, los equipos podrían tener que ceñirse a un alcance fijo (el número de funciones) siendo el tiempo su único valor variable (por ejemplo, no se puede publicar sin determinadas funciones, por lo que la fecha de publicación se retrasa). Solo después de lanzar el MVP, los equipos cambian a un alcance variable.
Con independencia de las diferencias entre el desarrollo en cascada y el desarrollo ágil, cuando se utiliza el triángulo de hierro, no hay un camino correcto o equivocado. El triángulo está ahí para ayudarte a tomar las mejores decisiones y a hacer concesiones para alcanzar tus objetivos empresariales. Una herramienta como los cronogramas visualiza los componentes básicos de un plan (alcance, personas y tiempo) para ayudar a los equipos a planificar en tiempo real. Puedes jugar fácilmente con el alcance, los equipos y el tiempo para planificar tu próxima publicación de producto, utilizando los datos existentes del equipo en Jira.