Metodología BaP

Un poco de historia

Por allá por el 2018, cuando entré a trabajar a 2Brains como Frontend developer, conocí al que sería mi mentor en todo lo que son las metodologías ágiles: don Rodrigo Camacho. En ese tiempo integramos un equipo de increíbles profesionales, y como mi primera experiencia con estás metodologías, todo me era nuevo y conocido a la vez. No digo que antes haya trabajado mal, pero faltaban piezas. En este equipo aprendí nuevas formas de interactuar tanto con otros profesionales, como también con el cliente. Esto me llevó a estudiar mucho sobre todo este mundo, obteniendo mis primeras certificaciones.

Este conocimiento teórico hasta ese momento me traía mucha ansiedad y necesidad por ponerlo a prueba. Fue a sí como en mi segundo proyecto dentro de 2Brains me di la libertad de interactuar con referentes del cliente de varias áreas. Imagínenme, yo siendo solo un frontend, ser invitado a reuniones de metodología donde solo había líderes del cliente porque les parecía interesante mi punto de vista. Agradezco mucho la oportunidad en ese momento. Desgraciadamente estuve poco tiempo ahí.

Para cuando salté a trabajar en Globant, tenía muchas preguntas más: ¿Se pueden implementar todas estas cosas sin reventar a los equipos?, ¿Cómo controlas la incertidumbre y alto nivel de cambios que permite la metodología?, ¿Están los profesionales preparados para este tipo de mecanismos? ¿Existen herramientas que te faciliten la implementación?, etc, etc… No está demás decir que seguía estudiando y obteniendo certificaciones, pero me faltaban oportunidades para probar cosas. Una vez que me integré a mi primer proyecto con Globant, lo primero que vi fue un desorden importante por problemas de calidad profesional, y malas formas interpersonales de varios de los integrantes del equipo, además, de poca claridad en los requerimientos del cliente. Mucho de lo que hicimos fue por investigación paralela más que por objetivos e intenciones claras por parte de ellos. Fue aquí que se me presentó la primera oportunidad de hacer cambios.

Después de poco menos de un año en esa cuenta, me ofrecieron ser el líder técnico del equipo. Acepté medio desconfiado, pero era una oportunidad clara de implementar algunas cosas y probar herramientas. Para Globant el rol del líder técnico es de mucha importancia, y no solo involucra a los chicos de desarrollo, la compañía nos invita a involucrarnos con cada uno de los miembros del equipo. Para mi esto caía como "Anillo al dedo". Por mis estudios hasta el momento, podía hablar con cada miembro del equipo en su idioma disminuyendo la fricción en la comunicación. Esto generó mucha confianza con cada uno de ellos. Trabajé muy de la mano con las personas de control de calidad, aclarando con lujo de detalles los procesos, reglas de negocio, y casos de uso. También trabajé en la definición del diseño de producto tanto en UX como UI, y tuve un primer vistazo al interiorizarme en los alcances del rol del Business Analyst, desgraciadamente no con su mejor exponente, pero que de todos modos me sirvió bastante. Ya como TL se me abrieron las puertas para tratar directamente con referentes del cliente tanto en lo técnico, como en el negocio, por lo que me fui enterando de muchas cosas; justamente algunas de las piezas que me faltaban.

Para este momento me enfrentaba a una importante decisión. Había aceptado entrar a Globant con la idea de dejar de ser Desarrollador pero aún no sabía a qué rol apuntar. No es que no me gustará programar, me encanta, y aún lo sigo haciendo, pero descubrí que me molesta programar para otros… jajaja. Manejaba tres opciones para ese tiempo: Project Manager, Agile Coach, o Business Analyst. Con lo que ya había estudiado y practicado, me sentía capaz de iniciar el vuelo en cualquiera de ellos, por lo que empecé una investigación en los estudios de cada uno de estos roles. Para project Manager no me gustó la idea de que se alejaran tanto de la gestión del producto y la metodología; y aunque habían algunos que lo lograban hacer, la mayoría solo se enfoca en gestión de personas y dinero… no es lo mío. Para el caso del Agile Coach, me vi sorprendido con la cantidad de frustración en las personas que entrevisté; estudiando este rol me di cuenta que la agilidad no mueren en los equipos, sino más bien, en los mandos medios y altos. Nuevamente, se alejaba mucho del producto. Y llegué al Business Analyst. Cuando lo estudié tenía mucho de lo que buscaba, no me alejaba del producto, participaba de la investigación y definición, podía acercarme a los clientes, realizar investigación, e influir en la metodología.

Aquí debo hacer un apartado. Con el tiempo me di cuenta que Globant a deformado bastante el rol del Business Analyst. Si nos basamos en la IIBA, y su certificación, el BA busca apoyar la toma de decisiones analizando el negocio desde diferentes puntos de vista en pos de recomendar soluciones o acciones. Lo que presenta Globant como un Business Analyst es lo que los teóricos de la agilidad llaman Proxy product owner, que básicamente es un PO que no toma decisiones. Hasta el día de hoy no me molesta en demasía, ya que puedo influir en la toma de esas mismas decisiones de forma tranquila.

En mi primera experiencia como BA conocí a quién terminó siendo mi mentora del área de Producto, doña Gabriela Serralta, una product manager de lujo de quién aprendí mucho. Una pena no haber podido continuar trabajando juntos. La oportunidad que me dio basada en la confianza mutua me permitió probar muchas cosas tanto en metodología como en desarrollo de producto, gestión de equipos y sobre todo Política y habilidades blandas. Fue en este periodo que desarrollé la primera versión de BaP, la cuál ya he probado por cerca de 5 años con excelentes resultados.

Y hasta aquí la historia previa. Vamos con lo técnico...

¿Qué es BaP (Beyond a Plan)?

Lo primero que quiero mencionar es que cuando se trabaja en agilidad debes aceptar la frase "Bienvenido el cambio". Para muchos esto es un cliché y lo discuten con ánimos de refutarlo ya que les cuesta asumir que para eso están las metodologías ágiles, y que esto nos demanda desarrollar más habiliades blandas que técnicas. ¿Por qué lo menciono?, bueno, cuando un proyecto inicia y no se tiene claro cómo llevarlo acabo, pero si está bastante entendido cuál problema quieren resolver, se habla de alta incertidumbre.

