Deiser Blog | Atlassian | ITSM | DevOps | Agile at Scale | Cloud

Jira Software: ¿Cómo planificar PI respetando SAFe®?

Escrito por Software Plant | 19-feb-2019 8:59:26

Si implementas Jira Software como Dios manda es complicado que un equipo eche a perder 20.000 horas de trabajo en un solo día. ¿Cómo puede ocurrir esto? Muy fácil: por una mala planificación de los incrementos de programa (en inglés, Program Increments, o sencillamente PI).

Utilizar Jira Sofware para hacer SAFe® es tan crítico que todos los miembros del Agile Release Train, es decir, todos los componentes de los equipos ágiles, se reúnan físicamente en un único espacio para realizar la planificación de los PI, que algunos de nuestros clientes han programado vuelos charter para juntar a sus empleados. Sin embargo, según el entusiasmo se va disipando con el paso del tiempo los equipos distribuidos se suelen arrimar a alguna herramienta que les permita llevar a cabo la planificación de los PI de forma remota.

Exactamente ¿Qué es lo más complicado al implantar SAFe®?

Durante el proceso de promoción de esta publicación surgió la siguiente duda uno de nuestros seguidores en Twitter (aparte de una mención especial de Claudio Ombrella) preguntando: ¿Cuál es la mayor complicación al momento de implantar el framework SAFe®? Los mismos Software Plant respondieron que básicamente es identificar las dependencias de la colaboración entre equipos y la preparación de un plan de acción adecuad.

La conversación completa (inglés) la puedes leer al hacer clic en el siguiente tweet:

 Jira Software y BigPicture son una suite adecuada para planificar PI, pero antes de revisar paso a paso cómo se hace, conviene aclarar una recomendación de SAFe® bastante controvertida:  

Use no tools for PI planning.

¿Por qué no usar una herramienta de software?

Puede que te llame la atención si el mundo de SAFe® es relativamente nuevo para ti, pero lo cierto es que Scaled Agile Inc. recomienda oficialmente que no se utilicen herramientas de software para planificar PI. Sal de Jira, júntate con todos tus equipos en una sala de eventos y no te salgas de los post-it que vais pegando en los swimlanes dibujados en la pared. Aunque la recomendación se hace en aras del trabajo en equipo, el compromiso y lo inmediato de anotar con rotuladores en un formato físicamente visible para cualquiera, la verdad es que hay dos problemas con este enfoque:

  •     Si tu empresa tiene equipos distribuidos en lugares muy remotos, que las sesiones de planificación de los PI sean presenciales puede ser muy costoso o directamente imposible.

  •     Cuando realmente llega la hora de ejecutar el PI, es posible que el pegamento de los post-it se haya secado

¿Entonces, qué es lo que se hace en la práctica? En cuanto se termina la sesión de planificación, todos los post-it se reflejan en Jira.  

Ahora es cuando aparece otro problema:

Por sí solo, Jira no permite la planificación de PI entre equipos

"SAFe® está muy extendido en sectores como el financiero, el sanitario o el tecnológico”, dice Tom Kucharski, CEO de SoftwarePlant y certificado en SAFe®. “El 99 por ciento de nuestros clientes necesitan poder planificar el trabajo de varios equipos en sus PI, pero Jira solo soporta la planificación ágil para un equipo a la vez. La situación empeora aún más cuando los equipos trabajan en localidades distintas, en un mismo país o incluso a escala global. Así es como comenzó la historia de BigPicture, una app de gestión de proyectos que cumple con las exigencias de SAFe®".

¿Cómo planificar tus PI con Jira + BigPicture?

Empecemos por un ejercicio sencillo: encuentra todos los términos que caen bajo la categoría de “tools” en el famoso póster del portfolio SAFe®. ¿Listo? 

Nosotros también hemos hecho la prueba. Roadmap, Backlog, Program Board y Objectives: todos ellos suenan a herramientas, así que los hemos marcado en los laterales del póster.

Además, consultando este excelente artículo de SAFe® sobre “PI planning”, no hemos podido evitar la matriz de riesgo a nuestra colección de herramientas para planificar incrementos de programa. Y si sigues buceando en la documentación del Scaled Agile Framework, seguro que llegas a la conclusión de que la vista de pájaro (‘Bird’s-eye view’) es uno de los términos más significativos de SAFe®.

Ahora que ya tenemos lista nuestra caja de herramientas para planificar PI, cabe preguntarse cómo transportarla a Jira. Aunque sería posible hacerse con varias apps del Marketplace de Atlassian, ¿por qué no hacerse con BigPicture 7, la app de gestión de proyectos que reúne todos los requisitos funcionales para cumplir con las exigencias de SAFe®? ¡Nos enorgullece ser el primer fabricante en el Marketplace que se ha centrado en este nicho!

Ahora, ¿Cómo se hace una planificación de PI con Jira + BigPicture?

 

PASO 1

Establecer los objetivos de los incrementos de programa en el roadmap SAFe® de BigPicture 7.
A la hora de planificar PI, hay dos tipos de objetivos: 1) los que abarcan a varios equipos, o ART (Agile Release Train, SAFe® Program level), que figuran en la fila superior de la siguiente ilustración; y 2) los objetivos a nivel de equipo.

