¿Qué es la gestión de programas ágil?

La gestión de programas ágil es un enfoque para gestionar múltiples proyectos relacionados (un programa) que se basa en principios ágiles como la flexibilidad, la colaboración, el desarrollo iterativo, la priorización del feedback de los clientes y la mejora continua.

Ágil es una filosofía con un conjunto de principios más que una metodología específica. Sin embargo, existen metodologías ágiles bien establecidas que a menudo forman parte de la gestión de programas ágil, como Scrum, programación extrema (XP) y Kanban. La gestión de programas ágil se diseñó inicialmente por y para el sector del software con el fin de ofrecer un mayor valor a los clientes con mayor rapidez, pero ahora tiene aplicaciones mucho más allá de esa industria.

La gestión de programas ágil suele incluir varios proyectos relacionados. Los proyectos individuales se pueden gestionar con un marco ágil, pero la gestión de programas ágil incorpora un conjunto de proyectos en un único todo cohesivo a lo largo de todo el ciclo de vida. Subiendo de nivel, un conjunto de programas y proyectos subyacentes podrían organizarse bajo una gestión de carteras más amplia.

La gestión de proyectos ágil se centra en un proyecto específico y en la gestión de los objetivos, los plazos, los recursos y los equipos relacionados con ese proyecto. La gestión de programas ágil supervisa un grupo de proyectos relacionados y la estrategia que une estos proyectos en torno a objetivos organizativos más amplios. Estas dos disciplinas comparten muchas de las mismas funciones, pero varían en su alcance, y los directores de programas ágiles asumen un papel más amplio en la estrategia del programa, el riesgo, la comunicación con los stakeholders y más.

Una forma rápida y demasiado simplificada de pensarlo es que la gestión del proyecto se preocupa más por la ejecución táctica y puntual de un proyecto individual. Mientras que la dirección del programa adopta un enfoque más estratégico para coordinar el éxito integral de los distintos proyectos que entran en el ámbito del programa.

La gestión de proyectos como disciplina comenzó a tomar forma en los Estados Unidos en la década de 1950. En la década de 1990, se formalizaron un grupo de métodos conocidos como" cascada ", en los que cada fase de un proyecto debe completarse antes de que todo el equipo pase a la siguiente fase. Pero a medida que el software aumentó en vitalidad y complejidad, los métodos tradicionales de gestión de proyectos y en cascada resultaron engorrosos y menos que ideales para proyectos que se mueven rápidamente y enfrentan cambios frecuentes.

En 2001, un grupo de desarrolladores de software creó el Manifiesto ágil para la gestión de proyectos ágil, que incluye cuatro valores clave y 12 principios. Los valores clave son:

• Individuos e interacciones sobre procesos y herramientas
  
  
• Software de trabajo sobre documentación completa
  
  
• Colaboración con el cliente en la negociación del contrato
  
  
• Responder al cambio en lugar de seguir un plan

Los valores preferidos no requieren el abandono de los no preferidos. Por ejemplo, la filosofía ágil no prohíbe el uso de un plan, sino que pone mayor énfasis en responder y prepararse para el cambio inevitable.

Estos principios ágiles se hicieron cada vez más populares para el proceso de desarrollo de software, pero la filosofía va mucho más allá del desarrollo ágil de software. Los principios ágiles se emplean ahora en muchas industrias diferentes, desde la moda hasta la biotecnología y la gobernanza.

Lo que hace que el enfoque ágil sea diferente de los métodos anteriores, como la cascada, es que los métodos ágiles están, desde el principio, diseñados para ser iterativos, cooperativos y flexibles. En un sistema de gestión de programas ágil, los proyectos se crean rápidamente y se revisan, debaten y modifican periódicamente en respuesta a la respuesta del equipo o del cliente. Se supone desde el principio que los planes y enfoques tendrán que cambiar, y que no habrá una adherencia servil a la planificación inicial. Los miembros individuales del equipo están facultados para hablar, sin una jerarquía tan firme como en otros enfoques.

Dado que la gestión ágil de programas es una filosofía más que una metodología concreta, los aspectos específicos de las prácticas ágiles pueden variar drásticamente de una organización a otra, o de un programa a otro. Pero hay algunos aspectos que se encuentran comúnmente dentro de la gestión ágil de programas.

La gestión ágil de programas incluye múltiples proyectos individuales; tanto el conjunto como cada proyecto individual podrían organizarse dentro de un marco ágil. La gestión ágil de programas incorpora una visión holística y global de un grupo de proyectos. A menudo incluye elementos que no están presentes en la gestión de proyectos individuales, como la elaboración de presupuestos, la estrategia general y el análisis a largo plazo.

