Gestión Ágil del Portafolio de Proyectos

La versión original de este articulo fue publicada en la edición de enero 2009 del Cutter IT Journal. La versión que presentamos aquí fue traducida y editada por SG, y publicada con el permiso de Cutter Consortium México.

Los métodos ágiles han dejado de ser un movimiento de unos cuantos radicales, y hoy en día son un fenómeno generalizado a lo largo de la industria de software. Sin embargo, a pesar de las victorias obtenidas a nivel de proyectos individuales, son raros los casos de organizaciones grandes que han logrado adoptar ágil a nivel organizacional y no tan solo en proyectos individuales.

El principal reto que enfrentan los métodos ágiles al tratar de escalar a nivel organizacional es el de poder funcionar en conjunto con prácticas de gobierno corporativo de TI. En particular, la gestión del portafolio de proyectos (project portfolio management) pareciera contraponerse con los métodos ágiles. En realidad esta no es una incompatibilidad de fondo, simplemente es necesario que la gestión de portafolio de proyectos evolucione hacia un enfoque adaptativo, de modo que facilite en lugar de estorbar a los proyectos ágiles.

En la mayoría de las organizaciones, las técnicas utilizadas para gestionar los programas y portafolios siguen siendo predictivas y dirigidas por planes. Se basan en ciclos de presupuesto anuales y planeación de la capacidad a largo plazo. No es sorpresa entonces que a pesar de haber adoptado métodos ágiles a nivel de sus proyectos, la mayoría de las organizaciones todavía no aprovechen los métodos ágiles a nivel de programas y portafolios de proyectos. Poniéndolo en otras palabras, los proyectos ágiles están restringidos porque los portafolios que los engloban no son ágiles, lo cual entorpece la asignación efectiva de recursos. Ante esto, la pregunta que debemos hacernos es: ¿Cómo podemos escalar los métodos ágiles más allá de los proyectos individuales de tal forma que impacten y beneficien a los programas y portafolios que los engloban?

Definiendo la gestión de portafolio de proyectos

Antes de ver cómo podemos cambiar la gestión de proyectos, hay que entender su esencia.

La meta de la gestión de portafolio en un ambiente de TI es ayudarnos a manejar la eficiencia y efectividad global de los esfuerzos de TI en una organización. Esto se logra al asegurar que todos los proyectos y sistemas existentes son visibles, planeados, y alineados a las metas de la organización.

La gestión del portafolio de proyectos es importante ya que las organizaciones de TI exitosas son aquellas que ven más allá de las necesidades de un solo sistema. Las actividades fundamentales de esta disciplina incluyen la identificación y selección de proyectos, el monitoreo y gobierno de proyectos, y la gestión del inventario de activos de TI.

Definiendo el desarrollo ágil

Definir el desarrollo de software ágil no es algo trivial. Muchas personas se refieren a los valores del Manifiesto Ágil como una definición. Sin embargo, para mí el manifiesto funciona mucho mejor como filosofía que como definición. Algunas personas establecen que conoces Agile hasta que lo ves –lo cual me parece una buena definición para los consultores experimentados, pero no para aquellos que apenas tratan de entenderlo. La definición que utilizamos en el grupo de software en IBM es la siguiente:

“El desarrollo de software ágil es una estrategia disciplinada y evolutiva que consistentemente genera software de alta calidad, dentro de los tiempos y costos. Se realiza por medio de un ambiente altamente colaborativo y autodirigido, con la participación activa de los interesados para asegurar que el equipo entienda y resuelva sus necesidades cambiantes. Los equipos de desarrollo ágil adoptan justo la cantidad necesaria de formalidad para cada situación que enfrentan.”

Aunque esta definición describe lo que consideramos que son los aspectos esenciales del desarrollo ágil, encontramos que a muchos de nuestros clientes se les dificulta identificar si alguno de sus equipos realmente hace desarrollo ágil. Para resolver esto hemos definido un conjunto de criterios que consideramos que los proyectos deben cumplir para ser considerados ágiles:

