Gestión ágil de proyectos

Cómo pueden ayudar las metodologías ágiles a tu equipo de software

Presentación
¿Qué es la gestión ágil de proyectos?
La gestión ágil de proyectos es una forma iterativa de gestionar los proyectos de desarrollo de
software que se basa en realizar entregas de forma continua y en integrar el feedback del cliente
con cada iteración.

Los equipos de software que aplican las metodologías ágiles en la gestión de proyectos aumentan
su velocidad de desarrollo, expanden la colaboración y fomentan la capacidad de responder
mejor a las tendencias del mercado.

A continuación, te damos las claves necesarias para saber cómo poner en marcha o definir tus
estrategias de gestión ágil de proyectos.

Historia

Los equipos de desarrollo de software vienen utilizando las metodologías ágiles, nacidas en los
años 40 a partir del modelo de fabricación "lean" ideado por Toyota, para aliviar la carga de
trabajo y aumentar la transparencia, así como para responder a las necesidades de los clientes
siempre en evolución. La metodología ágil supone un cambio significativo con respecto a la
gestión de proyectos en cascada, que se centra en los lanzamientos de gran envergadura, y
permite que los equipos de software colaboren mejor e innoven más rápido que nunca.

La gestión de proyectos tradicional basada en la metodología ágil se puede dividir en dos marcos
de trabajo: scrum y kanban. Mientras que el scrum se basa en las iteraciones de proyectos de
duración fija, el kanban se centra en un sistema de entrega continuo. Tras la finalización de una
tarea, el equipo pasa de inmediato a la siguiente.

Funcionamiento del método scrum

El scrum es un método de la gestión ágil de proyectos que se basa en iteraciones de trabajo de

duración fija llamadas sprints. Existen cuatro protocolos que articulan cada sprint.

El punto de partida se encuentra en el backlog o lista de tareas pendientes que se deben llevar a
cabo. En scrum, hay dos tipos de backlogs: uno se refiere al backlog del producto (facilitado por el
propietario del producto) que consiste en una lista de funcionalidades según su prioridad; y el
otro es el backlog de sprint que se crea incorporando los elementos más importantes del backlog
del producto hasta que se completa y se pasa al siguiente sprint. Los equipos que adoptan el
método scrum tienen funciones específicas y exclusivas cuando intervienen en el proceso.
Normalmente, hay tres figuras en un equipo de scrum: un experto en scrum, es decir, un
especialista del método scrum; el propietario del producto, que representa la cabeza visible del
producto; y el equipo de scrum, que habitualmente está formado por miembros con diferentes
funciones y que se encargan de completar las tareas.
Los cuatro protocolos del método scrum

Planificación de Demostración
Reunión rápida diaria Retrospectiva
sprints del sprint

Es una reunión de Es una reunión También conocido como Es una revisión

planificación de participativa en reunión rápida diaria, es de lo que ha ido
equipo para la que el equipo una breve reunión de 15 bien y mal, con
determinar qué hay enseña lo que minutos para poner al medidas para
que terminar en el ha lanzado en tanto al equipo de mejorar el
siguiente sprint. un sprint. software. siguiente sprint.

Tableros de scrum

Los tableros scrum se emplean para visualizar todo el trabajo de un sprint determinado. Durante
la reunión de planificación del sprint, el equipo pasa las tareas del backlog del producto al
backlog del sprint. Los tableros scrum pueden tener diferentes fases de trabajo que se pueden
ver en el workflow, entre las que se incluyen Pendiente, En curso y Completado. Los tableros scrum
son la pieza clave para mejorar la transparencia en la gestión ágil de proyectos.

Funcionamiento del método kanban

El kanban es un método de la gestión ágil de proyectos que adapta las tareas a las capacidades
del equipo. Se basa en completar el trabajo asignado en el menor tiempo posible, dando a los
equipos la posibilidad de responder a cualquier cambio que surja de una forma más rápida que
en el método scrum.

A diferencia del método scrum, el método kanban no utiliza backlogs (por norma general). En su
lugar, los trabajos se asignan a la columna Pendiente. Esto permite que los equipos que usen el
método kanban puedan centrarse en un sistema de entrega continuo, por lo que las tareas se
pueden realizar en cualquier momento. Todas las tareas se pueden ver, estudiar y preparar para
llevarlas a cabo, de tal manera que cuando se completa una, el equipo puede pasar a la siguiente
de inmediato. El volumen de trabajo se adapta a las capacidades del equipo respetando los
límites del trabajo en curso, que consiste en una restricción predefinida y aplicada al volumen de
trabajo y que se puede asignar a una sola columna en un momento dado (a excepción de la
columna Pendiente). El método de trabajo kanban incluye los siguientes cuatro elementos:

Los cuatros elementos del método kanban

Lista de
Límites del trabajo Sistema de entrega
tareas (o Columnas o filas
en curso continuo
historias)

La lista de
Se utilizan en los Se trata de una regla
tareas o El equipo se ocupa de
tableros de kanban que establece un
historias las historias dentro de
para diferenciar las límite al volumen de
representan los límites del trabajo
tareas de distintos trabajo pendiente y
las incidencias en curso y puede
flujos de trabajo, que se ajusta a las
o tareas que hacer publicaciones en
usuarios, proyectos, capacidades del
se deben cualquier momento.
etc. equipo.
abordar.

Tableros de kanban

Los tableros kanban se emplean para visualizar todo el trabajo que se está realizando. También
son útiles para organizar los recursos que necesiten los gestores de proyectos para llevar un
control del trabajo realizado y crear los cronogramas correspondientes. Un tablero kanban se
articula en columnas y filas para que las historias se muevan entre ellas según vayan
completándose. Las historias se asignan a la columna Pendiente hasta que se alcanza al límite del
trabajo en curso y se procede con la siguiente tarea. La lista de tareas se debe dividir en
apartados relativamente pequeños y deben organizarse por prioridades. Como puedes ver en el
ejemplo de al lado, las filas son muy útiles a la hora de separar las tareas de mayor prioridad del
resto.
Estimación, informes y planificación

Sea cual sea la metodología ágil que elijas para organizar la fase de desarrollo de un software,
necesitarás un modo de comprobar el progreso de tu equipo con el que puedas planificar los
futuros trabajos o sprints. Las estimaciones de proyectos ágiles ayudan a los equipos que usen
scrum y kanban a conocer bien sus capacidades. Los informes ágiles permiten consultar el
progreso del equipo a lo largo del proyecto. Y, finalmente, la preparación del backlog ayudará a
los gestores de proyectos a llevar un control de la lista de tareas pendientes y listas para que el
equipo las acometa.

Estimación de los proyectos ágiles

La estimación del proyecto es una fase imprescindible tanto en los métodos kanban y scrum
utilizados en la gestión de proyectos. En el caso del método kanban, muchos equipos fijan el
límite del trabajo en curso para cada fase en función de sus experiencias pasadas y el tamaño del
equipo. Los equipos de scrum hacen una estimación del proyecto para detectar cuánto trabajo se
puede realizar en un sprint concreto. Muchos equipos ágiles usan técnicas exclusivas de
estimación como la planificación iterativa mediante tarjetas ("planning poker"), la organización de
los horarios más adecuados o el uso de puntos de historia para determinar el valor numérico de
la tarea disponible. Estos tipos de estimaciones ofrecen a los equipos ágiles un punto de
referencia al que acudir durante la revisión retrospectiva del sprint y con el que comprobar el
rendimiento del equipo. Jira Software cuenta con opciones de personalización que se adaptan a
las técnicas de estimación de proyectos específicas de tu equipo.
Creación de informes ágiles

Las estimaciones de proyectos intervienen tanto al comienzo como al final de cada sprint. Estas
no solo ayudan a los equipos a establecer qué tareas pueden realizar al empezar un sprint, sino
que también les permiten evaluar al final lo acertadas que han sido las estimaciones iniciales. Los
informes ágiles, como los diagramas de evolución, muestran cuántos "puntos de historia" se han
completado durante el sprint. Por su parte, Jira Software permite crear decenas de informes listos
para usar que recopilan datos funcionales en tiempo real sobre el rendimiento de tus equipos.
Estos datos son muy útiles para realizar retrospectivas y son imprescindibles a la hora de mejorar
el desempeño de los equipos ágiles.
Gestión y preparación del backlog

Un backlog del producto es una lista de tareas asignadas al equipo de desarrollo que se basan en
la hoja de ruta del producto y sus objetivos. El equipo de desarrollo va cogiendo tareas del
backlog del producto para llevarlas a cabo en cada sprint.

La preparación y mantenimiento del backlog les sirve de ayuda a los equipos para alcanzar sus
objetivos a largo plazo al incorporar y quitar los elementos en función de la capacidad de trabajo
a largo plazo y al cambiar los objetivos del negocio. Jira Software permite a los equipos preparar
backlogs de gran tamaño clasificando y seleccionando varios elementos, además de ordenar las
historias de usuario y los errores arrastrando y soltando las incidencias. También se puede
aplicar un filtro con la herramienta de búsqueda ágil de Jira Software para encontrar una historia
de usuario o un error en particular.

Introducción a la gestión de proyectos

Algunos pensarán que la transición a lo ágil implica perder de vista el panorama general. No
podríamos estar menos de acuerdo.

Resumen
La gestión ágil de proyectos es un método iterativo de llevar a cabo proyectos que se basa en
realizar publicaciones de forma continua y en integrar el feedback de los clientes. Por ello, se
diferencia de la tradicional gestión de proyectos en cascada, que sigue un enfoque lineal de
desarrollo. La gestión ágil de proyectos promueve la comunicación abierta, la colaboración, la
adaptación y la confianza entre los miembros del equipo.