Responder rápidamente al cambio es un principio fundamental de la filosofía ágil. Como tal, la gestión de programas ágiles acepta el cambio como una oportunidad para ajustar el rumbo y realizar mejoras sobre la marcha que aporten valor al cliente. Dividir los proyectos en incrementos más pequeños para su finalización permite a las organizaciones ser más flexibles y adaptarse más rápidamente.

Un aspecto clave de la gestión de programas ágiles radica en un enfoque iterativo. Los proyectos individuales dentro del programa pasan por múltiples versiones y los equipos de desarrollo de productos discuten y mejoran los resultados en cada versión. Es vital ofrecer continuamente resultados de trabajo, ya sea un proyecto completo o un solo aspecto. También es importante perfeccionar el producto con cada iteración en función del feedback de los clientes, los KPI y los requisitos cambiantes.

La priorización de ágil premia la conversación cara a cara sobre el correo electrónico prolongado u otra comunicación basada en texto. Mientras que un hilo de correo electrónico puede llevar horas, días o incluso semanas, debido a limitaciones de tiempo o correos electrónicos perdidos, una comunicación cara a cara puede realizar la misma tarea en minutos.

La gestión de programas ágil, como visión global de un programa, debe centrarse en la eficiencia y eliminar elementos innecesarios o engorrosos. La documentación es un medio para un fin, no el fin en sí mismo, y debe incluir solo lo necesario.

La honestidad y la apertura son clave para el éxito de un programa ágil. Las conversaciones deben permitir que todos los miembros del equipo hablen. En este enfoque de gestión, la voz de todos es válida y se escucha.

Al mismo tiempo, debe ser aceptable filtrar las ideas impracticables sin que el progenitor de dicha idea se sienta desanimado de hablar en el futuro. El éxito de las "retrospectivas" (o "retros", que son evaluaciones posteriores al proyecto en las que se recopila feedback) también depende de la transparencia del equipo.

La gestión de programas ágil, como filosofía, no requiere el uso de ningún marco en particular. Pero muchos marcos de gestión de proyectos, incluidos Scrum y Kanban, se han asociado estrechamente con la filosofía ágil. Estos son algunos de los marcos más populares.

Scrum es un marco para el trabajo colaborativo en proyectos en equipo. El nombre, aunque parece similar a un acrónimo, en realidad proviene del deporte del rugby, en el que un scrum encuentra a los jugadores entrelazando los brazos para un empuje colaborativo hacia sus oponentes. Es una especie de carga de caballería, sin los caballos.

En ágil, un equipo de scrum incluye tres roles:

• Gerente de proyecto: este es el enlace entre el equipo scrum y los stakeholders, que podrían ser usuarios, clientes o una empresa matriz. El gerente de proyecto es responsable de comunicar factores externos, como el presupuesto, la dotación de personal y el feedback al equipo de scrum, al tiempo que comunica el progreso del equipo a los stakeholders.
  
  
• Scrum master: el scrum master no es tanto un "jefe" tradicional como un profesor del método scrum, un director de orquesta que facilita la orientación, la comunicación y la resolución de problemas. Los scrum masters no suelen ser los responsables de contratar y despedir.
  
  
• Desarrolladores o miembros del equipo: este término puede diferir en los casos en que, por ejemplo, el equipo de scrum está en una industria ajena al software. Ya sea que este rol se llame desarrollador, miembro del equipo o miembro del personal, este rol no tiene jerarquía. Idealmente, el equipo tiene entre tres y nueve miembros; los grupos más grandes tienden a ser más difíciles de guiar para un experto en scrum. Esto también puede incluir equipos autoorganizados, en los que las personas deciden exactamente quién y qué necesita el equipo para tener éxito sin una planificación excesiva por parte de la gerencia.

Scrum tiene algunos conceptos específicos que lo separan de otros modelos organizativos basados en equipos. El backlog del producto es un repositorio de todas las tareas, ideas, requisitos, entregables y recursos que el equipo puede necesitar durante el scrum. Puede (y realmente debe) ser actualizado y supervisado constantemente por el equipo para ayudar a garantizar su eficiencia e integridad.

En un scrum, el trabajo se separa en sprints, que suelen durar entre una y cuatro semanas. En el sprint, los miembros del equipo trabajan para alcanzar un objetivo específico y entregable. Ese objetivo puede ser un modelo de trabajo, una maqueta, un prototipo o incluso sólo una función o elemento del producto o solución final.