• Equipos autodirigidos
• Participación activa de los interesados
• Software ejecutable al final de cada iteración
• Integración continua con pruebas de regresión
• Mejora continua por medio de retroalimentación

Habiendo definido lo que es la gestión de proyectos y el desarrollo ágil, quiero hacer algunas aclaraciones importantes:

1. Considero que no hay nada inherente al desarrollo ágil que implique que los proyectos ágiles no pueden encajar en un marco de gestión de portafolio.
2. Tampoco creo que todos los proyectos de software en un portafolio deban seguir el mismo proceso.
3. El paradigma de proceso elegido para desarrollar un sistema potencial es una decisión importante durante la identificación y selección de proyectos, ya que cada paradigma conlleva ciertos riesgos y beneficios.
4. Ya que diferentes proyectos pueden seguir diferentes paradigmas de desarrollo, la actividad de monitoreo de proyectos debe ser lo suficientemente flexible como para poder manejar este rango.

El alcance de la gestión de portafolios

La gestión del portafolio de proyectos sucede más allá del ciclo de vida de un sistema en particular – desde antes de su concepción, durante el desarrollo, producción e incluso en el retiro del sistema.

Tal vez una de las razones por la que muchos desarrolladores malinterpretan la gestión de portafolio de proyectos es porque mucha de ésta sucede fuera del alcance del desarrollo de software mismo.

La identificación y selección de proyectos ocurre antes del esfuerzo de desarrollar el software, y gran parte del esfuerzo de monitoreo ocurre después de que el sistema es desarrollado.

Las organizaciones cuentan con recursos limitados, y muchas ideas u oportunidades de invertir dichos recursos. El resultado es que hay que escoger cuidadosamente cuales son los proyectos en los que la organización se enfocará para maximizar el retorno de inversión. Un concepto común entre los practicantes de ágil es el de la “Iteración 0”, que es el inicio del ciclo de desarrollo de un sistema. Es en esta iteración que se realiza el trabajo fundamental de organizar al equipo del proyecto, definir los requerimientos iniciales, la visión arquitectónica, y la planeación de alto nivel. Para que esta iteración 0 pueda llevarse, alguien tuvo anteriormente que decidir que este proyecto valía la pena. Así que la iteración 0 no es la primera. Para mantener el esquema de numeración consistente, diremos que ese trabajo se realiza en la iteración -1.

Identificación y selección de proyectos

Este esfuerzo es un proceso continuo en el que se recopilan ideas para nuevos proyectos, se evalúan y seleccionan.

La identificación de proyectos puede y debe ser lo más ágil posible. Cuando se propone un nuevo proyecto se debe realizar una inversión inicial para:

• Definir el proyecto a alto nivel
• Identificar una estrategia para llevarlo acabo
• Evaluar su viabilidad

En base a este trabajo, el proyecto será desechado o priorizado y puesto en el backlog de proyectos. El backlog es una lista priorizada de proyectos potenciales que pueden ser tomados por el departamento de TI. La cantidad de proyectos potenciales siempre será mayor que la cantidad de proyectos que el departamento de TI puede atender, por ello la necesidad de priorizarlos. Así como los desarrolladores ágiles implementen requerimientos de acuerdo a su prioridad, los gerentes de portafolio ágiles deben ordenar los proyectos en base a su retorno de inversión.

Monitoreo y gobierno

Iniciar el proyecto adecuado es tan solo un aspecto de la gestión de proyectos; también es necesario supervisar y guiar los proyectos en desarrollo, así como aquellos sistemas que ya están en producción o siendo retirados. Los riesgos iniciales fueron identificaron durantela iteración -1, sin embargo estos evolucionarán durante el desarrollo del proyecto. La naturaleza de los proyectos ágiles facilita la visibilidad hacia estos, lo cual facilitan la supervisión y gestión efectiva de proyectos dentro de un portafolio.

Los equipos ágiles disciplinados también contarán con un programa de métricas para soportar el gobierno de los proyectos. Las prácticas del desarrollo esbelto ofrecen una buena guía para establecer programas de métricas adecuados. Las tres principales recomendaciones son: Aplicar métricas sencillas y relevantes, supervisión continua de los proyectos y tener un ambiente integrado que automatice la generación de métricas. El aplicar métricas simples y relevantes permite que éstas sean más consistentes, precisas y útiles. La supervisión continua es crucial para poder corregir el rumbo a tiempo en un proyecto con problemas, o incluso cancelarlo antes de que haya grandes pérdidas.