Las metodologías ágiles, nos invitan a basicamente obedecer una estrategia adaptando la táctica constantemente. De esta forma, siempre estaremos atentos a cualquier cambio que se presente. Y con "cambio" me refiero a cualquier tipo que aparezca: se modifican los requerimientos, se tiene que cambiar la tecnología, debes cambiar el equipo de desarrolladores, cambiaron los tiempos, etc, etc. Cuando los requerimientos tienen alta volatilidad, y la tecnología a ocupar se debe validar sobre la marcha, es que un proyecto se vuelve Complejo, y lo que se demanda en ese momento es Adaptabilidad. De ahí que las metodologías se llaman "Ágiles". Qué tan rápido te ajustas al cambios y adaptas el plan para seguir mirando el mismo norte, o qué tanta información puedes obtener que refute la estrategia inicial, son parte de las preguntas que debes responder desarrollando tus habilidades de Comunicación y Negociación.

Y es ahí donde aparece la metodología BaP. Un set de herramientas muy conocidas y enlazadas de forma lógica con el propósito de tener la información necesaria para adaptarse al cambio.

Suena pretencioso, pero realmente funciona si te ordenas y aplicas diciplina. Imagina que colocas en una línea de trabajo todas las ideas más grandes y a medida que avanzas en los siete pasos que componen la metodología, vas atomizando las reduciendo la incertidumbre, el alcance, y aumentando la claridad que fortalece una buena táctica. No está demás decir que la metodología se fortalece con el trabajo en equipo y un buen liderazgo.

En la imagen a continuación pueden ver cómo se unen las diferentes metodologías para el desarrollo de producto desde la concepción de una idea, su construcción, y posterior maduración. Si bien estoy bastante seguro que BaP puede ser utilizado en todo el ciclo de vida de un producto, hasta ahora solo he podido probarlo en las etapas de construcción, eso quiere decir: Lean Startup y Agile.

Vamos parte por parte

Estaba difícil obtener una imagen clara de todas las herramientas enlazadas, así que te comparto este diagrama del flujo de trabajo. Como lo pueden apreciar, existe un orden donde en los primeros pasos se reciben las grandes ideas a ser estimadas. Mejor conocidas como Iniciativas, estas son tareas enormes con objetivos corporativos detras de su concepción. Esto quiere decir, que no se pueden llevar a cabo sin un análisis completo de viabilidad.

Se sigue con la identificación y priorización de requerimientos de cada iniciativa. Aquí ya pueden ver la primera acción concreta: "Divide y vencerás". Esto permite indentificar lo que realmente busca ganar el negocio o cuál necesidad el cliente/usuario quiere ver cubierta. Un rol muy importante en esta etapa es las del Product Manager para converger ambas ambiciones en algo abordable y definir una estrategia de producto.

Se sigue atomizando el trabajo, reduciendo la incertidumbre, y ganando en orden al pensar en cómo enfrentar el problema mediante la definición de épicas, aquí ya estamos pasando de la estrategia a la táctica por lo que el equipo de desarrollo debe empezar a estar presente.

El trabajo granular se desarrolla a partir del paso 5 con el uso del user story map, que permite a los equipos mirar en el tiempo qué tareas se deben realizar y en qué momento, manejando dependencias y recursos.

Toda la información anterior nos permite realizar la primera definición de roadmap de alto nivel y vislumbrar los primero hitos a cumplir, siempre consiedando recursos y tiempo disponible.

Otro detalle que pueden ver en este diagrama, es que cada paso incluye una forma de volver atrás en caso de que haya un cambio relevante que atender

• ¿Apareció un nuevo requerimiento?
• ¿Cambió una prioridad?
• ¿Existe una tarea demasiado difícil de realizar que impacta en la entrega?
• ¿No se cuenta con información para poder estimar?
• ¿Las tareas en el storymap (táctica) con cumplen con las estimaciones del roadmap (estrategia)?
• etc, etc

De esta forma puedes saber que al mover una pieza en cualqueira de las etapas qué tanto afectará en el plan, y tomar las acciones que se deban para ajustarlo. En otras palabras, ser Ágil.

Pero creo que ha sido mucha introducción, así que vamos al detalle del paso a paso, y así entenderán el propósito y el espítitu de esta metodología. No está demás decir que nada está escrito en piedra y que si quieren compartir sus opiniones conmigo, no duden en escribirme.

Los pasos son los siguientes:

0. Backlog de iniciativas
1. Priorización de iniciativas
2. Obtención de requerimientos
3. Importante vs Urgente
4. Mapa de épicas
5. Definir tática
6. Seguir la estrategia

[Paso 0] Backlog

Primero, la metodología BaP considera el tiempo como factor clave para la organización de los elementos, y dado que la representación clasica del tiempo es una línea que avanza de izquierda a derecha, es que ordené los pasos de la siguiente forma:

1. Won't have
2. Could have
3. Should have
4. Must have

Lo que hago es separar el primer paso, Won't have, para aislarlo y transformarlo en el backlog de las iniciativas. Aquí el líder de proyecto debe reunirse con todos los stakeholders y definir qué es lo que el negocio quiere realizar y dónde quieren llevar el producto, siempre considerando tecnología, experiencia de usuario, y negocio; puntos claves para la definición de un buen producto.

Lo que entre en este cuadro no debe ser priorizado aún. Aquí se produce la primera lluvia de ideas y entrada de requerimientos desde todas las partes involucradas. En otras palabras, "Pidan todo lo que quieran. Después veremos si se puede hacer.". Es importante dejar un título y descripción lo suficientemente claros para identificarlos rápidamente. En este punto es común que aparezcan muchas peticiones, sin embargo no les pondremos restricciones aún. Si lo ven como la estructura de un doble diamante , en este punto estamos abriendo el primero, por lo que se debe motivar y promover que aparezcan ideas.

Considerando lo anterior, cada stakeholder puede agregar lo que quiera mientras esté bien explicado. Así que agreguen cuadros de color gris sin límites, pero siempre con la moderación del líder de proyecto.