Los primeros en adoptar el desarrollo ágil solían ser pequeños equipos independientes que
trabajaban en pequeños proyectos independientes. Demostraron que el modelo ágil funciona,
para regocijo de los desarrolladores de software en todo el mundo y mejora de sus condiciones.
Recientemente, las organizaciones más grandes están escalando la metodología ágil más allá de
equipos y proyectos, buscando maneras de aplicarla a programas enteros. La metodología ágil se
ha extendido más allá de los equipos de desarrollo, y ahora la utilizan en equipos de TI, marketing
y desarrollo empresarial, entre otros.

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

La gestión ágil de proyectos es un método iterativo de llevar a cabo proyectos que se basa en
realizar publicaciones de forma continua y en integrar el feedback de los clientes. La posibilidad
de hacer ajustes durante cada iteración fomenta la velocidad y la adaptabilidad. Este modelo es
distinto al de gestión de proyectos lineal, que sigue una ruta establecida con desviación limitada.
La gestión ágil de proyectos es también un pilar de las prácticas de DevOps, en las que los
equipos de desarrollo y de operaciones trabajan en colaboración.

Cascada o ágil
La metodología ágil se empezó a adoptar en equipos de software, que pasaron del tradicional
modelo secuencial en cascada a un método que permitía recoger feedback y hacer ajustes de
forma continua a lo largo del ciclo de vida de desarrollo.

El modelo de gestión de proyectos en cascada implica una secuencia de ejecuciones claramente

definida, con proyectos que no pasan de fase hasta que la anterior recibe la aprobación final. Una
vez finalizada una fase, puede ser difícil y costoso revisar una etapa anterior. Los equipos ágiles
pueden seguir una secuencia similar, pero lo hacen en incrementos más pequeños con ciclos de
feedback regulares.
El modelo de gestión de proyectos en cascada sigue un enfoque lineal y secuencial. Funciona bien
para trabajos que implican procesos predecibles y recurrentes, pero puede dejar a los equipos de
desarrollo en mala posici´ón ante los imprevistos y sin la posibilidad de adaptarse más rápido
que la competencia.

Cualquier incumplimiento de plazos o cambio en el alcance durante un proyecto en cascada

puede tener un gran impacto en las versiones posteriores. Además, puede resultar difícil resolver
la deuda técnica o corregir errores si el equipo tiene que centrarse en desarrollar funciones
nuevas y avanzar por las distintas etapas del proyecto.

Abajo hemos incluido una imagen con un proyecto en cascada estándar, dividido en bloques de
tiempo estrictos. Este modelo fomenta una mentalidad de "máximo aprovechamiento" que
anima a desarrolladores, propietarios de productos y partes interesadas a solicitar la mayor
cantidad de tiempo posible en cada periodo de tiempo, ya que puede que no haya oportunidad
de iterar en el futuro. Por lo general, los equipos que utilizan el modelo en cascada intentan
controlar la corrupción del alcance a través del llamado "control de cambios", por el cual aceptan
que no debe modificarse el plan original.

El modelo en cascada puede agravar algunas de las dificultades habituales del desarrollo de
productos:

Impedimentos y gestión de dependencias: los estilos tradicionales de gestión de proyectos

suelen crear "rutas críticas" que impiden que el proyecto avance hasta que se resuelva una
incidencia que lo bloquea.
Dificultad para obtener el feedback de los usuarios y validar los productos: por si fuera poco,
los clientes finales no pueden interactuar con el producto hasta que no esté del todo
completo. Esto tiene como consecuencia que los problemas importantes relacionados con el
diseño del producto y el código no se descubren hasta la publicación.

En cambio, la gestión ágil de proyectos adopta un enfoque iterativo de desarrollo, ya que crea
varios pasos incrementales con intervalos de feedback regulares. Este modelo promueve la
adaptabilidad, ya que un equipo puede hacer ajustes a lo largo del proceso de desarrollo del
producto, en lugar de tener que limitarse a una trayectoria lineal. También permite realizar
publicaciones regulares y de gran impacto para que los equipos puedan lograr una serie de
victorias a lo largo del tiempo.

Las publicaciones iterativas permiten al equipo hacer lo siguiente:

Adaptarse a los cambios, como requisitos nuevos o impedimentos que bloquean parte del
trabajo.
Recoger el feedback de las partes interesadas durante el proceso y hacer ajustes a la hora de
iterar sin el estrés que causan los plazos de entrega.
 Crear relaciones y conexiones entre personas con funciones diferentes para que puedan
colaborar y comunicarse de forma eficaz.

La metodología ágil permite a los equipos adaptarse mejor a los inevitables cambios que se
producen durante un proyecto.

Una ventaja aún mayor es que los conjuntos de aptitudes se comparten en el equipo de software.
De este modo, se añade una mayor flexibilidad al trabajo en todas las partes de la base de código
del equipo y no se malgasta tiempo ni esfuerzo si cambia la orientación del proyecto. Para saber
más acerca de todo esto, lee nuestro artículo sobre crear grandes equipos ágiles.

Principios de la metodología ágil

Un proyecto ágil se segmenta en una serie de pasos incrementales que incluyen intervalos
de feedback regulares.
Cada requisito del proyecto se divide en fragmentos más pequeños, que luego se priorizan
según su importancia.
Promueve la colaboración, especialmente con el cliente.
Permite hacer ajustes en intervalos regulares para conseguir que se satisfagan las
necesidades del cliente.
Integra la planificación con la ejecución, lo que permite al equipo responder de forma eficaz
a los cambios de requisitos.

Aspectos que hay que tener en cuenta al implementar la

metodología ágil
Pasarse a la metodología ágil puede ser todo un reto, especialmente si el equipo o la organización
se basa en un modelo de gestión de proyectos más tradicional. Para adoptar prácticas ágiles,
puede ser necesario realizar cambios en los procesos, sobre todo si se quiere adoptar el modelo
DevOps, que implica que los equipos de desarrollo y de operaciones colaboren estrechamente
para desarrollar y mantener el software. Al implementar principios de metodología ágil, el equipo
y las partes interesadas deben tener en cuenta dos conceptos importantes:

La atención del propietario del producto debe centrarse en optimizar el valor de los
resultados del equipo. Además, debe ayudar al equipo a priorizar el trabajo más importante.
El equipo de desarrollo solo puede aceptar trabajo si tiene la capacidad de hacerlo. El
propietario del producto no debe imponer el trabajo al equipo ni obligarle a comprometerse
con plazos arbitrarios. El equipo de desarrollo se asigna trabajo del backlog del programa
cuando puede aceptar más trabajo.
Descubramos los mecanismos que usan los programas ágiles para organizar, ejecutar y
estructurar el trabajo de forma iterativa.

Hojas de ruta
La hoja de ruta describe cómo se desarrolla en el tiempo un producto o solución. En el desarrollo
ágil, proporciona contexto muy útil para ayudar a los equipos a alcanzar objetivos tanto
incrementales como a nivel de todo el proyecto. Las hojas de ruta están formadas por iniciativas,
que son grandes áreas de funcionalidad, e incluyen cronogramas que indican cuándo estará
disponible una función. A medida que el trabajo avanza y los equipos recaban nueva información,
es normal que la hoja de ruta cambie para reflejarla, ya sea ligeramente o de forma más
significativa. El objetivo es que la hoja de ruta siga centrada en las condiciones actuales que
afectan al proyecto y en los objetivos a largo plazo, de modo que el equipo pueda trabajar
eficazmente con las partes interesadas y seguir siendo competitivo.

Aquí puedes ver una hoja de ruta sencilla de un equipo de producto, con las iniciativas en
recuadros y los plazos indicados por los marcadores de hitos en rojo.

Requisitos
Las iniciativas de la hoja de ruta se dividen en una serie de requisitos. Los requisitos ágiles son
descripciones breves de la funcionalidad necesaria, en lugar de los documentos de 100 páginas
que se asocian con los proyectos tradicionales. Evolucionan con el tiempo y aprovechan el
entendimiento común que el equipo tiene del cliente y del producto deseado. Los requisitos
ágiles siguen siendo lean mientras todo el equipo desarrolla un entendimiento común mediante
la conversación y la colaboración constantes. Únicamente cuando la implementación está a punto
de empezar, se concretan los pormenores con todo detalle.

Backlog
El backlog define las prioridades del programa ágil. El equipo incluye todos los elementos de
trabajo en el backlog: funcionalidades nuevas, bugs, mejoras, tareas técnicas o arquitectónicas,
etc. El propietario del producto prioriza el trabajo del backlog para el equipo de ingenieros. Más
adelante, el equipo de desarrollo utiliza el backlog priorizado como única fuente fiable para saber
qué trabajo hay que hacer.

Métricas ágiles
Los equipos ágiles progresan gracias a las métricas. Los límites del trabajo en curso hacen que el
equipo y la empresa sigan concentrados en entregar el trabajo de la más alta prioridad. Gráficos
como el de control o el diagrama de trabajo pendiente ayudan a que el equipo prevea su
cadencia de entrega, y los diagramas de flujo continuo ayudan a identificar cuellos de botella.
Estas métricas y artefactos hacen que todos se centren en los grandes objetivos e infunden
confianza en la habilidad del equipo para entregar futuros trabajos.

Agile se basa en la confianza

Los procesos ágiles no pueden funcionar si no hay un alto nivel de confianza entre los miembros
del equipo. Hace falta sinceridad para mantener conversaciones difíciles sobre lo que es
conveniente para el programa y el producto. Puesto que las conversaciones tienen lugar a
intervalos periódicos, las ideas y preocupaciones se expresan con regularidad. Esto significa que
los miembros del equipo también tienen que confiar en las habilidades (y la disposición) de los
demás para llevar a efecto las decisiones que se tomen durante esas conversaciones.

