Dado: Una empresa que utiliza el Marco Agile Escalado (SAFe) para escalar el desarrollo Agile en toda la organización; 10 equipos de desarrollo combinados en un gran equipo (Agile Release Train, según la terminología SAFe) para entregar un producto común; la necesidad de una planificación trimestral de dos días (PI Planning) para determinar el plan de trabajo de los equipos de TI para los próximos 3 meses *; tres oficinas de desarrollo con una distancia entre las más remotas de más de 6 mil kilómetros y la diferencia de tiempo de trabajo correspondiente de 5 horas; experiencia previa en planificación que implicaba el uso de pizarras analógicas / pizarras / marcadores / notas adhesivas y la presencia física respectiva de todos los empleados clave en la misma habitación.
* Esta construcción de peso pesado "El plan de trabajo de los equipos de TI para los próximos 3 meses" amenaza con aumentar significativamente el tamaño del texto, por lo que en lo sucesivo voy a reemplazarlo con "el compromiso". En consecuencia, elaborar y adoptar un plan de trabajo será "comprometerse".
¿Por qué necesitamos esto?
1) Fatiga con métodos de trabajo análogos. Mientras las naves espaciales están arando el espacio, y Elon Musk está aburriendo sus túneles, nosotros, los muchachos de TI, hemos estado escribiendo persistentemente con marcadores en notas adhesivas pegándolas en los pizarrones: realmente hay algún tipo de disonancia en esto, ¿no es así? ? Así era nuestro compromiso hace un tiempo:
Sí, esta es una hoja de papel de aproximadamente 2 por 5 metros de tamaño, con cada nota adhesiva que se convertirá en una tarea JIRA después de la planificación ...
2) Fatiga de nuestros colegas nómadas. A pesar de que nuestra oficina central se encuentra en un país bastante agradable y cálido, el año pasado me sorprendió descubrir que están lejos de estar contentos con todos los viajes de ida y vuelta. Mis argumentos "Oh, bueno, puedes divertirte relajándote al sol en la playa" no fueron recibidos muy cálidamente. Al final resultó que no todos están listos para frecuentes viajes de negocios, que a menudo no son bienvenidos por sus familias, algunos colegas simplemente no podían soportar todo el tiempo en el aire considerando las distancias entre las oficinas y la frecuencia de las reuniones.
3) Involucrar a más colegas de TI en el proceso de planificación. Como queda claro en el párrafo anterior, difícilmente podríamos permitir que todo el personal de TI de las tres oficinas viniera a la planificación, por lo que solo se seleccionaron los Elegidos, lo que excluyó a los demás del proceso. Esto no fue beneficioso para el espíritu de equipo en general.
4) Optimización de costos. Sí, este es un momento delicado: hay muchas personas clave y hacer que vuelen de un lado a otro cuatro veces al año no es nada barato.
Parte Cero: Trabajar con la cartera de pedidos
Todo comienza mucho antes que la planificación real. Para trabajar productivamente en el Compromiso durante la planificación, debe tener algo por lo que comprometerse. Para asegurar esto, tengo que "cargar" a los dueños de negocios con el trabajo en iniciativas probables (o, en terminología SAFe, Epics, pero en adelante usaré nuestro término habitual) lo antes posible. Idealmente, este proceso debería estar completamente divorciado de la naturaleza iterativa de la planificación trimestral y seguir su propio camino Kanban. Tomamos SAFe Portfolio Kanban como base:
Tenemos un proyecto JIRA separado con tres tipos de problemas: epopeyas, iniciativas empresariales e iniciativas arquitectónicas; así como la correspondiente Junta Kanban. El algoritmo para el Propietario de Negocio de la Iniciativa es simple: agrega un problema a este proyecto, y va a Backlog por defecto, que es el primer estado de nuestro flujo Kanban:
Embudo:
Aquí se almacenan las iniciativas que aún no están listas para su revisión. El propietario del negocio trabaja en el contenido de la Iniciativa hasta que se sienta listo para el siguiente paso. Lo mínimo requerido en esta etapa es haber completado los campos de Enunciado del problema, Resultado deseado y Medida del éxito, así como una presentación un poco más detallada, pero simple y clara. En esta etapa, es importante dejar de lado las soluciones técnicas y centrarse en los parámetros del negocio. Cuando se recopilan todos los datos, el Propietario del negocio mueve la tarea al siguiente estado:
Revisión.Realizamos revisiones semanalmente para iniciativas empresariales y arquitectónicas. Idealmente, esta es una presentación de cinco minutos con preguntas y respuestas posteriores. Como resultado de la Revisión, se toma una decisión sobre lo que sucederá luego con la Iniciativa. Puede:
- ser devuelto a Funnel para su revisión,
- ser abolida sin posibilidad de una vida futura (en este caso, uso un estado especial Desactualizado oculto en el tablero Kanban),
- ser aprobado y trasladado a la siguiente etapa: análisis.
En esta etapa nosotros - ¡Yippee! - finalmente puede involucrar a los chicos de TI: analistas, arquitectos, leads, cualquiera. Por "nosotros" me refiero a mí mismo como ingeniero de trenes de lanzamiento. Pero, idealmente, también deberían ser los Empresarios, quienes ya han adquirido la experiencia y la autonomía necesarias para involucrar a los equipos correctos y lanzar análisis de forma independiente. De nuevo, estoy escribiendo sobre el caso ideal aquí. De hecho, el nivel de autoorganización de nuestros colegas es variable, y en algunos casos piden ayuda de un facilitador especialmente designado, pero trato de alejarme de esta práctica.
El propósito de esta etapa es el análisis preliminar o, como lo llamamos, predescubrimiento. Como resultado, deberíamos obtener un mínimo que nos permita comprometernos: soluciones propuestas, riesgos y dependencias, requisitos no funcionales y de infraestructura, mapas de usuarios, esquemas arquitectónicos. Además, les pedimos a los equipos que den una evaluación preliminar en los puntos de la historia a nivel de características, esto nos permitirá determinar las prioridades al final del trimestre.
En esta etapa, se crea una Junta Kanban personal para cada Iniciativa, en la que se pueden ver características e historias, con un enlace preliminar a una iteración específica, que es proporcionada por un flujo de trabajo JIRA separado. Entonces, al cambiar el estado, podemos asignar el problema a alguna iteración. Los Swimlanes en Kanban Boards están configurados por equipos de desarrollo. Dado que nuestro ecosistema JIRA es bastante complicado, durante el predescubrimiento y el descubrimiento creamos tareas en proyectos separados para no ensuciar los atrasos de los equipos:
También en la etapa previa al descubrimiento, involucramos a arquitectos o, como se ha practicado con frecuencia últimamente, a su gente de confianza: "Embajadores de EA". Su tarea es transmitir la visión del departamento de arquitectura a todos los participantes, ayudar a encontrar la mejor solución y, finalmente, aprobar esta solución con el Jefe de Arquitectura Empresarial de la empresa.
Cuando todas las personas involucradas creen que la Iniciativa se ha analizado lo suficiente y está lista para el siguiente paso, se pasa al siguiente estado:
Cartera acumulada.En esta etapa, es importante llevar a cabo una priorización de WSJF (
trabajo más corto ponderado primero ). Para hacer esto, tenemos una gran reunión 3 semanas antes de la planificación, que, lamentablemente, hasta ahora siempre ha durado muchas horas. Durante esta reunión, los miembros del Consejo de Administración evalúan el valor comercial, la crítica del tiempo, la reducción de riesgos y la habilitación de oportunidades con la ayuda del póker de planificación alineado con Fibonacci:
Para poder rastrear el historial de iniciativas, para cada una de ellas agrego una etiqueta en JIRA con datos trimestrales: 2018T4, 2019T1, etc.
Mirando hacia el futuro, permítanme describir todos los estados posibles. Después del compromiso final en PI Planning, las iniciativas exitosamente
implementadas se trasladan al estado de
Implementación , mientras que las 'no adaptadas' reciben el estado
Estacionado y podrían considerarse para los próximos trimestres. Las iniciativas entregadas se mueven al estado
Listo .
Como resultado, tenemos la siguiente imagen en el tablero de Kanban:
Por supuesto, aún no estamos en el medio de nuestro camino, pero por el momento ya puedo notar que gracias a la implementación de la cartera de pedidos
- Los dueños de negocios han comenzado a trabajar a través de sus Iniciativas en detalle y prepararse a fondo para la Revisión.
- Las revisiones se han vuelto más meticulosas en el buen sentido.
- Los equipos tienen más tiempo para el predescubrimiento.
- No pierdo viejas iniciativas: siempre puedo volver a las iniciativas estacionadas, no entregadas u olvidadas, y trabajar en ellas.
Herramientas utilizadas en esta etapa:
- Servidor de software Atlassian Jira
- Colores de complementos para Jira: para resaltar iniciativas empresariales y arquitectónicas
- El complemento 'Estructura - Gestión de proyectos a escala' - para visualizar la estructura hecha de Iniciativas y características que les pertenecen, y su priorización WSJF
- Atlassian Confluence - fuente de documentación interna
- Lucidchart y sus complementos para Jira y Confluence - para dibujar diagramas
Parte I. Preparación para la planificación de PI
Un mes antes de PI Planning es cuando llega el momento más ocupado. Deben tenerse en cuenta demasiadas cosas, y para no dejar nada fuera, tengo que crear un formulario de Google "logístico" de varias páginas. Permítanme describir las pestañas más importantes de este formulario y las actividades que las rodean.
Retroalimentación Unos días después de cada planificación de PI llevamos a cabo una retrospectiva, que nos ayuda a no olvidar a qué conclusiones llegamos y cómo necesitamos ajustar el curso. Esta es una parte importante en términos de mejora continua.
Preparación técnica Con la transición a la planificación remota, han aparecido solicitudes específicas, como la calidad de la conexión a Internet (priorización y optimización de rutas para JIRA y Confluence) y presencia de video y audio (utilizamos los kits Logitec Group, los micrófonos Jabbra y los auriculares personales en varias combinaciones , cámaras web, software de zoom para videoconferencia).
Facilitadores Es una lista de empleados responsables de la facilitación en cada uno de los grupos de trabajo, indicando su ubicación y un enlace al canal Zoom permanente del grupo de trabajo.
Audiencia La lista completa de todos los invitados.
Lista de verificación La lista completa de tareas importantes con plazos y personas responsables. Para darle una idea a continuación, puede encontrar varios ejemplos de las tareas más típicas y vitales relevantes para cada planificación de IP: capacitación de facilitadores (se ha preparado un manual de capacitación con todos los pasos necesarios, como organizar un equipo de trabajo, programar las reuniones y descomponer la Iniciativa en una lista de características); actualización de los planes de ubicación de los grupos de trabajo para cada oficina; control de la actualización de Velocity para todos los equipos de desarrollo; ordenar comidas; crear informes de trimestres anteriores; impresiones de listas de iniciativas y horarios.
Parte II. Planificación de PI y el proceso de compromiso
Después de todos los preparatorios, finalmente llega este momento: el comienzo de PI Planning. En dos días tenemos que descubrir todas las iniciativas, asegurarnos de que la información sea suficiente y comprometernos. Después de algunas charlas, los grupos de trabajo van a sus lugares y se ponen a trabajar. En este momento, el número de grupos se distribuye entre las tres oficinas como 4x4x2, y los usuarios remotos están conectados al grupo requerido a través de un canal Zoom dedicado.
Al completar el Descubrimiento en cada una de estas Iniciativas, el facilitador se asegura de que todos los datos necesarios, como Criterios de aceptación, solución técnica, riesgos, dependencias, la necesidad de una nueva infraestructura, estén disponibles y marquen la Iniciativa con el 'IT Sesión finalizada 'casilla de verificación para un fácil seguimiento del progreso. Después de eso, el grupo de trabajo puede pasar a la próxima Iniciativa.
Después de una docena de PI Plannings, la sensación de estar bajo constante estrés y presión de tiempo, que estuvo con nosotros desde el principio, se ha desvanecido significativamente, y ahora todo se parece más al trabajo como de costumbre. En la tarde del primer y segundo día de la Planificación, es el momento de un compromiso sin prisas de acuerdo con las prioridades. Para realizar un compromiso, tengo varias estructuras separadas. El primero es una estructura que contiene una lista de características e historias programadas para el compromiso:
Desafortunadamente, esta estructura en la captura de pantalla contiene solo tareas que no se ajustan al compromiso del trimestre actual, por lo que la muestra no es representativa. En cualquier caso, en el campo de búsqueda puedo seleccionar la Iniciativa necesaria en orden de prioridad por número, que se coloca en un campo separado para cada característica e historia, cambiar el estado de los problemas de Planificado a Comprometido y ponerlos en la iteración deseada , comprometiéndose por ellos:
Como resultado, el problema desaparecerá de esta estructura y aparecerá en una nueva, que refleja el creciente compromiso:
Como puede ver en la captura de pantalla, en esta estructura las historias caen en la carpeta del equipo de desarrollo al que pertenecen y se agrupan por iteración. Aquí, veo la velocidad total del equipo en el nombre de la carpeta, y además en la columna Compromiso, el exceso de compromiso se determina y resalta automáticamente para cada equipo, mediante el uso de una fórmula personalizada.
Por supuesto, si las iniciativas de primera y más alta prioridad se incluyen en un compromiso en su mayoría fácilmente, pronto, a medida que más y más equipos llenen sus trabajos pendientes hasta el final, podría haber problemas respectivos con algunas de las iniciativas, después de ciertos argumentos y discusiones. pospuesto (estacionado) como resultado.
Al final de este proceso bastante sencillo, los equipos juran cumplir su compromiso con la bandera de la compañía (ok, no realmente) y se apresuran a sus hogares (bueno, una vez más, no realmente, la mayoría huyen a algún bar para celebrar).
Herramientas utilizadas en esta etapa:
- Servidor de software Atlassian Jira
- El complemento 'Estructura - Gestión de proyectos a escala' - para monitorear el proceso de descubrimiento y durante la ejecución del compromiso.
Parte III Clonación de problemas en el ecosistema JIRA de la empresa.
Mientras todos beben, el RTE está trabajando en la creación de compromisos en la forma en que podría distribuirse a los retrasos de los equipos de desarrollo y monitorearse durante todo el trimestre. Para hacer esto, utilizo el complemento 'Bulk Clone Professional for Jira': agrega un elemento que hace clonación colectiva al menú Bulk Change y tiene características necesarias como clonación de enlaces, actualización de enlaces entre clones recién creados, actualización de enlaces épicos, adición de resumen prefijo y etiquetado automático:
Agrego estado como prefijo, porque en la etapa de planificación los estados reflejan la iteración planificada de finalización. Como resultado, puedo ver de inmediato en el Resumen cuando planeamos terminar la función o la historia.
Al principio, clono absolutamente todos los problemas en un proyecto Global Backlog separado, ya que tenemos épicas en él y necesito tener conexiones reales de historias épicas en tareas recién clonadas. Y ya como segundo paso, hago solicitudes JQL para cada equipo de desarrollo por separado y muevo las historias a los proyectos de trabajo de los equipos.
Como resultado, creo una estructura que refleja el Compromiso actual y consta de historias finales, que luego uso para monitorear:
En general, las ventajas de este enfoque son las siguientes:
- Es más fácil para un técnico de TI escribir nuevas características e historias en lugar de escribirlas con un marcador en una nota adhesiva.
- Muchas cosas, como la capacidad restante y la actualización de WSJF según las estimaciones de las historias, se calculan automáticamente mediante fórmulas personalizadas.
- Gracias a la clonación, el Compromiso original se conserva para la historia y siempre podemos volver a él.
- Nos ahorra tiempo y energía en la etapa de preparación de la planificación: el manejo del papel requiere energía.
- Por supuesto, es genial que ya no necesitemos agregar problemas a JIRA escribiendo notas adhesivas.
Herramientas utilizadas en esta etapa:
- Servidor de software Atlassian Jira
- El plugin 'Bulk Clone Professional para Jira': para clonar características e historias en proyectos JIRA en funcionamiento.
- El complemento 'Estructura - Gestión de proyectos a escala' - para la creación de la estructura de Compromiso final.
Epílogo
Queridos amigos, por supuesto, entiendo que la descripción general anterior es bastante superficial, y muchas cosas podrían revelarse de manera más detallada: monitorear la distribución de la capacidad entre las iniciativas empresariales y arquitectónicas y las tareas operativas, calcular fórmulas personalizadas en estructuras, administrar riesgos y mucho mas Pero todavía no sé si este tema es interesante para el público y, en caso afirmativo, qué exactamente. Si veo algún interés, estaré encantado de compartir mi visión sobre los temas relevantes.
Y una cosa más: es difícil de creer que sea posible, pero aún así me gustaría evitar en los comentarios los detalles relacionados con los administradores ágiles, los marcos, los efectivos y los "efectivos". Recuerde que describí la parte técnica de todo el proceso con la esperanza de interesar a las personas cercanas al tema, y espero con interés los debates pertinentes.
¡Nos vemos en los comentarios!