Nota: ¿Cómo se pueden gestionar épicas de alto nivel en Jira + BigPicture + SAFe®? Las épicas de alto nivel suelen tener una duración suficiente para cubrir varios PI, por lo que no parece disparatado plantearse incluir la propia épica como objetivo en el PI 1, PI 2, PI 3, etcétera. La alternativa es crear un proyecto distinto en Jira y, a continuación, asignarle esas épicas de alto nivel. A continuación, las épicas se pueden gestionar con un sencillo tablero Kanban (‘To do – In Progress – Done’) en Jira, en lugar de en el roadmap.

PASO 2

¿No tienes claro qué planificar en el próximo incremento del programa? Apóyate en el módulo de alcance de BigPicture 7, algo así como la estructura de descomposición del trabajo de todo el programa, que a estas alturas ya debería haberse definido. Usa épicas e historias como objetivos de PI, en lugar de subtareas aisladas.

Ten en cuenta, sin embargo, que es conveniente reservar las tareas convencionales (historias, características,funcionalidades y épicas) para el tablero de dependencias en lugar del roadmap. Lo aconsejable para el roadmap es que, siendo una capa de negocio, se emplee un lenguaje compresible de mayor nivel y que no contenga referencias a cuestiones técnicas. Por ejemplo, “entregar la prestación A”.
 PASO 3

El tablero de dependencias (o Program Board 2.0) será lanzado a principios de 2019. Este tablero puede complementar el roadmap del paso 1 a nivel de PI.

PASO 4

Una vez el PI está planificado y se ha iniciado, llega el momento de iteraciones más granulares de la planificación, normalmente cada dos semanas. La planificación de las iteraciones se lleva a cabo con un tablero de dependencias.

A la espera de que el tablero de dependencias contenga los niveles de PI, es posible emplear la versión simplificada de BigPicture: con el nivel de la iteración. Aquí está la documentación (en inglés).
Una vez que se ha planificado tanto el PI como la iteración, ¿cómo pueden saber los equipos, cada uno en su propio terreno, qué tareas deberían completar? Hay dos caminos:

  •     El tablero de dependencias de BigPicture puede “enviar” tareas al tablero de cada equipo en Jira Software. En este enfoque se apuesta por terminar las cosas, ya que cada equipo verá exclusivamente las tareas que se le han asignado, sin ver las de otros equipos. Por supuesto, para que esto funcione, según la iteración avanza el tablero de dependencias de BigPicture se sincroniza con el tablero de cada equipo en Jira Software.
  •     Otro enfoque, que apuesta por la colaboración entre equipos, es tener como referencia el tablero general de dependencias de BigPicture. Las flechas verdes y rojas hacen que cada equipo pueda tener en cuenta a lo largo de la iteración las dependencias de sus esfuerzos con lo que están llevando a cabo otros grupos de trabajo.

Además, y siempre que la capacidad lo permita, cualquier equipo ágil puede añadir nuevos trabajos al panel de backlog que puede verse en el lateral derecho de la siguiente captura de pantalla.



PASO 5

Según se avanza en el Incremento de Programa, lo más habitual es que los equipos se den cuenta de que no podrán completar todos los objetivos que se habían marcado para ese PI. El mapa de dependencias del tablero del programa (program board) permite valorar cómo de grave es retrasarse en una u otra área. ¿Qué le dice cada flecha roja al team leader y al gestor del programa? Que la tarea de en cuyo origen se encuentra la dependencia ya tiene un fuerte retraso. Por el contrario, las flechas verdes indican que las dependencias no amenazan el cumplimiento de lo planificado.
 


PASO 6

¿Te acuerdas de los riesgos del proyecto? Una épica, una historia o una tarea cualquiera pueden representar un riesgo. Y para eso está la matriz de riesgos de BigPicture.

Al igual que la Work Breakdown Structure (WBS) o el alcance del proyecto, la matriz de riesgos se define al iniciar el proyecto. Es conveniente no perderla de vista y modificarla según sea conveniente durante la ida del proyecto.

Cualquier Release Train Engineer o product manager certificado en SAFe® se dará cuenta rápidamente de que la matriz es inconsistente con la técnica ROAM de SAFe® (las siglas viene de Resolve, Own, Accept, Mitigate). Sin embargo, tanto los títulos de los ejes, que por defecto se titulan con los tradicionales parámetros de probabilidad y severidad (consecuencia), como los valores que pueden asumir son completamente configurables y pueden adaptarse fácilmente.

Para incluir el marco ROAM en Big Picture:

  •     Administración de Jira (icono del engranaje) > Add-ons > Configuración del riesgo
  •     Administración de Jira (icono del engranaje) > Tareas > Campos customizables > Risk consequence/Risk probability > Configurar

PASO 7

Cuando se acerca el final del PI, los objetivos del mismo se pueden marcar en el roadmap de BigPicture como “entregados” o “fallidos”. En el ejemplo, la tarea “PIV-2 Testing” se ha añadido como objetivo al Program Increment 3. Eso se debe a que los objetivos a nivel de PI rara vez pueden expresarse con issues del backlog: se formulan durante las sesiones de planificación y emplean un lenguaje de negocio, como, por ejemplo, “lanzar el producto X a los clientes”. 

¿Estás listo para gestionar los niveles de Programa y Portafolio de SAFe® sin recurrir a software excesivamente complejo?  ¡Descarga la presentación para compartirla con tus compañeros!

Este artículo ha sido escrito originalmente por Marcin Gebicz y traducido al español por el equipo de DEISER.