Por último, la automatización de métricas es importante ya que mientras más se recaiga en métricas manuales, el costo de éstas será mayor y su precisión menor; peor aún, pueden ser completamente falsas ya que el equipo puede querer tapar lo que realmente sucede en el proyecto.

En mi experiencia, la supervisión efectiva de un proyecto de software requiere tres categorías básicas de métricas: costo, calidad y productividad. El costo y calidad son fáciles de entender. En cuanto a la productividad, la meta en realidad no es medir el nivel de productividad como tal, sino determinar si un equipo está siendo más productivo conforme pasa el tiempo. Una métrica que los equipos ágiles frecuentemente capturan es la llamada “velocidad”. La velocidad de un equipo es el número de puntos de trabajo que pueden realizar en una iteración, calculada al observar el historial de iteraciones previas. Los equipos ágiles se basan en su métrica de velocidad para determinar la cantidad de trabajo a la que se pueden comprometer en una iteración. Si analizamos el cambio de velocidad de un equipo a lo largo del tiempo –es decir su aceleración– entonces encontraremos una métrica de la mejora en productividad.

El monitoreo y gobierno de sistemas una vez que se encuentran en producción también es de gran importancia en la gestión de portafolios. Muchas personas se enfocan solamente en los aspectos de la gestión de portafolios relacionados con el desarrollo de nuevos proyectos, pero eso es un error. Los gerentes de portafolio deben tener un buen entendimiento de los sistemas existentes en el inventario de activos de TI, así como de los sistemas que están por salir. Retirar un sistema existente puede ser una tarea complicada, y por lo tanto debe ser cuidadosamente gestionada.

Gestión de Inventario de TI

Las organizaciones de TI típicamente cuentan con una cantidad significativa de sistemas en producción, y comúnmente dichos sistemas están lejos de la perfección. Uno de los principales retos de los equipos de desarrollo es determinar estrategias viables para aprovechar dichos sistemas. Las estrategias técnicas para rehabilitar dichos sistemas ya existen y son suficientemente conocidas. El reto principal no es técnico, sino en cuanto a cómo gestionar efectivamente el inventario de sistemas existentes.

Una estrategia que yo he visto ser utilizada en varias organizaciones es la de clasificar los activos de TI, ya sean sistemas o fuentes de datos, en las siguientes categorías:

• Clase A. Activos críticos para la organización en el largo plazo.
• Clase B. Activos importantes, pero no se sabe con certeza si se mantendrán durante un largo periodo de tiempo.
• Clase C. Activos que no son críticos para la estrategia a largo plazo y posiblemente están próximos a ser eliminados o remplazados.

Esta categorización ayuda a los equipos de desarrollo a determinar en qué sistemas vale la pena invertir tiempo para refactorizar y mejorar componentes. Por ejemplo, automáticamente se invertiría en la calidad de los activos clase A, así que se implementarían pruebas de regresión para ellos y se aplicaría refactorización para mejorarlos gradualmente. En el otro extremo están los activos clase C, en los que no vale la pena invertir tiempo más allá de reparar defectos críticos. Los activos clase B están en medio y por lo tanto requieren ser juzgados caso por caso, así que mi recomendación es tratar de tener los menos activos posibles en esta categoría.

Conclusión

La gestión del portafolio de proyectos es una disciplina importante en las organizaciones de TI, y puede ser adaptada para lidiar con las necesidades de los proyectos ágiles. De hecho, los esfuerzos de gestión del portafolio pueden ser mejorados a través de la incorporación de prácticas ágiles. Las estrategias efectivas para la gestión del portafolio de proyectos reflejan las necesidades de los sistemas a través de todo su ciclo de vida, y se coordinan con otras disciplinas organizacionales tales como la arquitectura empresarial y el gobierno corporativo de TI.