Finalmente, revisen el listado en búsqueda de poder agrupar temas que estén relacionados o cuya expectativa se común. De esta forma, empezarán a optimizar el backlog y no perderán tiempo en el futuro con temas ya abordados.

[Paso 1] Priorización

Ahora empezaremos a cerrar el primer diamante. No podemos hacer todo al mismo tiempo, por lo que es necesario obtener la prioridad de todo lo que su agregó al backlog.

Aquí es importante poner reglas claras ya que se podría poner muy complicada esta reunión. Piensa que habrá un grupo multidiciplinario que tiene una prioridad en sus cabezas e intentarán que sus ideas encabecen los esfuerzos. Es muy necesario desarrollar las habilidades de comunicación y negociación para no caer en espacios redundantes de discusión. Por lo tanto establezcan un listado criterios que definirán la priodidad, llámese, impacto, recursos, time-to-market, competencia, lo que se les ocurra relevante para el negocio.

Como dije en el paso 0, el segmento Wont have, quedó reservado ser le backlog, por lo que nos quedan los pasos: Could be, Should be, Must be. Debido al orden que se definió para este MoSCoW, puedes suponer que lo que está más a la derecha es lo primero que debe ser realizado. Dicho de otra forma, la prioridad está basada en el tiempo, por eso es que se posicionó el Must be en el extremo derecho. De esa forma, a medida que se vayan terminando cosas, lo de más a la izquierda irá avanzando hacia a la derecha. Además de el orden por tiempo, pueden ver que las iniciativas se apilan en una columna ordenada de abajo hacia arriba considerando la prioridad de ellas en ese segmento.

Finalmente, debes dar un color a cada iniciativa que entre en prioridad. ¿Por qué es importante?, primero, porque ayudará a identificar el origen de un requerimiento, en los pasos sigueintes, manteniendo siempre el contexto y el alcance claros. Además, la paleta de colores que permite un contraste suficiente para identificar todo a simple vista, es bastante reducido, y no tendrás más de 10 colores. Esto está hecho intencionalmente. De esta forma, podrán controlar la carga de trabajo incluso tomando en cuenta este detalle: "No puedo agregar más iniciativas porque no tengo más colores, y nos podríamos confundir." ... jajajaj

Stakeholders

Quiero hacer un paréntesis importante aquí. Desde ahora en adelante, es sumamente importante identificar quiénes son tus stakeholders; básicamente porque es deber del líder del proyecto saber quienes son los interesandos en el producto y cual es su poder sobre la toma de decisiones.

No es complicado y existen una infinidad de herramientas para crear este mapa. Si bien puedes usar una planilla o un documento corriente, también puedes usar una de estas dos buenas opciones, que además te dará un par de herramientas interesantes y bastante usadas.

• Mapa de stakeholders: Es una matriz de 2x2 que permite posicionar a cada un de acuerdo a que tan involucrados están en el producto. Puedes ver más detalles aquí
• Matriz RACI: Es otra forma de agrupar a las personas de acuerdo a sus responsabiliadades dentro del proyecto. Puedes ver más detalles aquí

[Pasos 2 y 3] Obtención y priorización de requerimientos

Una vez que las iniciativas tienen su primera bajada, y ramarco "primera bajada" porque todo puede cambiar en cualquier momento, y por lo mismo se debe estar atento intentando preveer cualquier escenario que requiera volver atrás y repriorizar. En fin, una vez se tienen las iniciativas y su prioridad, vamos a analizar en detalle las que calleron en el segmento de MoSCoW Must have.

En este análisis debiesen participar los stakeholders identificados en esas iniciativas, y deseablemente, los referentes de cada área de la construcción: Diseñadores, Desarrolladores, Aseguradores de Calidad, etc. Aquí empezamos a abrir el segundo diamante de la metodología, por lo que necesitamos pasara de un equipo multidiciplinario a un interdiciplinario. ¿Porqué lo enfatizo?, bueno, porque a partir de ahora empezaremos a identificar problemas específicos y soluciones relativas.

[Paso 2] Obtención

Llegó el momento de profundizar en las peticiones de los stakeholders, y para esto necesitamos obtener el detalle de lo que implica para el negocio, la experiencia de usuario, y tecnología actual, llevar a cabo esta petición o necesidad. Pero, ¿Qué es un requerimiento?, bueno, es una descripción detallada de una necesidad específica que el producto debe satisfacer. Estos requerimientos pueden ser funcionales (lo que el producto debe hacer) o no funcionales (cómo debe ser el producto, como rendimiento, seguridad o usabilidad). Su correcta definición y gestión son cruciales para guiar el diseño, desarrollo y pruebas del producto, asegurando que cumpla con las expectativas de los usuarios y los objetivos del negocio.

Teniendo eso en cuenta, es que el paso 2 de la metodología BaP nos invita a agrupar cada requerimiento junto a su iniciativa separándolos en Funcionales y No Funcionales. Es importante que cada nuevo requerimientose agrupe y colorée como su iniciativa. De esta forma cuidamos la cooerencia y el alcance de estos. En este paso, no se pide priorizar. Tal como en el paso 0, la idea es que surgan todas las necesidades y peticiones sin filtros. Nuevamente se necesita una lluvia de ideas. Son todas los criterios de aceptación que los stakeholders (e incluso el mismo equipo) identifiquen como necesarios para dar por cumplida la iniciativa.

Como todas estas iniciativas entraron en el Must be done del paso 1, no es que algo se pueda dejar de hacer. Todo es importantísimo.

[Paso 3] Priorización

Para definir la prioridad, esta vez usaremos la clásica matriz de Eisenhower, pero con un cambio para acomodarla a esta metodología. Este cambio consiste en que la prioridad de construcción se ordena desde arriba a la derecha donde estará lo primero que se debe hacer, hasta abajo a la izquierda, donde estará lo último en construirse. Y aquí quiero hacer énfasis en eso. Esta priorización no es para ver qué se debe hacer, ya que todo "must be done". Lo que busca este paso es saber en qué orden debe ser llevado a cabo.

Por lo anterior, es que situaremos cada requerimiento en un orden ascendente desde el cuadro No importante/No urgente hacia el cuadro Important/Urgente, intentando alinear cada requerimiento a la diagonal. Esta etapa también debe tener un acuerdo previo para establecer los criterios para ordenarlos. Tanto el equipo como los stakeholders debe estar alineados desde este punto para no caer en malos entenidos o iteraciones forzadas por malos entendimientos. Consideren que entre más adelante estemos en este proceso, más costoso será volver atrás y reacomodarse.

Teniendo las reglas de priorización claras, es cosa de desarrollar el o los workshops necesarios hasta llegar a un acuerdo que permita avanzar por lo menos con lo que quede en el cuadro urgernte/importante. Pero no olviden la sabia frase "Que lo urgente no mate lo importante", no vaya a ser que por andar corriendo pierdan clientes.

Alternativas a la matriz de Eisenhower

Esta matriz no es una herramienta impuesta por la metodología. De hecho la he ido cambiando dependiendo del escenario en el que me encuentro. Si el problema es relevancia para el negocio, esta matriz entra muy bien. Pero, ¿Qué pasa si el orden depende de las capacidades del equipo, o el time-to-market, o qué tanto beneficio es para el negocio?, ahí puede que sea más oportuno utilizar otra matriz que muestre de mejor forma el porqué se ordenó de tal forma. Aquí te presento dos alternativas que podrían ayudarte, pero como te dije, todo depende del contexto. Quizás tú encuentres algo mejor (y te invito a compartírmela), o talvez es necesario combinarlas. La idea es salir de este paso con el camino pre fabricado.

• Impacto vs Esfuerzo: Esta matriz nos presenta una forma de equilibrar las expectativas del negocio con las capacidades del equipo. Más detalles aquí.
• Riesgo vs recompenza: Interesante forma de plantearse un roadmap basado en cuánto apostarás a que lo comprometido es lo que te llevará al triunfo. Más detalles aquí.

[Paso 4] Mapa de épicas

Sigamos avanzando, que ya estamos a la mitad del camino... Este paso comienza a cerrar el segundo diamante de la metodología permitiéndonos poco a poco pasar de la estrategia a la táctica. Para estas alturas ya podrías tener un roadmap basado meramente en las expectativas del negocio y los referentes del equipo. Es lo que se llama una estimación "High Level". Por favor, no cometan el clásico error de comprometer esas fechas por más certeras que parezcan. Probablemente las personas que las definieron no escribirán una sola línea de código, o trazarán una línea en figma, o validarán un caso de prueba. Siempre dejen claro que son fechas preliminares y que seguramente cambiarán una vez sea bajada la táctica.

En esta etapa es importante que las personas de producto estén siempre presentes, y si es necesario, junto a los referentes del equipo de cada área. Es importante que piensen en optimizar el tiempo, esfuerzo y recursos (tiempo sobre todo), por lo que te recomiendo que siempre en mente la Ley de Pareto, de esta forma siempre buscarás sacar el mejor provecho a lo que tienes.

Dicho eso, esta etapa es súmamente importante para iniciar la táctica, las épicas son tareas grandes tanto ten tiempo como en esfuerzo, por lo que son suceptibles a ser divididas en actividades más pequeñas. Sin embargo, son cosas que se deben realizar para completar el requerimiento, y por consiguiente, la iniciativa. Para este punto los requerimientos están bastante claros, por lo que podemos plantear soluciones a grandes razgos. Ya tienen la prioridad de la iniciativas, y el orden de los requerimientos, así que se debe pensar en un plan que permita abordar tanto como sea posible. Es por esto que tendrás que definir épicas, cuyos criterios de aceptación son los mismos requerimientos (esto se escribe solo... jajaja).

Si ves que la solución a un problema también aborda la solución de otros, agrupa en una sola épica (ley de pareto), pero vigila que no afecte el cumplimiento de las que tienen prioridad de construcción.

Para este punto creo que podrías darte cuenta que a cada herramienta la he ido adaptando para cumplir con el postulado de que el tiempo es lo más importante, y por lo mmismo todo avanza de izquierda a derecha y de abajo hacia arriba. Todo está empezando a quedar enlazado, y puedes notar que si apareciera un cambio repentin ya podrías informar el impacto que tendrá sobre todo el plan con lujo de detalles. Ese es el espíritu de esta metodología, que en todo momento tengas información para negociar, planificar, y medir impactos. Pero esto no termina aquí...

¿Qué es una épica?

Detengámonos un momento. Esta pregunta me la han hecho muchas veces. Creo que la definición de épica es algo que aparece en muchos lugares, y quiero compartirles el artículo de Atlassian (No pueden decir que no es una buena fuente) que siempre me pareció muy bueno: Historias, epicas e iniciativas. Aquí se explica muy claramente cómo se van separando los ítems para crear un plan. También verás que en esta metodología le agrego una etapa intermedia entre la Iniciativa y la Épica. Sin embargo, el definir una épica solo por su cantidad de trabajo me parece mesquino. Es como cuando un equipo scrum pesa una historia en 21 puntos porque le tomará 2 semanas, pero la tarea es sencilla de realizar. Que sea extenso de realizar no la hace complicada. Pero eso es para un artículo aparte... Ya lo he dicho, esta metodología se basa en el tiempo, así que cuando crees una épica piensa en cuánto te llevará completarla. Si trabajas por sprints el timebox te dará el punto de quiebre. Dado que una épica es una tarea grande, si esta te toma más de un sprint, tendrás que dividirla y ¡PAF! ya tienes una épica. El tiempo es siempre el factor más importante, por lo que la eficiencia es el punto más importante.

No quiero sonar absolutista ya que hay muchas formas de definir una épica. He creado unas por hito de negocio, o por feature, o por flujo de experiencia, o por etapa del desarrollo de software. Lo que busco es que no te compliques, sobre todo en etapas iniciales de un proyecto, donde debes empezar a trabajar cuanto antes para maximizar los recursos. Nada está escrito en piedra y puedes reformular la táctica tantas veces como quieras, mientras no pierdas contexto y el norte (estrategia).

[Paso 5] User story map... pero horizontal

Esto se pone interesante... Cada vez estamos obteniendo más detalles de lo que se debe hacer y el segundo diamante se está cerrando cada vez más para terminar con una táctica que nos permita iniciar el trabajo. Es por esto que el paso 5 es el Storymap. Y si, no se parece al clásico, pero como ya lo he dicho, la metodología obedece al criterio del tiempo, y un esquema que avanza hacia abajo no le sirve, así que le di una nueva vuelta de tuerca y lo dejé horizontal...jejeje. Ya verás que tiene sentido cuando lleguemos al paso 6.

Actividades

Primero, no se asusten por la línea roja atravezando la imagen. No es un error, y la explicaré más adelante. Segundo, si bien en la imagen sugiere que solo estén líderes y referentes en esta etapa, nunca será malo tener a todo el equipo en ella. No descartemos una idea genial viniendo de donde menos los esperas.

Ya tienes el orden y alcance de las épicas, lo mismo que la prioridad de requerimientos e iniciativas. Ahora queda hilar más fino, y es que tomaremos épica por épica, leyendo cada uno de sus criterios de aceptación, y definiendo que actividades se deben llevar acabo.

El líder del equipo iniciará explicando cada una intentando responder a todas las preguntas del equipo. Este empezará indicar todas las cosas que se deben hacer y consideraciones que se deben tener. Estas actividades se agregarán con un buen título y descripción independiente del tipo que sea. Aquí es importante que los miembros del equipo tengan una visión de mediano plazo, por lo que la experiencia es imperativa. Aunque todas las sugerencia son validas, es necesario que cada personas pueda proyectar su trabajo en el tiempo, considerando dependencias y bloqueos.

Una vez que se tenga un listado inicial de actividades, estas se deben trasladar al storymap considerando los siguientes criterios:

• Tiempo estimado
• Recursos necesarios
• Bloqueos y dependencias

y estas reglas sobre las actividades:

• Deben ser coloreadas como la épica
• Deben ser ordenadas de izquierda a derecha de acuerdo a sus dependencias.
• Deben ser ordenadas de arriba hacia abajo de acuerdo a su prioridad.
• El criterio de tiempo es por sprint, por lo que cada cuadro se extenderá tantos sprint como sea necesario. Posteriormente se realizarán las divisiones.
• Si varias actividades dependen de una, esta última será tan alta como el grupo de tareas que bloquee.
• Los bloqueos deben quedar claramente descritos con un Spike delante de todas las tareas que son bloqueadas por este.
• Cada actividad debe encabezar su título con las áreas involucradas. Ej: [UX - Frontend], [Producto], [Backend], etc
• Sobre todas las actividades debe estar un recuadro tan ancho como la totalidad de actividades a realizar.

¡Perfecto! Teniendo esto claro, pasemos a hablar de los tipos de actividad más comunes. Esto no quiere decir que no aparezcan otros, eso depende del negocio y proyecto, pero usualmente se encontrarán con estos tipos.

Antes de saltar al otro segmento, siempre ten en cuenta la épica y sus criterios de aceptación. No vaya a ser que por dejarse llevar esten agregando actividades que no tienen nada que ver con el alcance de la épica. Es muy importante que el líder del proyecto sepa manejar al equipo para no desviarse.

Ok, hay información más que suficiente en internet o en las IA, así que seré breve en cada definición:

Historias de usuario

Teniendo claro quien es nuestro negocio, cada necesidad, petición, o problema, es una posible historia de usuario. Siempre lo he dicho, las historias son problemas a resolver, por lo mismo, siempre son encabezadas con un Como, Quiero, Para y sus respectivos Criterios de aceptación. Es el equipo el que define la solución a ese problema, que también puede agregar más criterios de aceptación.

Como me respondió una gran amigo y mentor en agilidad cuando le hice la pregunta "¿Que debe incluir una historia de usuario?", el me respondió "Todo lo necesario para completarla". Contra ese pragmatismo quedan pocos argumentos. Por lo mismo, la definición y alcance de cada tarea debe ser acordada con todo equipo para evitar malos entendidos y retrabajo.

Tareas

¡Simple! cualquier necesidad que no sea una historia de usuario. ¿Demasiado breve?, bueno, esto siempre ha sido materal de debate en todos los proyectos que he integrado, así que no intentaré generar un estandar y solo te sugeriré algo: Una tarea es todo lo que NO esté ligado a la experiencia de usuario, expectativas del negocio, o directa construcción de la solución, pero que agregará un valor importante al resultado. Ej: cambiar la versión de una librería, pasar a tecnologías Cloud, utilizar un agente IA, etc.

Bugs

Estos comienzan a aparecer ya entrando en la construcción, y no son más que incumplimientos en los criterios de aceptación de cada actividad. Por lo mismo es importante que se controlen todos los escenarios posibles antes de que la actividad entre en desarrollo.

Si bien un bug puede presentarse por motivos técnicos u omisiones, la gran parte obedece a que nos se desarrolló como se solicitó. Aquí es importante tener altura de miras y no atacarse mutuamente. (He visto disputas épcias.... jajaja).

Spikes

Esta es la única actividad que se escapa las de reglas de este paso en la metodología. Un spike no es más que algo que no sabes, y debes destinarle tiempo para investigación. Este tipo de cosas son las que meten incertidumbre en los proyectos y es deber de todo el equipo tener la suficiente tenacidad para controlarlo. He visto spikes cuyos resultados modifican completamente un roadmap.

Reglas sobre el spike en el storymap:

• Siempre se pintarán de color gris. Esto porque son zonas grises o de desconocimiento.
• A continuación del spike deben aparecer todas las actividades bloqueadas por el.
• Al basarse en una investigación con resultados que podrían ser inesperados, se debe controlar muy bien el tiempo que se le destine. Si se estima que tomará más de un sprint es buena idea cuestionarse el alcance de la épica.

Split horizontal/vertical y el proceso de desarrollo de software

Voy a tocar un tema peliagudo... En cada proyecto que he integrado los últimos años ha surgido el tema del split(división) de actividades. ¿Cómo se debe hacer? ¿Qué criterios ocupar? ¿Es necesario? ¿Dejamos que pase en carryover?, bueno, son preguntas que han aparecido en muchas ocaciones. Pero creo que debo explicar en qué consiste un Split, o mejor dicho, que rayos significa. No es muy complicado:

Teniendo esa definición en mente, el split obedece a la necesidad del equipo de poder hacer foco en tareas más pequeñas, usualmente, que puedan ser finalizadas en un sprint. Esto no es menor ya que esta acción afecta directamente la táctica, y fácilmente puede sumar a una estimación inicial de dos sprint uno más. Cuando la métrica más importante de la metodología es el tiempo, esto afecta de sobremanera. Sin embargo, los criterios para realizar un split pueden ser muy variados, y mayoritariamente son un acuerdo de equipo. Por ejemplo:

• No se alcanza a terminar en un sprint.
• Tiene subtareas que bloquean otras.
• Se agregaron criterios de aceptación fuera de alcance, pero que son importantes.
• Gente de vacaciones que no podrá completar su parte de la actividad.
• entre otras...

Para los que trabajamos en esto es un tema cotidiano, así que quiero hacer foco en dos tipos de split que los filósofos de la agilidad siempre están debatiendo. Y si bien estoy seguro que estas metodologías sirven en muchos rubro, y que tendrán situaciones similares, esta vez me limitaré a mi experiencia en la construcción de productos digitales y desarrollo de software.

Split vertical

Este es el más recomendado por las metodologías ágiles, y se basa en que toda actividad debe ser terminada en un sprint junto a todas sus subtareas, que componen el desarrollo de la actividad. Obedece a una estructura donde se avanza de forma vertical como una estructura de piezas que sostiene la implementación de una funcionalidad.

Esto es lo ideal, ya que permite cumplir con el postulado de rápida entrega de valor y la Integración continua / Entrega continua sobre funcionalidades completas.

Este tipo de división mantiene un backlog ordenado y también ayuda a cumplir con la regla de definir pequeñas tareas que se puedan terminar en el periodo de un sprint. Pero aquí está el principal problema de esta forma, porque:

• ¿Está el equipo preparado para terminar cada actividad en un sprint?
• ¿Es posible terminarlo en un sprint?
• ¿Dejamos margen a los "imprevistos"?
• Si encontramos un bug, ¿Podremos resolverlo a tiempo?

y así, hay muchas más preguntas... y por eso aparece el split horizontal.

Split horizontal

He participado de muchas discusiones y debates al respecto. Los puristas lo odian, pero la realidad es otra. En mi experiencia, solo he podido participar en un equipo de alto desempeño , y solo con ellos he visto que se logró el ansiado Split Vertical. La verdad es que es muy complicado cumplirlo, porque no todos están preparados para esa intensidad, los proyectos son muy exigentes, y pese a que la metodología ágil indica que se debe adaptar a la realidad del equipo y compañía, los puristas escriben las reglas en piedra y no se mueven de ahí.

El split horizontal obedece a la necesidad de ir terminando las funcionalidades pieza por pieza, para posteriormente integrarlas en una actividad final. Esta es la lógica del desarrollo de software, donde planificas el trabajo por área de desarrollo, paralelizando lo que puedas y coordinando entregables.

No les mentiré, esto ayuda mucho a la coordinación del esfuerzo de cada miembro del equipo, pero es un problema la administración. El backlog tiende al caos y es fácil perder el hilo del desarrollo. Por lo que es imperativo que los líderes del equipo tengan herramientas que le permitan no irse del camino.

User persona, Journey map y service blueprint

Este será un gran paréntesis... Quiero detenerme aquí para comentarte de unas herramientas que te serán muy útiles en esta metodología. Como cada herramienta usada hasta ahora, estas son bastante conocidas, sobre todo en el mundo de los diseñadores de servicios y de experiencia de usuario. Son muy útiles para saber para quién estamos desarrollando el producto y cómo se lo queremos presentar.

Hay información de sobra en internet, así que te las comentaré desde mi experiencia y cómo me han ayudado. Incluso he realizado presentaciones donde se han convertido en piezas fundamentales en los procesos de diferentes clientes, que no le veían el valor hasta que se los planteas de una forma conectada y holística.

User persona

Entre más detalles tengas, mejor. Pero no entusiasmes mucho, esto depende mucho de la investigación que hagas y el producto a desarrollar. El definir correctamente el usuario o el conjunto de ellos, ayudará a empatizar y hacer foco en lo que realmente importa.

Si el producto es de nicho, quizas un user persona es ideal, pero si es más masivo y apela a conjunto de personas con características en comun, un proto persona, o incluso un arquetipo, es lo que buscas. Creo que está bien definido su alcance en este artículo. La idea es que te permita poner al usuario en el centro de la acción.

¿Porqué es importante en esta etapa de la metodología?, bueno, están las historias de usuario, en donde ese usuario, es uno de los que definas en estos user persona. Recuerda que la estructura de las user stories es: COMO, QUIERO, PARA; ese COMO se completa con uno de los user persona que identifiques.

Journey map

Como parte de la etapa de empatizar, es que bajas a piso la realidad actual mediante un mapa que refleje cuál es el comportamiento del usuario ante una determinada experiencia. Esto permite revelar puntos de dolor que te definan acciones a tomar y situaciones a consideran a la hora de implementar una solución.

¿Estamos resolviendo el problema que enfrenta el usuario realmente?. Esta es una de las preguntas que permite resolver el Journey Map, y creo que este artículo lo explica bastante bien.

Junto con el user persona, son resultado de la investigación previa al desarrollo de la solución. Sin esto, podrías estar trabajando en vano, porque "Nadie destina tiempo y dinero a construir algo que nadie usará". (Eso lo escuché de un profesor, y no puede estar más en lo correcto.)

Service blueprint

¡Muy bien! Ya hiciste tu investigación y sientes que ya puedes definir una solución. Sin embargo, todo está en tu cabeza y se te puede olvidar a medida que escribes épicas, hisotrias de usuario, tareas, etc. Esto es muy común, por lo que es necesario utilizar alguna herramienta que te permita poner la pelota en el piso y ordenar las ideas de todos los involucrados en construir la solución.