En conclusión...
La gestión ágil de proyectos es un modelo innovador para todo tipo de proyectos, no solo los de
software. Al proporcionar la flexibilidad para responder a los cambios durante el ciclo de vida del
desarrollo, la metodología ágil permite a los equipos lanzar productos de mayor calidad que
satisfagan las necesidades de los clientes. Además, motiva a los equipos; fomenta la
responsabilidad, la innovación y la mejora continua; y permite responder a los cambios sin
desbordarse. Y eso le viene de maravilla a cualquier programa.

Workflow
Todo el mundo odia los "procesos", pero hay que asumirlo: sin un workflow establecido, no se va a
ningún lado.

Todos los equipos de software tienen un proceso para llevar a cabo el trabajo. Normalizar el
proceso (es decir, establecerlo como workflow) lo convierte en algo estructurado y repetible, lo
cual lo convierte en escalable. En Atlassian tenemos un enfoque iterativo de la gestión del
workflow porque nos ayuda a alcanzar nuestros objetivos más rápidamente y ejemplifica nuestra
cultura de equipo. Somos expertos en la gestión de workflows ágiles (sin falsa modestia) y
queremos ayudaros a que vosotros también lo seáis.

Empieza por lo fácil, empieza ahora

Al implementar un workflow para un equipo, siempre hay que empezar por lo fácil. Resiste la
tentación de dedicar semanas de ingeniería (en exceso). Los workflows demasiado complejos son
difíciles de entender y de adoptar, por no hablar de su adaptabilidad. Para los equipos de
software, recomendamos estos estados de workflow básicos:

Por hacer: Trabajo que no se ha empezado

En curso: Trabajo en el que el equipo está trabajando activamente.
Revisión del código: Trabajo que está finalizado y en espera de revisión.
Finalizado: Trabajo completamente terminado y que cumple con la definición que tenga el
equipo de finalizado.

En un gestor de incidencias, estos estados fluyen de uno al siguiente mediante transiciones que
estructuran el flujo de trabajo.

Flujo de trabajo ágil | Orientador ágil de Atlassian

Algunos equipos de software incluyen estados adicionales en su workflow para ayudarles a
realizar el seguimiento de los estados del trabajo con mayor precisión.
 Esperando el control de calidad: Trabajo que se ha implementado, pero que está
esperando la revisión de un encargado de pruebas (consulta nuestro artículo sobre pruebas
ágiles para obtener más información).
Listo para hacer un Merge: Código que se ha revisado y está listo para fusionarse con la
rama principal o la rama de publicación.

Cada estado del workflow no necesita un control por parte de distintas personas. A medida que el
equipo ágil madura, los desarrolladores pueden asumir más parte del trabajo, desde el diseño
hasta la entrega. Después de todo, un equipo autónomo que pueda controlar trabajo
heterogéneo es uno de los distintivos de la agilidad.

Los workflows saludables se adaptan a las necesidades del equipo. Es normal encontrar alguna
dificultad. Pero no es normal que se convierta en algo crónico.
Habla de cada punto problemático en la retrospectiva del equipo y recuerda que cada equipo
tendrá valores ligeramente diferentes en función de su proyecto, recursos tecnológicos y método
preferido para trabajar. Por eso es tan importante elegir un gestor de incidencias que tenga una
configuración de flujo de trabajo flexible. Demasiados equipos sacrifican su estilo de trabajo para
adaptarse a un conjunto de herramientas concreto, lo cual es frustrante para todos. Los
miembros del equipo empiezan a evitar esa herramienta, extendiendo la frustración por todo el
equipo y creando caos en general. Y cuando falla la motivación, la productividad se resiente. Son
dos contratiempos que todos queremos evitar.

Los equipos que acaban de adoptar metodologías ágiles o que no tienen habilidades
interdisciplinares a menudo terminan con "minicascadas" en su flujo de trabajo. Por ejemplo, el
equipo de diseño inicia un elemento de trabajo con un modelo. El equipo de desarrollo realiza la
implementación. El equipo de pruebas confirma la calidad. Cada estado está bloqueado hasta
que se complete el anterior. ¿Te suena? Eso es una cascada. No obstante, se puede hacer mucho
mejor con flujos de trabajo ágiles que desbloqueen el equipo y simplifiquen el desarrollo.

Optimiza el workflow
Cuando te sientas cómodo con el flujo de trabajo básico y estés listo para personalizarlo, crea
estados para cada tipo de trabajo del proceso del equipo. La idea, el diseño, el desarrollo, la
revisión del código y las pruebas son funcionalmente diferentes y pueden ser estados
individuales. Intenta lograr un conjunto lean de estados que comuniquen claramente la fase en la
que se encuentra un elemento de trabajo.

Los estados de proyecto también se pueden compartir con el resto de la organización. Al crear un
flujo de trabajo, piensa sobre qué métricas es importante informar y qué podrían aprender los
miembros que no sean del equipo. Por ejemplo, un flujo de trabajo bien diseñado responde a las
siguientes preguntas:

¿Qué trabajo ha finalizado el equipo?

¿El backlog de trabajo está aumentando o sigue el ritmo del equipo?
¿Cuántos elementos hay en cada estado?
¿Hay cuellos de botella que estén ralentizando al equipo?
¿Cuánto tarda una tarea media en completarse?
¿Cuantos elementos de trabajo no han pasado nuestros estándares de calidad a la primera?

El siguiente paso para optimizar el flujo de trabajo es garantizar un flujo constante de trabajo. Los
límites del trabajo en curso (WIP) imponen un número máximo y mínimo de incidencias en un
estado concreto del flujo de trabajo, asegurando que cada estado tenga trabajo suficiente para
involucrar a todo el equipo, pero no demasiado para evitar que dejen de estar centrados en las
prioridades. La aplicación de límites en el trabajo en curso mostrará rápidamente los procesos
que ralentizan el trabajo general a lo largo de la canalización. A medida que el equipo aprenda a
optimizar teniendo en cuenta los límites WIP, aumentará el rendimiento. (Consulta el artículo
sobre límites WIP para obtener más información).

Los retos de escalar un workflow

Las organizaciones que cuentan con varios equipos ágiles se enfrentan a retos especiales con los
flujos de trabajo. A menudo, los equipos desean optimizar su propio flujo de trabajo para reflejar
su cultura y sus procesos únicos. Es algo perfectamente comprensible. Sin embargo, puede
suponer un problema cuando distintos equipos usan procesos diferentes en el mismo proyecto.

Los equipos ágiles que trabajan juntos se benefician al compartir el mismo flujo de trabajo. Usar
el mismo flujo de trabajo hace que realizar transiciones de trabajo entre equipos ágiles sea más
fácil, dado que usan las mismas convenciones para definir y entregar los trabajos. Crear un
proceso común normalmente implica concesiones por parte de ambos equipos. Eso está bien: así
los equipos aprenden los unos de los otros y al final, el resultado será un flujo de trabajo mejor.

Consejo de Experto
Con Jira Software, el gestor de incidencias de Atlassian, los equipos pueden compartir flujos de
trabajo, pero tienen representaciones distintas del proceso en su tablero ágil. Esta capacidad da
lugar a opciones de visualización flexibles sin sacrificar el activo compartido de flujo de trabajo.

Independientemente de tu workflow, el proceso para desarrollarlo también debería ser ágil.

Habla sobre ello en las retrospectivas de vez en cuando y adáptalo a medida que cambie la
cultura y la composición de los equipos.

Epics, historias, temas e iniciativas

Estas sencillas estructuras ayudan a los equipos ágiles a gestionar con dignidad el alcance y a
estructurar el trabajo.

Digamos que tu equipo y tú queréis hacer algo ambicioso como lanzar un cohete al espacio. Para
ello, tienes que estructurar el trabajo desde los objetivos más ambiciosos hasta los detalles más
minuciosos. Debes ser capaz de responder a los cambios, crear informes del progreso y ceñirte a
un plan. Los epics, las historias, los temas y las iniciativas son, exactamente, las herramientas que
necesitarás para conseguirlo.

Al comprender cómo estas populares metodologías ágiles y de DevOps ayudan a organizar el

trabajo, tu equipo puede lograr un equilibrio saludable entre estructura, flexibilidad y el
lanzamiento de cohetes al espacio.

¿Qué son las historias, los epics, las iniciativas y los temas?
Las historias, también llamadas "historias de usuario", son breves requisitos o solicitudes
escritas desde el punto de vista del usuario final.
Los epics son grandes cantidades de trabajo que se pueden desglosar en un número de
tareas más pequeñas (llamadas "historias").
Las iniciativas son conjuntos de epics que conducen hacia un objetivo común.
Los temas son grandes áreas de enfoque que abarcan a toda la organización.
Historias frente a epics ágiles
En cierto modo, las historias y los epics en la metodología ágil son similares a las historias y epics
en el cine o la literatura. Una historia es una narración sencilla; una serie de historias
relacionadas e interdependientes conforman un epic. Lo mismo se aplica a la gestión de trabajo,
donde la finalización de historias relacionadas conduce a la finalización de un epic. Las historias
cuentan el trabajo completado mientras que los epics comparten una perspectiva de alto nivel del
objetivo común.

En un equipo ágil, las historias son algo a lo que el equipo puede comprometerse a acabar en un
sprint de una o dos semanas. Muchas veces, los desarrolladores pueden trabajar en decenas de
historias al mes. Los epics, en cambio, son pocos y tardan más en completarse. Los equipos
suelen tener dos o tres epics que tratar de completar cada trimestre.

Si tu empresa quiere lanzar cohetes al espacio y mejorar el servicio de retransmisión de los

lanzamientos, deberías estructurar tus historias como indicamos abajo.

Ejemplos de una historia ágil:

