Agilidad, ¿En qué momento hay que descubrir nuevos requisitos? Constantemente #ContinuousDiscovery

De las no sé ya ni cuantas reuniones y proyectos que yo haya podido tener en mi vida, y de las otras tantas que 233 Grados de TI haya podido tener en estos últimos meses, explicando y concienciando a empresas sobre el salto a la agilidad se podría elaborar una especie de FAQ con cuestiones que salen siempre, repetida y reiterativamente, siempre.
Muchas de esas cuestiones, dudas, partes más complicadas de implantar, de concienciar, de cambiar, han dado y darán para muchos post de este blog. Y vamos con uno más, en este caso tratando una cuestión que normalmente viene a manifestarse así… “-Y si ahora no tenemos ciclo de vida en cascada, y no hay una gran y única fase de requisitos, o de análisis… ¿cómo vamos a sacar los requisitos? ¿La foto global? ¿Dónde queda el trabajo que hacían analistas de negocio o similares?-“
En relación a esto, la figura del Product Owner es algo que relativamente se ha entendido bien, sus roles y responsabilidades son más o menos conocidos (te dejo una infografía), pero creo que no ha sido igual de popular la información relativa a “los procesos” cercanos al product owner, los relativos a extraer necesidades, “cargar” esas pilas de producto, etc., en general a lo que llamaremos “el ciclo de descubrimiento”.

Los intentos más populares para ir extrayendo necesidades en un ciclo de vida ágil o, simplificadamente y para que se entienda, cómo ir generando el Product Backlog

Quizá la idea más “antigua” (a lo que a agilidad se refiere, obviamente) de dónde, en qué punto, definir las necesidades, funcionalidades, etc., que debían irse incorporando al producto por parte de desarrollo, era centrarse en la “reunión de planificación del sprint”. Esta idea, aunque popular, no dejaba de ser un error (a la reunión de planificación el Product Owner se debiera ir a explicar historias de usuario no a crearlas), ya que, lógicamente, la lista de necesidades debía estar lista antes de esa reunión, de no ser así las “reuniones de planificación del sprint” excedían en tiempo, eran frustrantes,porque los elementos del backlogno estaban biendefinidos, entendidos, ovalidados.
Para evitar lo anterior, se popularizó el concepto de esto reuniones de refinamiento o Backlog Grooming, una la reunión previa “ a la reunión de planificación del sprint” con la idea de preparar el próximo Sprint Planning, para evitar llegar a él con las tareas a medio a hacer. No obstante, si bien esto ayuda, tampoco deja una respuesta muy clara a “cuando extraer esas necesidades que conformarán el product backlog”.
Otra popular iniciativa en este ámbito vino de los Spikes. Los spikes, que venían de eXtreme Programming, eran tareas “de investigación” que se introducían en un Sprint, típicas para extraer y comprender requisitos, pero que en muchos equipos fueron creaciendo hasta convertirse en “el Sprint de Spikes”, cuyo cobjetivoera dedicar un Sprint completo a la extracción y detección de nuesos requisots. Ocupaban un papel muy similar a los El Sprint cero.
El problema de esta última estrategia era que esos Sprint de Spikes o de descubrimiento eran demasiado bruscos y rompían la secuencia de Sprint típicos, generaban la idea de que “el descubrimiento” iba por fases. Ya sean print Cero, Spikes o Sprints de Descubrimiento, el descubrimiento ocurre por trozos aislados, sin embargo.. el descubrimiento siempre debería estar sucediendo.
Y la idea que mejor transmite “el descubrimiento constante” (ese #ContinuousDiscovery) es la que se ha llamado “Dual-Track”.

Dual-Track Scrum o Dual-Track Ágil (que vendría a ser algo así como Scrum o Agilidad de Doble vía)

El término “Dual-Track” viene de Jeff Patton (el autor de User Story Mapping: Discover the Whole Story, Build the Right Product). La idea asume que hay dos caminos en el desarrollo de un producto: “Descubrir” y “Entregar”.
Esta manera de verlo, evita y elimina la idea de que “primero hay una fase de requisitos” y después “viene su implementación”, y que si es un ciclo de vida ágil sucede lo anterior pero muchas veces, rompe la idea de fase, ya que “Descubrir” y “Entregar” muchas veces ocurren de manera simultanea.
Bajo una visión “Dual-Track” un “equipo de descubrimiento” está continuamente en descubriendo y el equipo de desarrollo está continuamente “entregando” producto al usuario final.
En “Dual-Track” el product owner, o el equipo correspondiente, está continuamente detectando, creando y validando nuevas necesidades, siguientes historias que se agregan al Product Backlog. En muchas ocasiones por “equipo de descubrimiento” nos estamos refiriendo al “product owner”, si bien este también podría ser la “interface” hacia desarrollo de un equipo de descubrimiento mayor.
Si el equipo de desarrollo trabaja con Ingeniería Software, Construye – Prueba – Entrega y Verifica, el de descubrimiento Experimenta, Descubre-Diseña y Valida.
Si el equipo de desarrollo considera desperdicios documentación innecesaria, código innecesario, etc., el de descubrimiento considera desperdicios las Funcionalidades que no se usan
El equipo de desarrollo busca Construir el Producto correcto y el de descubrimiento construir de manera correcta.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *