Cómo utilizamos EventStorming para aclarar nuestros procesos

Como cualquier otra empresa, tenemos muchos procesos en Easy LMS. Por ejemplo, cómo gestionamos los tickets de soporte o desarrollamos nuevas funcionalidades. Utilizamos la Kata de Mejora para optimizar nuestros procesos. Uno de los primeros pasos es especificar la situación actual. Sin embargo, resulta que cada uno tiene su propia visión sobre cuál es la situación actual. EventStorming es una técnica que utilizamos para definir nuestros procesos sin ambigüedades..

Imagina que eres un empleado nuevo en una empresa. Te emparejas con un miembro del equipo con más experiencia y recorres todos los procesos empresariales, en su mayoría no documentados. Creas un modelo mental del proceso haciendo preguntas y leyendo la documentación. Cuanta más experiencia adquiera, menos preguntas tendrá que hacer y menos documentación tendrá que leer. La mayoría de las cosas las harás (semi)automáticamente.

Una documentación menos actualizada sobre un proceso provocará una mayor variación en los modelos mentales que los empleados tienen de ese proceso.

Luego, si comparas cómo gestionas el proceso con otro miembro del equipo, te darás cuenta de que haces algunas cosas de forma bastante diferente. Esto ocurre porque vuestros modelos mentales difieren.

Cuando se optimiza un proceso utilizando la Kata de Mejora, describir la situación actual puede resultar difícil cuando los modelos mentales difieren significativamente. Ojalá tuviéramos una forma de convertir estos modelos mentales en documentación.

Cómo llegamos a EventStorming

A principios de 2020, asistí a la conferencia Domain-Driven Design Europ para aprender más sobre cómo modelar mejor nuestro software. Un taller al que quería unirme era sobre EventStorming. Ya había leído sobre él antes, y pensé que podría ayudarnos a sacar el conocimiento específico del dominio de las cabezas de nuestros expertos de una forma fácil de compartir con los desarrolladores. Así podríamos crear mejor software. Resultó que EventStorming es muy útil para modelar software, ¡pero también para modelar procesos empresariales!

Por desgracia, llegó la pandemia. Cerramos nuestra oficina y empezamos a trabajar a distancia. EventStorming gira en torno a tener a un grupo de expertos en una sala trabajando sobre una gran superficie compartida. Esto ya no era posible de organizar. Afortunadamente, Alberto Brandolini, el fundador de EventStorming, también se dio cuenta de esto y organizó otro taller para resolver este problema: Remote EventStorming. Me apunté a él y después esperé una oportunidad para experimentar con EventStorming.

Modelización de nuestro proceso de desarrollo con EventStorming

En los últimos meses, hemos cambiado mucho nuestro proceso de desarrollo. A veces, el proceso fallaba, y se hizo evidente que ya nadie tenía una visión total del proceso. ¡El proceso candidato perfecto para probar EventStorming en!

Le digo al equipo que quiero experimentar con EventStorming. Estoy seguro de que podemos obtener una buena visión general del proceso de desarrollo actual haciendo esto. Invito a un par de desarrolladores interesados de ambos equipos y creo una pizarra remota compartida utilizando Miro. Seguimos los pasos predeterminados de EventStorming:

1. Exploración caótica: cree notas adhesivas para todos los eventos que se le ocurran que suceden en el proceso.

2. Reforzar la línea de tiempo: ordene los eventos desde el principio del proceso hasta el final.

3. Enriquecer los eventos: añada metainformación a cada evento. El comando (acción) que dispara el evento, los datos necesarios, el sistema que actúa y la política que dice qué hacer a continuación.

4. Enriquecer los eventos: añadir meta información a cada evento.

Exploración caótica

Al principio resulta un poco incómodo. Pero en cuanto aparecen las primeras notas adhesivas, el ritmo se acelera y todo el mundo se vuelca.