Los usuarios de iPhone necesitan acceder a una vista vertical de la alimentación en vivo
cuando utilizan la aplicación móvil.
Los usuarios de equipos de escritorio necesitan un botón de visualización en pantalla
completa en la esquina inferior derecha del reproductor de vídeo.
Los usuarios de Android deben estar vinculados al Apple Store.

Aprende a configurar historias (llamadas también "tiques") en Jira Software

Las anteriores historias están relacionadas entre sí y podrían considerarse tareas independientes
que conducen a la realización de un trabajo de mayor volumen (un epic). En este caso, el epic
podría ser "mejorar el servicio de retransmisión del lanzamiento del primer trimestre".

La organización del trabajo en historias y epics también os ayuda a tu equipo y a ti a comunicaros

de manera eficaz dentro de la organización. Si te encargabas de informar del progreso del equipo
al responsable de ingeniería, hablarías de epics. Si, en cambio, comentabas detalles con un
compañero de tu equipo de desarrollo, hablarías de historias.
Para ver definiciones completas, ejemplos y buenas prácticas, consulta
los siguientes artículos:

Orientador ágil: Epics

Orientador ágil: Historias

Iniciativas frente a epics ágiles

Del mismo modo que los epics están compuestos de historias, las iniciativas lo están de epics. Las
iniciativas ofrecen otro nivel de organización por encima de los epics. En muchos casos, una
iniciativa recopila epics de diversos equipos para lograr un objetivo mucho más ambicioso y
extenso que cualquiera de los epics en sí mismos. Mientras que un epic es algo que puedes
completar en un mes o un trimestre, las iniciativas suelen completarse en varios trimestres o
incluso un año.

Ejemplos de epics en una iniciativa:

Imaginemos que tu empresa de naves espaciales quiere reducir el coste por lanzamiento en un 5
% este año. Es un fantástico ajuste para una iniciativa, ya que ningún epic por sí solo podría
alcanzar un objetivo tan ambicioso. En dicha iniciativa, habría epics como "Reducir el consumo de
combustible en la fase de lanzamiento un 1 %", "Aumentar los lanzamientos por trimestre de 3 a
4" y "Bajar todos los termostatos de 22 a 21 grados #modopadre".

En Atlassian:

Internamente, llamamos a nuestras iniciativas "Tickets de PC". Los tickets de proyecto central (PC)
se configuran en Jira Software como nuestros epics. Cada equipo escoge sus cuatro o cinco
objetivos más importantes para el año en curso y establece los tickets de PC para cada uno de
ellos. Los fundadores y el equipo de gestión utilizan estos tickets de PC para comprender todo el
trabajo realizado en la empresa.

SIGUIENTE: Aprende a configurar epics ágiles

Iniciativas frente a temas

En muchas organizaciones, los fundadores y el equipo de gestión alientan la búsqueda de algún
destino ambicioso. Estos son los (a veces, muy cursis) objetivos que se anuncian cada año o cada
trimestre, y los temas son cómo realizas un seguimiento de ellos.

Las iniciativas son conjuntos de epics.

 Los temas son etiquetas que realizan el seguimiento de objetivos generales de la
organización.

Las iniciativas tienen un diseño estructural: albergan epics, y la realización de estos epics
conducirá a la finalización de la iniciativa. Los temas son una herramienta organizativa que te
permite etiquetar elementos del backlog, epics e iniciativas para comprender qué trabajo
contribuye a qué objetivos de la organización. Los temas deberían inspirar la creación de los epics
y las iniciativas, pero no tienen una estricta relación de 1 a 1 con ellas. Un tema para una empresa
de naves espaciales sería algo como "La seguridad ante todo".

A continuación, se muestra qué apariencia tienen los temas en Advanced Roadmaps for Jira:

En Atlassian:

Uno de nuestros temas este año es "Trabajo abierto". Esto es un impulso final hacia una mayor
transparencia, dentro y fuera de la empresa. Mi equipo está trabajando con este tema mediante
la realización de una retrospectiva pública sobre la metodología ágil. Pedimos a los
desarrolladores de software que reflexionen sobre su experiencia en el desarrollo ágil y que
tuiteen feedback con la etiqueta #RetroOnAgile. Como campaña de tres meses, hemos
desarrollado un epic para esto y lo hemos etiquetado con el tema "Trabajo abierto".

Estructuración del trabajo:

Adoptar una metodología ágil y una estructura no son cuestiones que se excluyan entre sí, y la
estructura que se presenta no tiene por qué ser genérica. El éxito se consigue cuando tu equipo y
tú comprendéis estos conceptos y sois capaces de adaptarlos a vuestras necesidades. Para
nosotros, esos son las historias, los epics, las iniciativas y los temas. Puedes ponerte en marcha
aprendiendo cómo configurar epics en Jira Software.

Epics ágiles: definición, ejemplos y plantillas

Usa los epics ágiles para segmentar un conjunto de trabajo grande en historias más pequeñas.

Resumen
Un epic ágil es un conjunto de trabajo grande que puede dividirse en tareas específicas (denominadas
“historias de usuario”) en función de las necesidades o solicitudes de los clientes o usuarios finales. Los
epics son una práctica importante para los equipos ágiles y de DevOps.

Al adoptar una metodología ágil y DevOps, un epic permite gestionar tareas.Se define como una
gran cantidad de trabajo que se segmenta en tareas específicas (llamadas “historias” o “historias
de usuario”) en función de las necesidades/solicitudes de los clientes o usuarios finales.
Los epics constituyen una forma útil de organizar el trabajo y de crear una jerarquía. La idea es
desglosar el trabajo en elementos que se puedan lanzar, de manera que los proyectos grandes se
puedan llevar a cabo efectivamente y tú puedas continuar proporcionando valor a tus clientes
con regularidad. Los epics ayudan a los equipos a desglosar su trabajo y, al mismo tiempo, a
seguir trabajando en pos de una meta más elevada.

Mantener la agilidad a la hora de organizar tareas de gran envergadura como los epics no es
tarea fácil (nunca mejor dicho). Sea cual sea el tamaño de tu organización, descubrir cuál es la
relación que tienen los epics con unas prácticas sólidas de metodología ágil y DevOps constituye
una destreza esencial.

¿Qué es un epic ágil?

Un epic es una gran cantidad de trabajo que se puede desglosar en varias historias de menor
tamaño, a veces denominadas "incidencias" en Jira. Los epics suelen abarcar a varios equipos en
varios proyectos, y puede incluso hacerse un seguimiento de ellos en varios tableros.

Los epics casi siempre se entregan a lo largo de una serie de sprints. A medida que un equipo
aprende más sobre un epic a través del desarrollo y los comentarios de los clientes, se irán
incorporando y eliminando historias de usuario según convenga. Esa es la clave de los epics
ágiles: el alcance es flexible, y se basa en los comentarios de los clientes y en la cadencia del
equipo.

Ejemplo de epic ágil

Pongamos que es el año 2050 y trabajamos para una organización de viajes espaciales de ocio.
Efectuamos alrededor de una docena de lanzamientos al año, así que ninguno de estos
lanzamientos es lo más grande que hacemos en un año, pero siguen distando mucho de ser una
tarea rutinaria y requieren muchas horas de trabajo. Semejante volumen resulta ideal para un
epic.
Ejemplo de epic: "Lanzamiento de turismo espacial para marzo de 2050" incluye historias de
elementos de trabajo rutinarios, así como otras destinadas a mejorar aspectos clave del
lanzamiento del transbordador, que pueden abarcar ámbitos muy diversos, desde la compra de
billetes de viajes espaciales por parte de los clientes hasta el lanzamiento del propio cohete. Por
lo tanto, varios equipos contribuirán a este epic trabajando en una amplia gama de historias.

El equipo de software que respalda la compra de billetes para el lanzamiento de marzo de 2050
podría estructurar su epic como se indica a continuación:

Epic: Lanzamiento para

   
marzo de 2050

Historia: actualizar Historia: reducir el

intervalo de fechas para
incluir las fechas de
lanzamiento de marzo de
2050.
Historia: promocionar la oferta
tiempo de carga para las
veraniega en Saturno en la
listas de vuelos
página de confirmación de las
solicitados a < 0,45
reservas de Primera clase.
segundos

Al mismo tiempo, los equipos de propulsión podrían contribuir al mismo epic con estas historias:

Epic: Lanzamiento para marzo de

   
2050

Historia: Mantener la presión de los Historia: reducir el Historia: contratar nuevo

depósitos de combustible por consumo total de ingeniero de propulsión para
encima de las 250 ppm en el combustible en un reemplazar a Gary.
lanzamiento 1 %. #garygate2050

Los epics en el marco de un programa completo de

metodología ágil
Un epic debería ofrecer al equipo de desarrollo todo lo que sus miembros necesitan para tener
éxito. Desde un punto de vista práctico, es la máxima categoría de su jerarquía de trabajo. Sin
embargo, comprender cómo se relaciona un epic con otros elementos ágiles proporciona un
contexto importante para el trabajo de desarrollo diario.

Una hoja de ruta de un producto es un plan de acción de cómo un producto o una solución
evoluciona a lo largo del tiempo.
Un tema es un objetivo de la organización en el cual se inspiran los epics y las iniciativas.
La hoja de ruta de un producto se expresa y visualiza como un conjunto de iniciativas
organizadas en un cronograma.
Desglosar iniciativas en epics ayuda a mantener el trabajo diario del equipo (que se expresa
en historias más pequeñas) conectado a los objetivos de la empresa generales.

Un conjunto de epics completados impulsa una iniciativa específica, que hace que el producto en
general continúe desarrollándose y evolucionando al compás de las demandas del mercado y de
los clientes, así como de los temas de la organización.
Si volvemos al ejemplo anterior, uno de los temas podría ser aumentar los lanzamientos de
transbordadores espaciales, la hoja de ruta se encaminaría a incrementar el número de
lanzamientos trimestrales de 3 a 4, las iniciativas consistirían en reducir los costes y vender más
billetes, y cada epic pasaría a formar parte de las iniciativas.