Durante el sprint, los miembros del equipo se reúnen una vez al día en un "scrum diario" o "stand-up". Según los principios de scrum, estas reuniones deben ser de un nivel extremadamente alto. Con una duración máxima de 15 minutos, el scrum diario encuentra a los miembros del equipo anunciando brevemente su progreso y cualquier bloqueador que esté obstaculizando su trabajo, con el menor detalle posible. A veces, ciertos miembros del equipo pueden interrumpir una reunión posterior al scrum diario para discutir más a fondo algo anunciado en el scrum diario.

Al final de un sprint, todo el equipo, miembros del equipo, scrum master y director del proyecto, se reunirá para revisar y discutir lo que se ha construido. El director del proyecto puede transmitir cualquier cambio de los stakeholders, como los usuarios o la organización en general, y tras debatirlo, el equipo puede incorporar esos cambios en el siguiente sprint.

Kanban es un sistema visual para gestionar y realizar seguimiento de proyectos. Los tableros Kanban presentan una representación visual del progreso de un equipo en un proyecto, en el que las subtareas individuales se clasifican en una de unas pocas categorías. Esas categorías suelen incluir:

• Backlog: todas las tareas que aún no se han movido a otra categoría; al inicio del proyecto, todas las tareas estarán en la cartera de pedidos
  
  
• En proceso: tareas que están en curso
  
  
• En revisión: tareas para las que se ha alcanzado la etapa inicial de finalización, que están siendo evaluadas por otra persona
  
  
• Listo: tareas que se completaron.

“Kanban” proviene de la combinación de las palabras japonesas para signo (“kan”) y tablero (“ban”), que juntas significan algo similar a una valla publicitaria o un tablero de mensajes. Kanban se puede realizar tanto en forma analógica como digital. En la forma analógica, se suelen utilizar postits físicos para las tareas individuales, que se van moviendo de columna en columna a medida que se completan.

También hay muchas versiones digitales de tableros kanban, que pueden ser especialmente útiles para equipos de proyectos en los que algunos o todos los miembros son trabajadores remotos.

La programación extrema, o XP, es una metodología ágil diseñada originalmente para que los ingenieros de software mejoren la calidad, la capacidad de respuesta y la velocidad del software. El concepto básico es una forma de ágil, que se basa en ráfagas aún más pequeñas de plazos de creación comprobables.

En XP, cada elemento individual de un proyecto general se prueba repetidamente, a veces incluso se bombardea con pruebas destinadas a romperlo. Luego, esos aspectos individuales se prueban juntos, a menudo semanalmente, para ayudar a garantizar la máxima compatibilidad.

En la comunicación, XP se basa en la simplicidad al extremo. La documentación pretende ser lo más mínima posible para que otros miembros del equipo la entiendan, con lenguaje, conceptos y metáforas simples. Esta simplicidad también se extiende al diseño real de la tarea; Los proyectos de XP a menudo se diseñan sin considerar características adicionales en el futuro, considerándolas como ajenas al lanzamiento del proyecto. Esto a veces se conoce como YAGNI, o You Aren't Gonna Need It.

XP no es la opción adecuada para todos los proyectos; es importante usar XP solo para proyectos que no necesitarán escalabilidad o reelaboración significativa.

SAFe es un conjunto de principios y prácticas basadas en el método de desarrollo lean-ágil, DevOps y el pensamiento sistémico. Scaled Agile Framework (SAFe) está diseñado (como su nombre lo indica) para escalar marcos ágiles en grandes organizaciones para alinear múltiples proyectos y ayudar a garantizar la funcionalidad cruzada y la interoperabilidad. Esto se hace principalmente a través de una estructura que incluye hojas de ruta de incremento de planificación (PI).

Las identificaciones incluyen "habilitadores" (dependencias de otras tareas), "épicos" (iniciativas más grandes diseñadas para una necesidad empresarial específica) e "historias" (funcionalidad deseada, ya sea desde una perspectiva de usuario o empresarial).

La metodología ágil disciplinada se considera un conjunto de principios, promesas y pautas en lugar de una metodología completa. Es un enfoque ligero, mínimo e híbrido para la gestión de programas con una gran libertad para los miembros individuales del equipo.

Algunos marcos ágiles, como Scrum y SAFe, incluyen metodologías y pasos prescriptivos. Esta especificidad puede ser excelente para ciertos proyectos, pero DA tiene como objetivo proporcionar más libertad y agilidad a los miembros del equipo. El concepto básico permite a las personas elegir qué conceptos y marcos son ideales para su flujo de trabajo particular. Scrum puede funcionar para algunos, pero no para otros, especialmente dentro de una perspectiva de programa más amplia. DA pone una gran cantidad de poder en manos de las personas, lo que lo convierte en la mejor opción para proyectos con miembros del equipo que estén muy bien informados, sean independientes y ya estén familiarizados con los conceptos ágiles básicos.