Empezamos dando a todos los participantes su propio trozo de pizarra y un color (pero no naranja, más adelante hablaremos de ello). Tienen 25 minutos para crear notas adhesivas para todos los eventos que se les ocurran durante el proceso. Un suceso es algo que ocurrió en el pasado y que ya no se puede cambiar. Por eso se escriben en pasado. Por ejemplo: "Repositorio de código creado" o "Código desplegado en el entorno de producción".

Les animo a que hagan "trampas" y miren los eventos que anotan otros participantes, porque puede abrirles una parte del proceso en la que no habían pensado antes. No pasa nada por añadir eventos que también tengan otros participantes.

Cumplimiento del calendario

Cuando veo que no aparecen nuevas notas adhesivas en la pizarra, pasamos al siguiente paso. Trazo una línea en la pizarra. Luego pido a todos que tomen su nota adhesiva del acontecimiento que ocurre primero en el proceso de desarrollo y la coloquen encima de la línea de tiempo. En breve debatimos qué evento es realmente el primero y lo colocamos al principio de la línea de tiempo. Para indicar que todos estamos de acuerdo con este evento y su lugar en la línea de tiempo, cambiamos el color de la nota adhesiva a naranja (por eso antes no había notas adhesivas de este color...). A continuación, pasamos al siguiente evento.

Entramos en un debate más extenso sobre un acontecimiento. Para mantener la fluidez, creo un tipo especial de nota adhesiva llamada punto caliente. En ella, describo el problema y seguimos adelante. Volveremos a los puntos calientes más adelante. Nos encontramos con un evento que han creado varios participantes. Nos quedamos con el que mejor describe el evento, y eliminamos los demás. También añadimos ramas para los eventos condicionales. Las colocamos por encima o por debajo de la línea de tiempo del proceso principal.

Después de dos horas y media, nos detenemos. La cronología está terminada y todos los puntos conflictivos resueltos. Todo el mundo está lleno de energía, e inmediatamente planificamos la siguiente reunión para hacer el proceso más claro enriqueciendo los eventos con metadatos.

Enriquecer los eventos con metadatos

Este paso se explica mejor con una imagen:

Al principio de nuestro (sub)proceso (nota adhesiva negra grande), tenemos que tomar medidas (nota adhesiva azul) para dividir el trabajo. Para ello, necesitamos información (nota adhesiva verde) en forma de la historia de usuario en la que vamos a trabajar. Jira es el sistema (nota adhesiva rosa grande) que utilizamos para ello. Una vez hecho esto, hemos dividido la historia de usuario en las llamadas subtareas. Eso es un evento (nota adhesiva naranja). La política de desarrollo (nota adhesiva morada grande) nos indica entonces nuestra siguiente acción: poner una subtarea en progreso en Jira.

Seguimos la línea de tiempo y enriquecemos cada evento. Si no estamos seguros de cómo enriquecer un evento con metadatos, creamos una zona activa y seguimos adelante. Más tarde, revisamos todos los puntos calientes. Algunos no podemos arreglarlos. Por ejemplo, cuando hacemos una demostración de la historia, porque eso depende de la planificación de las partes interesadas. O cuando creamos documentación para la historia porque aún no forma parte de nuestro proceso. No pasa nada; sólo estamos describiendo la situación actual de nuestro proceso. Pero es algo que podemos mejorar.

Experimento finalizado con éxito

Todo el mundo está entusiasmado con EventStorming y los resultados que hemos obtenido.

Confiaba en que podríamos obtener una buena visión general del proceso de desarrollo actual realizando un EventStorm. Al final, efectivamente, tenemos una imagen clara de nuestro proceso de desarrollo:

Ahora es fácil explicar a los demás cuál es nuestro proceso de desarrollo actual. También sabemos que nos faltan algunas partes esenciales en nuestro proceso actual.

Estoy impaciente por empezar a modelar nuestros otros procesos empresariales.