Durante un tiempo utilicé diagramas de flujo como una forma de explciar una idea y que quedara documentado de inmediato. El problema es que era complejo separar contextos de acción de los diferentes protagonistas e indicarles donde debían entrar al juego y en qué momento salir. Fue entonces que descubrí el Service blueprint.

Aunque este artículo lo explica muy bien, quiero presentártelo con mis propias palabras y como lo hice a mis clientes. Recuerda que estamos en la etapa del storymap. Este representa la táctica ordenada en cuadros que representan las actividades a realizar en un orden temporal y de dependencias. Pero, ¿de dónde salió ese plan?. Ahí es donde entra el service blueprint, una herramienta para equipos interdiciplinarios donde convergen todas las ideas para implementar una solución. Es como un gran diagrama de flujo, pero que está claramente organizado por sistemas integrados, servicios utilizados, experiencia definida, niveles de la arquitectura de desarrollo, etc, que básicamente representa el diseño holístico de la solución.

Es importante entender que no es necesario diseñar una solución completa desde el tiempo cero del desarrollo. A menos que trabajes en metodología waterfall, pudes diseñar una solución que se vaya madurando con cada iteración. En otras palabras, inicia con el famoso MVP. Esto permite incorporar cambios a medida que vayas descubriendo más antecedentes, o si el mercado cambió, o si las prioridares se fueron para otro lado.

Como mencioné antes, es muy importante para el storymap el desarrollo del service blueprint, y es que ambos se van contruyendo al mismo tiempo, donde el primero es a causa del segundo. Eso quiere decir, que lo que diseñes como solución en el SBP termina siendo una serie de actividades en la táctica.

Recuerdo que era confuso para los clientes entender solo con palabras, así que les presenté esta imagen

Esta es una de las formas en que puedes acompazar ambas herramientas, donde de acuerdo a las etapas del Journey map definido como solución, vas definiendo épicas o steps en tu storymap. De esta forma, tienes un contexto claro de porqué las tareas se definieron y organizaron.

Para mi fue una revelación cuando me di cuenta.

[Paso 6] Roadmap fusionado al Release map

Recuerdas que te dije que no te preocuparas por la línea roja que atravieza el storymap, bueno, aquí es donde inicia... jejeje.

Como ya lo dije, el tiempo es el principal punto de referencia de toda esta metodología, y es el causante de que varias herramientas hayan sido modificadas para acomodarse a este formato. Sabemos, también, que un roadmap se basa en la entrega a futuro, por lo que aquí es donde el factor "tiempo" empieza a cobrar su mayor relevancia. ¿Cómo sabemos que estamos a tiempo? o ¿cómo nos damos cuenta de si llegaremos a cumplir con los objetivos corporativos?, es más ¿cómo nos damos cuenta si estamos construyendo lo que nos pidieron?, y para eso es el roadmap.

Para la metodología BaP, es el último paso, pero representa la validación y confirmación del plan definido en los pasos anteriores. Ya para el paso 3 seguramente ya tenías las expectativas del cliente lo que representa el roadmap tentativo de la compañía. Sin embargo, es necesario validarlo contra la realidad, y es este el momento.

Roadmap

Esta es una herramienta ya clásica en casi todo orden de diciplinas que contemple un trabajo de largo plazo. Esta contempla solo dos valores: Un día de inicio y uno de término. Si, suena reduccionista, porque en realidad, para llegar a esas fechas, se debíeron realizar varias reuniones de equipos interdiciplinarios, donde los líderes de la compañía se deben poner de acuerdo para dónde quieren llevarla, siempre considerando rentabilizar la empresa maximizando las ganancias, controlando el gasto, y reduciendo los costos asociados al desarrollo de productos, sin dejar de lado la continuidad operativa, siempre con una mirada holística.

Es común en los equipo enojarse y frustrarse por las estimaciones que se bajan a ellos, cuando los líderes presentan el roadmap de la compañía. El desconocimiento provoca incertidumbre, y la incertidumbre provoca ansiedad, y la ansiedad, lleva a malas reacciones, por lo que entiendo esa reacción. Sin embargo, y después de años de compartir esa molestia, he ido empatizando con ambos lados. Los equipos sienten la presión de cumplir con las expectativas sin morir en el intento; y los líderes tienen la presión de hacerse cargo de la decisión que tomaron, y aquí es donde me quiero detener. Si alguna vez te preguntaste si se justificaba el sueldo que ganan los que toman estas decisiones, te respondo de inmediato que SI. Una empresa seria no da mucho margen al error en estos niveles jerárquicos. Ellos se equivocan y la empresa pierde dinero, y eso atenta directamente contra lo que mencioné en el párrafo anterior sobre la rentabilidad de la compañía. Por lo mismo, los términos de su contrato tienen cláusulas diferentes a los miembros de los equipos de "más abajo". Su cabeza siempre está en juego... o debería estarlo.

Release map

En cuanto a esta herramienta, también tiene una definición simplista: Dime qué entragarás y cuándo lo harás. jajaja. Lo siento, pero no tiene más información que esa, pero tal como lo fue con el roadmap, hay más en el fondo para llegar a esta planificación. Y es que coordinar estas entregas tienen mucho de gestión y variables a considerar. Por lo mismo, la alineación con las expectativas de los stakeholders y la táctica definida en el equipo, es primordial.

La integración y entrega continuas no es simplemente "Terminé una funcionalidad. ¡A PRODUCCIÓN!". El cuándo es oportuno o pertinente publicar depende de alineaciones estratégicas con, por ejemplo, el equipo de marketing: No puedes salir con un producto porque la campaña no está ejecutada; o con el equipo de legales: el estado exige que se cumplan nuevas exigencias que serán requeridas para cuando alguna ley salga promulgada; o el clásico: debemos esperar a que otro equipo termine su parte porque dependemos de ellos; y finalmente, el Time-To-Market: que nos permitirá saber cuándo tenemos un ventaja competitiva real en el mercado.

Integrando herramientas