Creación de un epic ágil

Cuando crees un nuevo epic, ten en cuenta otras herramientas de planificación y organización de
las que es posible que ya disponga el equipo. La creación de epics basándote en los objetivos y
resultados clave trimestrales del equipo es un buen comienzo. Cuando crees un epic, piensa en lo
siguiente:

Creación de informes: crea epics para los proyectos que querrán tener controlados los
gerentes y ejecutivos.
Narración: usa epics y las historias que surgen en ellos como mecanismo para contar cómo
llegaste al estado actual de una función o un producto.
Cultura: deja que la cultura de la organización dicte el tamaño y el nivel de detalle de un
epic.
Tiempo: la mayoría de equipos de desarrollo dependen de marcos de estimación en lugar
del tiempo, pero merece la pena asegurarse de que los epics tendrán un par de semanas de
duración. Ni demasiado tiempo ni demasiado poco.

Descubre cómo funcionan los epics en Jira.

Desglose de un epic ágil

Desglosar un epic en historias más prácticas ayuda a comprender un proyecto y a mantener la
motivación, pero puede ser una tarea abrumadora para los novatos. No hay una solución
universal para la creación de historias a partir de un epic, pero hay muchas buenas opciones que
puedes considerar:

Función de usuario o perfil: crea una historia independiente para cada perfil de usuario.
“Inicio de sesión más rápido para nuevos usuarios”, “inicio de sesión más rápido para
clientes que vuelven”, etc.
Pasos ordenados: desglosa el proceso y crea una historia para cada paso.
 Cultura: deja que las normas del equipo dicten si una historia es una tarea rápida o un
proyecto de una semana completa.
Tiempo: a menos que haya alguna otra convención preestablecida, diseña historias que
puedan completarse en un sprint o menos.

No existe ninguna definición universal que establezca una distinción clara entre una historia de
gran tamaño y un epic. En general, debería considerarse como epic cualquier volumen de trabajo
que el equipo calcule que tardará "semanas" (o más) en terminar (en lugar de "horas" o "días") y,
como tal, debería desglosarse en historias más pequeñas.

Medición de los epics ágiles

Se pueden usar gráficas de trabajo pendiente para visualizar los epics y, además, estas sirven
para mantener a los equipos motivados y a las partes interesadas ejecutivas informadas. En una
buena gráfica de trabajo pendiente de un epic es donde la agilidad de la organización brilla con
verdadera luz propia.

La gráfica de trabajo pendiente de un epic muestra la cantidad estimada y real de trabajo que hay
que hacer en un sprint o un epic. El eje de abscisas indica el tiempo, mientras que el de
ordenadas representa las historias o las incidencias.

Utiliza la gráfica de trabajo pendiente para hacer un seguimiento de todo el trabajo restante y
para determinar las probabilidades de cumplir el objetivo del sprint. Supervisar el trabajo total
restante a lo largo de la iteración permite al equipo gestionar su progreso y responder en
consecuencia.

Al analizar una gráfica de trabajo pendiente queda claro cómo progresa el equipo y dónde están
los impedimentos. La posibilidad de ver con claridad estos datos mantiene a todo el mundo en
sintonía y promueve un diálogo abierto sobre la evolución del producto y las previsiones de
finalización. ¡Por no mencionar que la transparencia genera confianza!

Descubre cómo configurar gráficas de trabajo pendiente en Jira Software

Optimiza tus epics con la automatización
Cuando domines el arte de crear epics e historias, quizá quieras ir más lejos y optimizar procesos
con la automatización. En Jira, estas son tres de las reglas de automatización más habituales para
sprints.

1. Añade automáticamente 3 historias tras la creación de un epic. Ir a la regla

2. Cierra automáticamente historias cuando el epic se marque como finalizado. Ir a la regla
3. Cambia el estado de un epic cuando cambie el estado de una de las incidencias vinculadas. Ir
a la regla

Consulta estas reglas de automatización y centenares más en la Biblioteca de plantillas de Jira

Automation.

Ir a la biblioteca

Funcionamiento de los epics ágiles

Los epics no son los cimientos indiscutibles de un programa de metodología ágil, pero sí
representan en la práctica el eje motor de la mayoría de los equipos ágiles y de
DevOps.Comprender dónde encajan en un programa de metodología ágil sólido crea el contexto
necesario para tu trabajo, y desglosarlos en historias da impulso al proyecto.

Historias de usuario con ejemplos y plantilla

Las historias de usuario son tareas de desarrollo que se suelen expresar como "persona + necesidad +
propósito".

Resumen
Una historia de usuario es una explicación general e informal de una función de software escrita desde
la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software
valor al cliente.

Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de
software. Pero no lo son.

Un componente clave del desarrollo de software ágil es poner a las personas en primer lugar, y
las historias de usuarios ponen a los usuarios finales reales en el centro de la conversación. Las
historias utilizan un lenguaje no técnico para ofrecer contexto al equipo de desarrollo y sus
esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está compilando lo
que está compilando y qué valor crea.

Las historias de usuario son uno de los componentes centrales de un programa ágil. Ayudan a
proporcionar un marco centrado en el usuario para el trabajo diario, lo que impulsa la
colaboración y la creatividad y mejora el producto en general.

¿Qué son las historias de usuario ágiles?

Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un objetivo
final, no una función, expresado desde la perspectiva del usuario del software.

Una historia de usuario es una explicación general e informal de una función de software escrita
desde la perspectiva del usuario final o cliente.
El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará un
valor particular al cliente. Ten en cuenta que los "clientes" no tienen por qué ser usuarios finales
externos en el sentido tradicional, también pueden ser clientes internos o colegas dentro de tu
organización que dependen de tu equipo.

Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el resultado
deseado. No entran en detalles, ya que los requisitos se añaden más tarde, una vez acordados
por el equipo.

Las historias encajan perfectamente en marcos ágiles como scrum y kanban. En el scrum, las
historias de los usuarios se añaden a los sprints y se "queman" a lo largo del sprint. Los equipos
de kanban introducen las historias de usuario en su backlog y las ejecutan siguiendo su flujo de
trabajo. Es este trabajo sobre las historias de usuario lo que ayuda a los equipos de scrum a
mejorar en la estimación y planificación del sprint, lo que conduce a un pronóstico más preciso y
a una mayor agilidad. Gracias a las historias, los equipos de kanban aprenden a gestionar el
trabajo en curso (WIP) y pueden perfeccionar aún más sus flujos de trabajo.

Las historias de usuario son también los componentes básicos de los marcos ágiles más grandes,
como los epics y las iniciativas. Los epics son grandes elementos de trabajo divididos en un
conjunto de historias, y varios epics constituyen una iniciativa. Estas estructuras más grandes
garantizan que el trabajo diario del equipo de desarrollo contribuya a los objetivos de la
organización incorporados en los epics y las iniciativas.

Más información sobre epics e iniciativas

¿Por qué crear historias de usuario?

Para los equipos de desarrollo nuevos en la metodología ágil, las historias de usuario a veces
parecen un paso más. ¿Por qué no dividir el gran proyecto (el epic) en una serie de pasos y seguir
adelante? Pero las historias dan al equipo un contexto importante y asocian las tareas con el valor
que estas aportan.

Las historias de usuario tienen varios beneficios clave:

Las historias centran la atención en el usuario. Una lista de tareas pendientes mantiene
al equipo centrado en tareas que deben completarse, pero un conjunto de historias lo
mantiene centrado en solucionar problemas para usuarios reales.
Las historias permiten la colaboración. Con el objetivo definido, el equipo puede
colaborar para decidir cómo ofrecer un mejor servicio al usuario y cumplir con dicho
 objetivo.
Las historias impulsan soluciones creativas. Las historias fomentan que el equipo piense
de forma crítica y creativa sobre cómo lograr mejor un objetivo.
Las historias motivan. Con cada historia el equipo de desarrollo disfruta de un pequeño
reto y una pequeña victoria, lo que aumenta la motivación.

Descubre cómo funcionan las historias de usuario en Jira Software

Trabajar con historias de usuario

Una vez que se ha escrito una historia, es hora de integrarla en tu flujo de trabajo. Por lo general,
una historia la escribe el propietario del producto, el gestor del producto o el gestor del
programa, y la envía para su revisión.

Durante una reunión de planificación de sprint o iteración, el equipo decide qué historias
afrontará en ese sprint. Los equipos discuten los requisitos y la funcionalidad que requiere cada
historia de usuario. Esta es una oportunidad para ponerse técnico y creativo en la
implementación de la historia por parte del equipo. Una vez acordados, estos requisitos se
añaden a la historia.

Otro paso común en esta reunión es calificar las historias en función de su complejidad o tiempo
hasta su finalización. Los equipos usan las tallas de las camisetas, la secuencia de Fibonacci o el
Planning Poker para hacer las estimaciones adecuadas. Una historia debe ser de un tamaño que
pueda completarse en un sprint; por lo tanto, cuando el equipo establezca las especificaciones de
cada historia, se deben asegurar de dividir las historias que superen ese horizonte de finalización.

Cómo escribir historias de usuario

Piensa en lo siguiente cuando escribas historias de usuario:

Definición de “Listo”: la historia suele estar “lista” cuando el usuario puede completar la
tarea descrita, pero debes asegurarte de definir lo que representa completarla.
Describe tareas o subtareas: decide qué pasos específicos deben completarse y quién es
responsable de cada uno de ellos.
Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, considera crear varias
historias.
Pasos ordenados: escribe una historia para cada paso en un proceso más grande.
Escucha el feedback: habla con los usuarios y capta sus problemas o necesidades en lo que
dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de
tus clientes.
Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el
tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias
deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses
deberían dividirse en historias más pequeñas o considerarse un epic independiente.