El Scrum a gran escala, comúnmente conocido como LeSS, es una versión de Scrum diseñada específicamente para equipos más grandes, o grupos de equipos, para los que Scrum fue creado. Aunque LeSS sigue implicando sprints, reuniones diarias de scrum y revisiones, tiene algunas directrices adicionales para garantizar que los equipos más grandes alcancen sus objetivos escalando la metodología ágil sin perder su alma.

En LeSS, todos los equipos trabajan en un sprint común, en lugar de, como en la gestión de proyectos ágiles, sprints individuales planificados por equipos individuales. También hay un backlog compartido, completo con todas las tareas necesarias para todo el programa. Y la planificación del sprint implica dos tipos de reuniones: una reunión de planificación general para todos los equipos y luego reuniones de planificación del sprint individuales para cada equipo.

Nexus es un marco similar a Scrum, con algunas adiciones, sustracciones y alteraciones. La principal diferencia es la incorporación del Equipo de Integración Nexus (NIT), un grupo separado de miembros del equipo que funcionan como entrenadores. El NIT incluye a menudo a miembros de los equipos Scrum, y es responsable de dirigir los bloqueos, proporcionar asistencia y entrenar a los equipos a través de los procesos ágiles. El NIT tiene sus propias reuniones, separadas del Scrum diario.

Si bien Scrum es un concepto fenomenal para proyectos específicos dentro de la gestión ágil de proyectos, cuando hablamos de gestión ágil de programas, en realidad estamos hablando de equipos de equipos. Ahí es donde entra Scrum@Scale.

En Scrum@Scale, todos los miembros del equipo ágil se consideran parte de un equipo Scrum intercambiable, lo que permite la colaboración interdisciplinar. Para ayudar con los desafíos presentados por un programa más grande en tiempo real, hay algunos miembros nuevos del equipo. El director de producto (CPO) crea un backlog único para todos los scrums y se coordina con los propietarios de productos individuales. Un papel similar es el Scrum de scrums master, que coordina los esfuerzos entre los scrum masters.

Lean es una metodología destinada a reducir las ineficiencias y crear mejoras continuas en la calidad de los entregables. A menudo se considera que está incluida en el marco ágil. Pero mientras ágil es una filosofía, lean es una metodología, con herramientas y directrices más específicas. Lean se preocupa principalmente por minimizar la ineficiencia y el desperdicio, mientras que la filosofía ágil se centra principalmente en la iteración, el feedback y la flexibilidad.

Lean tiene cinco principios fundamentales:

• Identificar el valor: básicamente, determine exactamente cuál es el objetivo y elimine todo lo que no añada valor.
  
  
• Trazar el flujo de valor: utilice una herramienta de gestión como los tableros Kanban para visualizar la hoja de ruta del producto. Básicamente, visualice el plan del proyecto de principio a fin.
  
  
• Crear un flujo de trabajo: construya el proceso de producción con pasos específicos, buscando cualquier obstáculo concebible. El objetivo es crear un flujo de trabajo lo más fluido posible.
  
  
• Establecer un sistema de extracción: un sistema de extracción se basa en crear nuevas tareas únicamente debido a la demanda de los clientes y solo cuando los miembros del equipo están listos para más trabajo. Esto a menudo se hace con una cola de tareas.
  
  
• Mejorar continuamente: utilice una variedad de técnicas para crear valor continuamente y mejorar el producto. Puede tratarse de metodologías y filosofías como Lean Six Sigma y Kaizen o marcos estructurados como Scrum, que fomentan las pruebas constantes y los circuitos de feedback beneficiosos.

La gestión ágil de programas, con sus metodologías asociadas, proporciona muchas formas de mejorar la entrega de proyectos.

• Especificidad: al iterar continuamente, los equipos ágiles pueden reducir exactamente lo que quiere el cliente, en lugar de intentar mejorar ciegamente todo el proyecto.
  
  
• Eficiencia: la gestión ágil de programas incluye principios destinados a reducir el desperdicio, la documentación y la burocracia.
  
  
• Versatilidad: con plazos de entrega rápidos en respuesta a los comentarios de los clientes, la versatilidad es una parte fundamental de la gestión ágil de programas. Los equipos ágiles saben, incluso antes de que comience un proyecto, que se realizarán cambios durante el proceso.
  
  
• Moral del equipo: la gestión de programas ágil fomenta la apertura, la transparencia y el empoderamiento de los miembros individuales del equipo para que hablen. La jerarquía es menos importante que la honestidad y el trabajo en equipo dedicado.