¿Dónde están las tareas referentes al diseño de interfaces gráficas? ¿Dentro de los Sprint? ¿fuera? ¿En el equipo de construcción? ¿si? ¿no?
El problema y la pregunta suele venir de algo que pasa muchas veces (que no siempre): que un Sprint sea demasiado corto para hacer tanto el diseño de interfaz como la implementación de una funcionalidad.
Las razones de por qué desligar UI de los Sprint de construcción suelen ser varias. Una típica, para “tener una foto global”, más allá de las pocas historias de usuario (o items en general) que se van a hacer en el Sprint. Otro argumento más para desligarlo: que en las reuniones Sprint Planning las historias que van a entrar en el Sprint lleguen con el UI flojo… y ya sea demasiado tarde y se retrase todo.
Si pasa lo anterior, sólo queda la opción de que el UI esté definido antes de que se empiece a construir la Historia de Usuario.
Dual-Track: “Discovery Track” vs “Construction Track”
Dicho esto, toca aquí hablar (o volver a hablar con más profundidad, porque ya lo hice en Agilidad, ¿En qué momento hay que descubrir nuevos requisitos? Constantemente #ContinuousDiscovery) del “Dual Track”, del “Discovery Track”(línea de descubrimiento) vs “Construction Track” (línea de construcción).
El concepto de “Dual-Track” explicita dos líneas de trabajo, los líneas temporales, como dos líneas temporales de Sprints en paralelo (y cuidado con esto, luego te cuento más abajo), unos centrados en descubrir y en lograr el detalle necesario para aquello que debe construir la línea de Sprints de creación.
El trabajo del “Discovery Track” alimenta el Product Backlog. El “Discovery Track” tiene como misión tener listas las historias de usuario antes de que arranque el Sprint de construcción en el que se implementarán, lo que incluye la información necesaria complementaria, y, según lo que hemos hablado, el UX, UI y similares.
Y esto PUEDE llevar (no necesariamente, ni obligatoriamente, ya que cuanto más trabajo en paralelo mejor) a un desfase temporal entre los Sprints de Construcción y de Descubrimiento, los de descubrimiento van “antes” preparando el trabajo para cuando lleguen los de “construcción”. Esto implica que el “Discovery” vaya uno, o más, Sprints por delante.
Peligros
Dicho esto, cuidado, que el concepto es potente pero te puede “llevar al lado oscuro” si no lo usas bien. ¿Dónde podemos liarla?
Enmascarar un ciclo de vida en Cascada
Por ejemplo desfasando mucho el ciclo de Discovery del de Contruction, especificando un montón de cosas que quizá no se lleguen a hacer, desperdicio. U olvidando el Hypothesis-Based Development, desarrollo basado en Hipótesis.
Recuerda: en cascada hay fases secuenciales, donde una depende del resultado de la anterior, en agilidad hay tareas más en paralelo y continuas.
Olvidar la colaboración, haciendo peligrar la naturaleza del equipo multifuncional. Dual-Track Scrum vs Discovery Sprints
Es por ello que Jeff Patton, creador del concepto del “dual”, decía que no era conviene pensar que el Discovery Track tiene SUS Sprints, con un grupo de gente trabajando en SUS Sprint, separados del equipo de construcción.
Es decir, NO hay dos Scrum en paralelo, sino un único Scrum que es Dual. Parece una tontería pero tiene su profundidad, porque enfatiza el trabajo en equipo, no caer en romper la multifuncionalidad, además de ayudar a no caer en fases secuenciales, evitar pequeños cascadas.
Evita dos flujos, con equipos separados, cada uno entregando sus artefactos para el siguiente Sprint. Resalta la colaboración, desarrollo, Testing, UX trabajan en conjunto, para crear y validar.
Para que leas más del tema
Te dejo algunas referencias, filtradas de un montón, que yo que tu me leería si quisiera complementar esto que te he contado:
Dual-Track Scrum
Where do you put your UX and UI stories in your agile framework?
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Javier,
muy buen post de nuevo. Como me alegro que reemprendieras el blog. 🙂
Esta problemática de como paralelizar las actividades en fase de la cascada (requisitos/UI, pero también pruebas) es un desafío clásico al adoptar la agilidad, pero no por ello trivial ni siempre bien resuelto.
Como dices en el post, son actividades con tempos diferentes, y por ello «encasquetarlas» de manera rígida en un sprint plantea problemas evidentes.
Desfasarlas «porque sí» tampoco es una solución, pues reduces los beneficios del feedback real de los Sprints, y además tienes riesgo de romper la comunicación del equipo, probablemente el peor inconveniente de la cascada.
El Sprint del equipo es único, eso se debe decir alto y claro. Además de mostrar los inconvenientes de la desconexión, creo que el propio equipo es quien mejor puede determinar como llevarlas a cabo, y no todos los sprints tienen que estar estructurados por igual respecto análisis/UI y programación.
El concepto de «Ready» puede guiar al equipo para saber cuanto UX hacer antes del sprint, y usando las historias (o ítems) del backlog, con sus prioridades/dudas/estado… como piedra angular de la colaboración y de la autogestión del equipo.
Alex @ http://www.itnove.com
Gracias Alex :-)!