Una vez que las historias de usuario estén definidas de forma clara, debes asegurarte de que
todo el equipo pueda verlas.

Plantilla y ejemplos de historias de usuario

Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:

“Como [perfil], [quiero] [para].”

Desglosemos esta estructura:

 “Como [perfil]”: ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el
perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte
hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa
y cómo se siente. Sentimos empatía por Max.
“Quiere”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están
intentando lograr realmente? Esta descripción debería realizarse con independencia de las
implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás
cometiendo un error.
“Para”: ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el
beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?

Por ejemplo, las historias de usuario pueden tener este aspecto:

Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio juntos.
Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor control.
Como gestor, quiero poder comprender el progreso de mis compañeros, para poder
informar sobre nuestros éxitos y fallos.

Esta estructura no es obligatoria, pero resulta de ayuda para establecer una definición de
"hecho". Cuando ese perfil puede alcanzar su valor deseado, la historia está completa.
Recomendamos a nuestros equipos definir su propia estructura, y que no se desvíen de ella.

Introducción a las historias de usuario ágiles

Las historias de los usuarios describen el por qué y el qué que hay detrás del trabajo diario de los
miembros del equipo de desarrollo; a menudo las historias de usuario se expresan de la siguiente
manera: perfil + necesidad + propósito. Entender su papel como fuente de verdad para lo que el
equipo está entregando, pero también el por qué, es clave para un proceso sin problemas.

Empieza por evaluar el siguiente gran proyecto o el más apremiante (por ejemplo, un epic).
Divídelo en historias de usuario más pequeñas y trabaja con el equipo de desarrollo para
mejorarlo. Una vez que tus historias están fuera, donde todo el equipo puede verlas, ya tienes
todo listo para empezar a trabajar.

Puntos de historia y estimación

Una buena estimación ayuda a los propietarios de los productos a optimizar sus procesos en términos
de eficiencia e impacto. Por eso es tan importante.

Resumen
La estimación es complicada. Para los desarrolladores de software, es uno de los aspectos más difíciles
de su trabajo, por no decir el más difícil. Conlleva tener en cuenta un montón de factores que ayudan a
los propietarios de los productos a tomar decisiones que afectan a todo el equipo, así como a la
empresa. Con todo eso en juego, no es de extrañar que todos, desde los desarrolladores hasta la alta
dirección, tiendan a perder los estribos sobre este tema. Craso error. La estimación en la
metodología ágil no es más que eso, un cálculo: no es un juramento de sangre.

No es obligatorio trabajar los fines de semana para compensar el tiempo de más que nos lleva un
trabajo que habíamos subestimado. Dicho eso, veamos algunas maneras de realizar estimaciones
con la mayor precisión posible.
Colaboración con el propietario del producto
En un desarrollo ágil, el propietario del producto se encarga de priorizar el backlog, es decir, la
lista ordenada de trabajo que contiene descripciones breves de todas las funciones y
correcciones de un producto. Los propietarios del producto capturan los requisitos de la
empresa, pero no siempre entienden los detalles de la implementación. Por ello, una buena
estimación puede informar al propietario del producto sobre el nivel de esfuerzo de cada
elemento de trabajo, que a su vez sirve para evaluar la prioridad relativa de cada elemento.

Cuando el equipo de ingeniería empieza su proceso de estimación, normalmente surgen

preguntas sobre los requisitos y las historias de usuario. Esto es algo positivo: las preguntas
ayudan a todo el equipo a entender el trabajo mejor. Específicamente en el caso de los
propietarios de los productos, la división granular de los elementos de trabajo y las estimaciones
les ayudan a priorizar todas las áreas del trabajo, incluidas las que pueden estar ocultas. Con las
estimaciones del equipo de desarrollo en la mano, no es extraño que un propietario del producto
reordene los elementos del backlog.

La estimación ágil es un trabajo en equipo

Involucrar a todo el mundo (desarrolladores, diseñadores, testers, deployers... todos) en el
equipo es clave. Cada miembro del equipo aporta una perspectiva diferente sobre el producto y
el trabajo necesario para entregar una historia de usuario. Por ejemplo, si la gestión de productos
quiere hacer algo que parece sencillo, como admitir un nuevo navegador web, el desarrollo y el
control de calidad deben dar su opinión también, ya que su experiencia les ha enseñado qué
dragones pueden estar al acecho bajo la superficie.

Asimismo, los cambios de diseño requieren no sólo la aportación del equipo de diseño, sino
también la del de desarrollo y la del de QA. Dejar a parte del equipo de producto más amplio
fuera del proceso de estimación crea estimaciones de menor calidad, baja la moral porque los
contribuyentes clave no se sienten incluidos y compromete la calidad del software.

No dejes que tu equipo sea víctima de las estimaciones poco precisas. Es un camino seguro al
fracaso.

¿Quieres probar los puntos de historia? En primer lugar, regístrate o inicia sesión en Jira
Software >>

Prueba este tutorial interactivo para configurar tu primer proyecto de scrum

Aprende a configurar estimaciones y a realizar el seguimiento de las historias de usuario

Puntos de historia frente a horas

Los equipos de software tradicionales proporcionan estimaciones en un formato de tiempo
concreto: pueden ser días, semanas o meses. Sin embargo, muchos equipos ágiles han decidido
pasarse a los puntos de historia. Se trata de unidades de medida que permiten expresar una
estimación del esfuerzo total que deberá hacer el equipo para implementar íntegramente un
elemento del backlog del producto o cualquier otro trabajo. Los equipos asignan puntos de
historia en función de la complejidad y del volumen del trabajo, así como del riesgo o de la
incertidumbre. Los valores se asignan para desglosar el trabajo de forma más eficaz en partes
más pequeñas. De esta manera, se puede gestionar la incertidumbre. Con el tiempo, esto ayuda a
los equipos a ser conscientes de lo que pueden llegar a conseguir en un período de tiempo
concreto y genera un sentimiento de consenso y compromiso con la solución. Aunque pueda
parecer contradictorio, esta abstracción es realmente útil, ya que obliga al equipo a tomar
decisiones más complejas sobre la dificultad del trabajo. A continuación, se indican algunos
motivos por los cuales es recomendable utilizar puntos de historia:
 Las fechas no tienen en cuenta el trabajo no relacionado con el proyecto que
inevitablemente surge en nuestro día a día, como correos electrónicos, reuniones y
entrevistas en las que un miembro del equipo puede participar.
Las fechas tienen una connotación emocional. La estimación relativa elimina este
componente.
Cada equipo estima el trabajo en una escala ligeramente diferente, lo cual significa que su
velocidad (medida en puntos) será diferente, como es natural. Asimismo, esto imposibilita
que se politiquee usando la velocidad como arma.
Una vez que se llegue a un acuerdo sobre el esfuerzo relativo del valor de cada punto de
historia, podrás asignar puntos rápidamente sin que haya lugar a demasiado debate.
Los puntos de historia recompensan a los miembros del equipo por resolver incidencias
basándose en la dificultad, y no en el tiempo empleado. De esta forma, los miembros del
equipo se mantienen centrados en entregar valor, no en el tiempo dedicado.

Lamentablemente, los puntos de historia se suelen utilizar de forma incorrecta; por ejemplo,
cuando se emplean para juzgar a las personas o para asignar cronogramas y recursos detallados,
o bien cuando se confunden con una medida de productividad. La auténtica función de los
puntos de historia es que los equipos puedan hacerse una idea del volumen de trabajo y saber
qué partes tienen prioridad. Para ver un debate en profundidad sobre los puntos de historia y las
prácticas relacionadas con las estimaciones, échale un vistazo a esta mesa redonda con expertos
del sector. Si quieres más consejos sobre la estimación ágil, sigue leyendo.

Puntos de historia y póker de planificación

Los equipos que se estén iniciando en los puntos de historia usan un ejercicio llamado póker de
planificación. En Atlassian, el póker de planificación es una práctica habitual en toda la empresa.
Los miembros del equipo toman un elemento del backlog, hablan sobre él brevemente y cada
uno fórmula mentalmente una estimación. A continuación, todos levantan una tarjeta con el
número que refleje su estimación. Si todo el mundo está de acuerdo, ¡estupendo! De lo contrario,
dedica algo de tiempo (no mucho, tan solo un par de minutos) para entender el motivo detrás de
las distintas estimaciones. Recuerda, sin embargo, que la estimación debe ser una actividad de
alto nivel. Si el equipo se va por las ramas, respira hondo y encauza el debate a un nivel más
general.

¿Listo para intentarlo?

Instala esta Aplicación de póker de planificación

Obtén más información sobre el póker de planificación

Mantén las estimaciones a un alto nivel. Si el equipo se va por las ramas, respira hondo y deriva el
debate a un superior. #AgileTips

Estima con mayor inteligencia, no con mayor esfuerzo

Ninguna tarea individual debe superar las 16 horas de trabajo. (Si usas puntos de historia, puedes
decidir que 20 puntos es el límite superior, por ejemplo). Sencillamente, es demasiado
complicado estimar elementos de trabajo individuales de mayor duración con confianza. Esa
confianza es especialmente importante para los elementos en la parte superior del backlog.
Cuando algo se estima por encima del límite de 16 horas (o 20 puntos) del equipo, será una señal
para dividirlo granularmente y volver a estimarlo.
Para los elementos que se encuentren más abajo en el backlog, basta con una estimación
aproximada. Cuando el equipo empiece a trabajar en esos elementos, los requisitos podrían
haber cambiado y la aplicación seguramente habrá cambiado también, de modo que las
estimaciones no serán tan precisas. No pierdas tiempo estimando trabajo que posiblemente
cambiará. Da al propietario del producto una cifra aproximada que pueda utilizar para priorizar la
hoja de ruta del producto adecuadamente.