Si hacemos memoria de las reglas del Storymap un poco más arriba, recordarás que se debía posicionar un recuadro tan ancho como la cantidad de sprint que tomará terminar una épica. ¡Bien! Este es el primer paso: Tomaremos todas las épicas y sus recuadros de tiempo y los copiaremos en el roadmap de forma que podamos tener la mirada completa de cuanto tiempo tomará terminar todo el trabajo priorizado. Para este momento ya puedes tener las primeras alertas en cuanto a si se cumple con las expectativas del cliente y los stakeholders. Pero no te adelantes y vayas a armar un incendio. Necesitas razones y justificaciones para levantarte de la silla e ir a negociar. No puedes ir solo con el problema. Debes poder ofrecer un solución, una alternativa, o por lo menos una recomendación fundada.

Como ya tienes una táctica, estamos trabajando con la idea de integración y entregas continuas, y además la agilidad nos pide que la entrega sea funcional, significa que tu plan contempla salidas programadas, independiente de si es en ambientes bajos o producción. Estas salidas son parte del release plan, y deben ser marcadas en la parte superior del roadmap encabezadas con los títulos de la entrega a realizar. Para esto debemos volver al Storymap y de acuerdo con la táctica definida, identificar cuándo entregarás funcionalidades completas, siempre considerando si es oportuno que salga en ese momento. Ahí es donde los líderes del equipo deben manifestarse y coordinar esa salida para esa fecha u otra.

Para este momento ya tienes información suficiente para saber si cumplen con las expectativas de la compañía. Tienes información sobre tiempos, estimaciones del equipo, indicadores de producto, y algunas otras cosas que te permitirán levantarte de la silla e ir a negociar adecuaciones a la táctica o la estrategia. Sin embargo, y si bien constantemente he enfatizado que el tiempo es el factor principal que afecta esta metodología y que es el motivo por el cual todas las herramientas avanzan horizontalmente, hay diversos factores que afectan directamente todo lo que hemos visto hasta ahora. Yo las llamo "Consideraciones", y te las explicaré a continuación.

[Paso extra] Consideraciones. La mirada vertical

Este es un punto que agregué cuando ya tenía implementada la metodología, pero estamos en agilidad, así que "bienvenido el cambio". Constantemente estaba sufriendo por cambios al plan por cosas que no veia venir pero que son cotidianas, más no irrelevantes. Estas afectaban directamente las planificaciones forzando los ajustes sobre la marcha, y obligándome a dar explicaciones a cada semana de porqué hay retrasos o porqué no lo vi venir. ¿A qué me refiero?, bueno, estoy hablando de la capacidad del equipo, el nivel técnico, cantidad de personas por rol, distribución de la capacidad, e incluso licencias médicas o feriados y vacaciones.

Puede parecer increíble que se nos pasen estas cosas, pero es de todos los días. Somos seres humanos y nuestra capacidad para tener la fotografía completa en nuestra cabeza, y sus cambios en el futuro, es mucha información para procesar. Ahora, si es posible, pero súmale que debes poder idear cambios al plan y estimar su impacto completo. He sufrido la presión de tener que reformular la mitad del backlog porque no consideré que algunos miembros del equipo tenían vacaciones y solo me quedaba con los miembros más novatos (¡Dios mío! jajajaj).

Bueno aquí es donde entran las consideraciones. Es el conjunto de antecedentes que se deben tener en consideraciones de cara a la siguiente entrega. Es muy importante que se deje por escrito o coordinado cualquier cosas que podría afectar el cumplimiento de la táctica.

Afecta el storymap y el release map

Esto no es antojadizo, y quiero evitarte dolores de cabeza por sorpresas inesperadas, así que me pondré en diferentes situaciones (casos reales) y cómo afectó al hipotético proyecto a continación. Considera los siguientes antecedentes básicos:

• 1 feriado
• Frontend senior: 2 semanas de vacaciones.
• 1 frontend senior con capacidad de 2 actividades por sprint + asistencia a FE Junior.
• 2 frontend junior con capacidad de 1 actividad por sprint.
• Distribución de capacidad: Nuevos desarrollos 40%, Iteraciones: 30%, Soporte: 30%.

Casos

• Eso significa que puedes realizar 4 actividades de frontend por sprint. Ahora, vuelve al storymap y verifica que no tengas más de 4 tareas de esta área en algún sprint antes de la próxima entrega. Si es el caso, tendrás que mover alguna actividad hasta otro sprint, lo que significa que podrías estar empujando otras tareas que dependan de esta en el futuro, y esto llevaría a un posible cambio en fechas de entrega.
• El desarrollador senior tiene 2 semanas de vacaciones antes de la entrega, bueno, primero encomíendate a los dioses... jajaja. La capacidad de tu equipo baja a la mitad, por lo que si tienes un sprint con más de 2 actividades tendrás que redistribuir la carga extra, con las mismas implicaciones del punto anterior.
• Después de una liberación aparecieron muchos bugs productivos, pero solo tienes un 30% de capacidad para esto. Además tienes muchas actividades organizadas coordinadas de acuedo a la distribución de capacidad del equipo. Aquí puedes distribuir los bugs en diferentes sprints, pero ¿qué pasa si deben solucionarlos antes del siguiente sprint? Bien, toca ir a negociar la distribución, pero eso significa que tendrás que negociar, también, cambios en actividades ya planificadas. Así que a mover piezas junto a los líderes del equipo. Pero, ¿y si no puedes mover las piezas sin cambiar la fecha de entrega?, aquí es donde debemos plantearnos negociar un cambio en la fecha de entrega o en el alcance de la épica, o en el peor de los casos, negociar con el equipo horas extras. (Por favor no lleguen a eso)
• El feriado cae justo en la fecha de liberación planeada. (jajja... esto me paso). Bueno, nada que decir, te toca ver si es conveniente y se puede adelantar o postergar la salida, con todo lo que implica esa coordinación y reuniones para justificar el cambio de fecha de algo que debiste prever con suficiente antelación.

Estos son algunos de los muchos casos que se te pueden presentar. Puedes agregar las consideraciones que estimes convenientes para tu caso particular: OKR, KPI, analítica, estado anímico del equipo, etc. Esto te da la mirada vertical a la planificación y que te permite planificar en detalle tu táctica, pudiendo contemplar muchas variables con información que te posibilite negociar con datos empíricos, y números reales, que finalmente es lo que toman en cuenta los líderes de la compañía para realizar sus ajustes.