Aprende de las estimaciones anteriores

Las retrospectivas constituyen un momento para que el equipo incorpore ideas de iteraciones
anteriores, incluida la precisión de sus estimaciones. Hay muchas herramientas ágiles (como Jira
Software) que realizan el seguimiento de los puntos de historia, cosa que facilita en gran medida
el análisis y el recalibrado de las estimaciones. Prueba, por ejemplo, a comparar las cinco últimas
historias de usuario que haya entregado el equipo con un valor de 8 puntos de historia. Estudia si
cada uno de estos elementos de trabajo tuvo un nivel de esfuerzo similar. Si no, analizad por qué.
Utilizad esta información en los siguientes debates de estimaciones.

Al igual que el resto de los aspectos de un proceso ágil, la estimación es una cuestión de práctica.
Irás mejorando con el tiempo.

¿Qué es un diagrama de Gantt?

Descubre qué son los diagramas de Gantt y cómo pueden ayudarte a gestionar proyectos ágiles.

Resumen
El diagrama de Gantt es una herramienta de gestión de proyectos en la que se recoge la
planificación de un proyecto. Normalmente tiene dos secciones: en la parte izquierda se incluye
una lista de tareas y, en la derecha, un cronograma con barras que representan el trabajo. Los
diagramas de Gantt también pueden incluir las fechas de inicio y de finalización de las tareas, los
hitos, las dependencias entre tareas y las personas asignadas. Para cumplir con las demandas del
desarrollo de software moderno, las herramientas de hoja de ruta como Jira Software incluyen
funciones como una estructura de tareas plegable y paneles de gestión de recursos. Estas
herramientas de hoja de ruta ayudan a los equipos a mantener una estrategia coherente en los
proyectos a pesar de la naturaleza iterativa de los procesos de desarrollo de software.

Orígenes del diagrama de Gantt

A principios del siglo XX, Henry Gantt revolucionó la gestión de proyectos con los diagramas de
Gantt que, por aquel entonces, se trazaban en hojas de papel. Con el uso creciente de los
ordenadores en la década de los 80, los diagramas de Gantt se volvieron cada vez más complejos
y elaborados. Hoy en día, los diagramas de Gantt siguen siendo una de las herramientas de
gestión de proyectos más utilizadas.

En la actualidad, las herramientas de diagramas de Gantt suelen denominarse "herramientas de

hoja de ruta". Jira incluye dos herramientas de hoja de ruta que puedes utilizar para crear
diagramas de Gantt sobre tus proyectos: Roadmaps, que crea planes en torno a las incidencias de
Jira asignadas a un equipo, y Advanced Roadmaps, que hace lo mismo teniendo en cuenta varios
equipos y organizaciones.
Roadmaps

Hojas de ruta avanzadas

¿Para qué se utiliza un diagrama de Gantt?

Los gestores de proyectos utilizan los diagramas de Gantt con tres fines principales:

Crear y gestionar un proyecto completo

Los diagramas de Gantt sirven para visualizar los componentes básicos de un proyecto y para
organizarlo en tareas más pequeñas y gestionables. Las pequeñas tareas resultantes se
programan en la línea de tiempo del diagrama de Gantt, junto con las dependencias entre las
tareas, las personas asignadas y los hitos.

Determinar la logística y las dependencias de las tareas

Los diagramas de Gantt se pueden utilizar para supervisar la logística de un proyecto. Las
dependencias de tareas hacen que una tarea nueva solo pueda iniciarse una vez que se haya
completado otra. Si una tarea se retrasa (nos puede pasar a cualquiera), las incidencias asociadas
se reprograman automáticamente. Esto puede ser especialmente útil cuando se planifica en un
entorno con varios equipos.
Supervisar el progreso de un proyecto

A medida que los equipos registran el tiempo que van a dedicar a incidencias en el plan, puedes
supervisar el estado de los proyectos y realizar los ajustes necesarios. Tu diagrama de Gantt
puede incluir fechas de lanzamiento, hitos y otras métricas importantes para supervisar el
progreso del proyecto.

Ventajas de utilizar un diagrama de Gantt

Hay dos razones principales por las que los diagramas de Gantt son tan apreciados en la gestión
de proyectos. Por un lado, facilitan la creación de planes complejos, especialmente aquellos en
los que participan varios equipos y cuyos plazos cambian. Los diagramas de Gantt ayudan a los
equipos a planificar el trabajo basándose en los plazos y a asignar los recursos correctamente.

Por otro lado, los gestores de proyectos utilizan los diagramas de Gantt para tener una visión
general de los proyectos. En ellos se representan, entre otras cosas, la relación entre las fechas de
inicio y finalización de las tareas, los hitos y las tareas dependientes. Los programas modernos de
diagramas de Gantt, como Jira Software con Roadmaps y Advanced Roadmaps, sintetizan la
información y muestran cómo afectan las elecciones a los plazos.

Diagramas de Gantt: planificación basada en la metodología ágil y en

cascada

Los diagramas de Gantt pueden ser una herramienta muy útil tanto para las metodologías en
cascada como para las ágiles.

En cascada

El modelo en cascada de planificación de proyectos sigue un enfoque lineal, en el que los

requisitos del cliente y de las partes interesadas se recogen al principio del proyecto. Luego, los
gestores de proyectos elaboran un plan secuencial para el proyecto, que incluye hitos y plazos.
Cada parte del proyecto depende de la finalización de las tareas anteriores. Este modelo es muy
adecuado para los equipos que se centran en procesos (como la construcción o la fabricación), y
no tanto para aquellos que se dedican a la creación de ideas o resolución de problemas, ya que
los pasos deben planificarse con antelación.

Los diagramas de Gantt son un sistema que gusta especialmente a los gestores de proyectos que
utilizan el modelo en cascada. Determinan un calendario de proyectos dividiéndolos en
elementos de trabajo manejables y asignando fechas de inicio y finalización. También son útiles
para identificar los hitos importantes de un proyecto. Los hitos son logros que los equipos deben
alcanzar en el plazo previsto o antes de que este se cumpla. Son opcionales pero recomendables.

Agile

Por otro lado, el modelo ágil de planificación de proyectos valora la flexibilidad y la adaptabilidad.
En lugar de crear un cronograma completo con fechas establecidas, los equipos ágiles dividen los
proyectos en iteraciones más pequeñas (también conocidas como sprints). Al comienzo de un
sprint, el equipo planifica su trabajo en función de los objetivos del proyecto para las dos
semanas siguientes. Una vez que el sprint ha terminado, los logros y acontecimientos resultantes
ayudan a crear el plan para el próximo sprint.

Un diagrama de Gantt puede mostrar el impacto que los cambios en una sola tarea pueden tener
en todo el plan o en toda la hoja de ruta del producto. Esto resulta esencial para los equipos
ágiles, ya que el feedback de las partes interesadas es un aspecto importante de la metodología.
Uso de los diagramas de Gantt
Los diagramas de Gantt siguen siendo un importante instrumento de gestión de proyectos en
diversos sectores. A finales de la segunda década del siglo XXI, el Project Management Institute
llegó a la conclusión de que solo el 11 % de las organizaciones eran totalmente ágiles. La mayoría
de las organizaciones emplean metodologías de gestión de proyectos en cascada (generalmente,
en niveles de gestión superiores), además de las ágiles. A esto se le denomina "enfoque híbrido".
Si te centras en las fechas y los plazos, entonces probablemente te encuentres entre quienes
necesitan diagramas de Gantt basados en el tiempo.

Jira Software incluye dos funciones de hoja de ruta distintas, cada una con un enfoque
ligeramente diferente. Jira Roadmaps es una herramienta diseñada para supervisar el trabajo
asignado a un solo equipo, mientras que Advanced Roadmaps está indicada para la planificación
de proyectos más grandes y en los que participen varias organizaciones.

Jira Roadmaps: diagramas específicos de proyectos

En la captura de pantalla anterior, hecha en Roadmaps, se muestra un diagrama de Gantt

específico de un proyecto, que se suele utilizar a nivel de equipo o de departamento. En el
diagrama se muestra cómo el equipo está supervisando el trabajo para alcanzar sus objetivos. La
estructura de desglose del trabajo plegable permite a los gestores de proyectos obtener una
visión general de las historias cruciales del proyecto.

Advanced Roadmaps: diagramas de organización de alto nivel

Roadmaps ofrece una planificación rápida y sencilla que ayuda a los equipos a gestionar mejor
sus dependencias y a hacer un seguimiento del progreso general en tiempo real. Estas hojas de
ruta a nivel de proyecto o de equipo son útiles para la planificación a nivel de equipo de tareas de
gran volumen.

Las hojas de ruta de Advanced Roadmaps son ideales para planificar, gestionar y hacer un
seguimiento del trabajo de varios equipos o incluso de toda la organización. Permiten adaptarse
en función del trabajo.
Los programas diseñados con flujos de trabajo entre equipos ofrecen herramientas más
avanzadas, como las funciones de gestión de capacidad y de planificación automática, para la
creación de planes más complejos. También incluyen diversas opciones de visualización con las
que puedes personalizar el diagrama de Gantt para destacar un aspecto determinado de tu plan
al presentarlo.

Conclusión
Los gestores de proyectos y líderes del sector utilizan el software más puntero de diagramas de
Gantt, como Jira Software con Roadmaps y Advanced Roadmaps, para ayudar a las
organizaciones a alcanzar sus objetivos. Ya sea que se planifique un proyecto complejo o se
supervise el progreso de la empresa, las herramientas de diagramas de Gantt como estas son
muy escalables e igualmente aplicables a los niveles de cartera, grandes soluciones, programa y
equipo, según las directrices de SAFe®.

Consulta más información acerca de cómo pueden ayudarte Roadmaps y Advanced Roadmaps a
la hora de planificar tu próximo proyecto. Empieza a usar hoy mismo la versión de prueba
gratuita de Jira Software Cloud.

Gestión de programas vs. gestión de

proyectos
Cómo trabajan en conjunto la gestión de programas y la gestión de proyectos para mejorar el
desempeño organizacional.

Los programas y proyectos están en el corazón de muchos esfuerzos comerciales. Para usar una
metáfora, los proyectos son como trenes operados por gerentes de proyecto que ayudan a
impulsar el trabajo de un equipo para lograr metas y finalmente llegar con un bien o servicio
terminado.

Para continuar con la metáfora, el programa es como una colección de trenes que circulan por
diferentes vías, pero que se dirigen a la misma estación u objetivo. El director del programa es el
conductor de la estación y dirige los distintos trenes del proyecto.

Qué es la gestión de programas?

La administración de programas es el proceso de administrar programas asignados a los
objetivos comerciales que mejoran el desempeño organizacional. Los gerentes de programa
supervisan y coordinan los diversos proyectos y otras iniciativas estratégicas en toda la
organización.
Los gerentes de programas también ayudan a impulsar el cambio organizacional al ayudar con
transformaciones ágiles, incluida la implementación de prácticas y principios de DevOps. Los
gerentes de programas pueden alinear las prácticas y procesos de gestión de programas con
valores ágiles como la colaboración, la autonomía y el empoderamiento del equipo, la entrega de
valor a los clientes y la adaptación al cambio en el momento. Un administrador de programas
puede dar vida a DevOps y ágilidad a equipos en programas grandes o proyectos individuales al
adaptar los programas a los requisitos y oportunidades específicos del negocio.

Gestión de programas vs. gestión de proyectos

La gestión de programas a veces se confunde con la gestión de proyectos. La gestión de

proyectos es el proceso de liderar un proyecto realizado por un equipo para lograr ciertos
objetivos, como la construcción de un nuevo producto.

Un proyecto representa una pieza de trabajo única y enfocada con un alcance específico y un
resultado definido. Los proyectos pueden durar varios años, pero su enfoque principal sigue
siendo el mismo. El éxito de un proyecto se puede medir mediante la entrega de artefactos y
productos que se acumulan en los objetivos más amplios de un programa.

La gestión de proyectos es el proceso de entrega de valor que hace avanzar gradualmente un

programa. A pesar del énfasis en los artefactos y los entregables, la gestión de proyectos todavía
implica estrategia y planificación, ya que un director de proyecto debe determinar cómo cumplir
con los objetivos establecidos al principio del proyecto. Una vez que un proyecto está en marcha,
el gerente de proyecto rastrea el progreso, asigna recursos, administra riesgos, comunica y más.

La gestión de programas implica la gestión de un programa con múltiples proyectos relacionados.

Dado que los programas están vinculados a iniciativas estratégicas, a menudo son de larga
duración y posiblemente permanentes. Los programas continúan a través del cambio
organizacional, contribuyen a múltiples objetivos y contienen muchos proyectos que entregan
componentes específicos de la iniciativa estratégica más grande.
Los proyectos tienen:

Un conjunto de tareas con un entregable claro y una fecha límite para su finalización
Relación con la creación, actualización o revisión de un documento, proceso, resultado u otra
unidad de trabajo en particular.
Un alcance predefinido que se limita a una salida específica
Mejora la calidad, la eficiencia, la gestión de costes o la satisfacción del cliente de forma
específica y predeterminada

Los programas tienen:

Plazos desconocidos o fluidos debido al gran alcance e impacto del trabajo que debe
realizarse de forma continua durante un largo período de tiempo
Múltiples entregables con dependencias interrelacionadas que pueden continuar
evolucionando en función de las cambiantes necesidades comerciales.
Una serie de entregables completados juntos para aumentar la eficiencia, precisión,
confiabilidad u otras necesidades comerciales.
El trabajo permite a la empresa lograr un objetivo o iniciativa comercial a largo plazo que se
ejecutará a perpetuidad.
El éxito ofrece beneficios a largo plazo o desbloquea nuevas capacidades para la
organización.

Qué hace un gestor de programas?

Los administradores de programas deben equilibrar la entrega de artefactos, la participación en

las decisiones estratégicas, la gestión de las partes interesadas y la mitigación de riesgos en todo
el programa. En un programa organizacional totalmente empoderado, los gerentes de programa
deben poder resolver, o conectarse con personas que pueden resolver, y planificar la mitigación
de cualquier problema que afecte la iniciativa estratégica que buscan lograr.

Debido a la amplitud de sus responsabilidades, los directores de programas desempeñan un

papel clave en las empresas. El rol es flexible por diseño para enfrentar los diferentes desafíos
que enfrentan los equipos mientras pasan a producción.

En un día cualquiera, un director de programa puede realizar cualquiera de las siguientes tareas:

Evaluar el estado de la cartera

El gerente del programa revisa y evalúa una cartera o portfolio conectándose con equipos para
identificar cualquier mitigación de riesgos o mejora oportuna. Estas conexiones pueden ser
charlas de café o reuniones de equipo. El objetivo del director del programa es mantenerse
conectado y comprometido lo suficiente como para trabajar al unísono hacia objetivos
compartidos. Esto incluye conectarse con los equipos del proyecto para garantizar que los
gerentes del proyecto sean compatibles y desbloqueados.

Gestionar el riesgo

La gestión de riesgos es un elemento clave de la gestión de carteras. Los riesgos incluyen un

retraso en el cronograma del proyecto, cambios en los requisitos o el descubrimiento de partes
interesadas adicionales. El director del programa debe estar al tanto de todo lo que pueda afectar
el progreso o el resultado del programa y los proyectos relacionados. Idealmente, un gerente de
programa puede tomar acciones correctivas para reducir o administrar los riesgos en la cartera.

Ejecuta el programa

Los gerentes de programa son responsables de ejecutar el programa, que incluye:

Gestionar presupuestos y recursos en cooperación con los directores de proyectos.

Definición de los parámetros de funcionamiento y controles.
Mantener los elementos centrales del programa que sientan las bases de los estatutos del
equipo y otros documentos de establecimiento.

Interactuar con las partes interesadas

El director del programa se conecta con las partes interesadas para tener una idea del contexto
más amplio que rodea a los objetivos. Estas conversaciones brindan información clave sobre el
panorama general. Al asociarse con las partes interesadas, el director del programa puede ayudar
a guiar a los equipos del proyecto.

Refinar el modelo operativo

El modelo operativo da forma al modo en que los equipos progresan hacia sus objetivos. Esto
puede incluir el establecimiento de canales de comunicación y métodos de presentación de
informes, la identificación de objetivos y el establecimiento de prioridades en todo el programa.
Durante el curso de un programa, el administrador del programa optimiza el modelo operativo
para aumentar la probabilidad de éxito y reducir el impacto del riesgo.

Decisiones de apoyo

La toma de decisiones adopta muchas formas, desde la realización de una reunión con los
responsables de la toma de decisiones hasta la recopilación de información básica sobre las
decisiones necesarias o la realización de un análisis comparativo de múltiples opciones. Los
administradores de programas específicos pueden inclinarse hacia diferentes áreas,
dependiendo de sus fortalezas. El director del programa revisa los resultados para identificar
oportunidades de mejora en sistemas, procesos o resultados.
El enfoque y el alcance de cada gerente de programa dan forma a los detalles de cómo se
involucran con estas prácticas.

¿Qué hace un jefe de proyecto?

Un día típico para un gerente de proyecto puede incluir:

Verificación del estado de un entregable para determinar si se entregará a tiempo y dentro

del presupuesto
Revisar una cola para identificar nuevos trabajos, monitorear las tareas existentes y
desbloquear elementos específicos para el equipo del proyecto.
Crear un plan sobre cómo alcanzar un hito específico que describa la gestión de las partes
interesadas y las oportunidades de comunicación.
Asegurar que el trabajo del proyecto cumpla con los requisitos de calidad y confiabilidad
establecidos al inicio del proyecto.

Como puede ver, los directores de programas y proyectos trabajan en tareas muy relacionadas.
La principal diferencia entre estos dos roles es el alcance y la ambigüedad:

Los proyectos tienen un alcance estricto y se controlan desde el principio, mientras que los
programas tienen un alcance más amplio que puede cambiar en el transcurso del
programa.
Los proyectos tienen una ambigüedad limitada porque el éxito se ha definido claramente al
principio, mientras que los programas deben superar la ambigüedad para definir qué se
debe hacer y cómo conceptualizar el "éxito" del programa en general.

Administrador de Programas Administrador de Proyectos

Planifica estrategias Planifica proyectos

Brinda asesoramiento a las partes Realiza un seguimiento del progreso de los

interesadas proyectos

Revisar y asesorar en proyectos Asignar recursos

Ofrece auditorías y control de calidad Gestiona Riesgos

Tutoría a equipos de proyectos Comunica

En conclusión ...
El Program Management Institute observa (https://www.pmi.org/learning/featured-topics/progra
m) que "las organizaciones con una gestión de programas madura tienen mucho más éxito que
aquellas que no la tienen". Esto se debe a que la gestión de programas permite a las
organizaciones lograr una mejor alineación con los objetivos estratégicos, la gestión de las
interdependencias de los proyectos, una mejor gestión de los recursos y más.

Jira Align proporciona funciones de gestión de programas que conectan la estrategia empresarial
con la ejecución técnica. Sus características de administración de programas incluyen tableros de
programas visuales, previsión y simulación, seguimiento de programas, hojas de ruta de varios
niveles, administración de dependencias y más.