El tema de cómo combinar Diseño-UX en un modelo de trabajo Ágil, ya lo he tratado más de una vez, de hecho, como lectura previa a este post, te recomiendo leer este post, de hace poco, ¿Más UX o más Ágil?, y este, algo más antiguo, ¿Cuándo se hace el diseño de interfaces (UI) y el UX en Scrum?.
Hoy, como he tenido unos días, de nuevo, tratando el tema, voy a dejar un nuevo post sobre este asunto.
La previa: Cada uno tiene «su UX»
Yo he estado con equipos que no saben ni lo que es el UX (ni falta que les hace), para su trabajo no lo necesitan, trabajan con interfaces simples y sus usuarios no necesitan, ni quieren, nada más. Si eres UX puedes estar poniendo el grito en el cielo, pero créeme, este mundo es demasiado heterogéneo, no hace falta que te de más datos, pero, por ejemplo, aquellos que hacen software «científico», para usuarios «científicos», no piensan en UX (e incluso sus usuarios les odiarían si les cambian su viejuna interfaz de «toda la vida»).
Luego están los que hacen cosas muy simples, rápidas, que necesitan algo de diseño, pero sin florituras, y, en estos casos, en un modelo ágil, las acciones de lo que vendría a ser UX son tareas derivadas de Historias de Usuario (HU), que se estima que se completen durante el Sprint de creación, al igual que, por poner un ejemplo, pasa con las tareas de Testing.
Ahora vamos con un tercer caso, aquellos que necesitan una profunda actividad de UX, aquellos que trabajan con productos en los que la «experiencia de usuario» es muy determinante, vamos con este caso…
Opciones cuando UX es determinante para convertir una HU en una funcionalidad de un producto software
Antes de seguir, y al igual que ya te advertí en el post de ¿Más UX o más Ágil?, ojo con el riesgo es caer en un (a) cascada, por mucho que se maquille y se le pongan nombres bonitos, y (b) equipos silo (un equipo de UX y otro de desarrollo).
Si hasta que no diseñes TODA la experiencia de usuario, UX, etc., no puede empezar desarrollo a desarrollar, si eso lleva meses y meses, entonces… «cascadaca al canto» y equipos silos en vez de multifuncionales. Me ahorro contarte, por enésima vez, los problemas en que deriva lo anterior, no es cuestión de repetirme ni de alargar el post.
Ya sabes que la agilidad promueve la entrega frecuente, valor frecuente, equipos multifuncionaes, descubrimiento continuo, etc. Entonces… ¿alguna operativa para integrar el trabajo UX en un modelo de trabajo Ágil?
Separar al mínimo el tiempo desde que UX hace su tarea hasta que desarrollo hace la suya
No es lo mismo que UX termine todo su trabajo y que sea en ese momento cuando Desarrollo comience el suyo… a que vayamos, juntos, haciendo UX y desarrollo poco a poco, eso nos enfrenta a todos con la realidad y elimina muchos desperdicios, créeme, lo he visto.
Muchos argumentarán que necesitan ver una visión más global previa, de muchas HU, vale, puede ser, yo no sé lo que haces y a qué te dedicas, y seguramente lleves razón, pero que… sean las mínimas. Si tienes que hacer el UX de 5 HU a la vez, antes de dejarlas listas para desarrollo… mejor que hacerlo para 500.
Una manera de organizarlo: Definition of Ready – Denifition of Done
Del Definition of Ready (DoR) y del Denifition of Done (DoD) ya te hablé hace mucho tiempo, en Definition of Ready (y el Lado Oscuro) y en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done).
Aquí me interesa más el DoR, que es lo que hemos acordado que debería acompañar a una HU para que Desarrollo pueda implementarla, donde el UX de la HU puede ser parte del DoR.
En el siguiente dibujo (que yo vi por primera vez pegado en alguna pared) tienes una posible opción para llevar lo anterior a un tablero, a gestión visual. Bajo Diseño / UX están las tareas de «research», etc., necesarias para que una HU, o varias, puedan estar listas para desarrollo.
Existen más maneras de organizar esto, pero esta me gusta porque refuerza la idea de un único equipo multifuncional, no dos, no uno de UX y otro de desarrollo, no un equipo con un tablero, y sus cosas, y otro, con las suyas.
Terminando…
Más sitios para ampliar este tema, leer más, etc. Este post de Cutler, analiza varias opciones y acaba recomendando una solución similar a la que te he contado antes (lo que también viene a decir que la opción que te contaba en este post es uso bastante común y extendido, te la puedes encontrar por muchos sitios), interesante también leer los comentarios. Este otro post de Handa, más «narrativo», también tiene ideas interesantes.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Yo tengo una duda… ¿No hablamos siempre de que debemos tender a un Kanban claro de 3 columnas solamente? Me estrujo el cerebro una y otra vez para poder conseguir esto y ser super ágiles en Desarrollo (porque UI/UX está a mil cosas y en nuestro caso quedarían tareas en «Diseño» perennes… no viene bien que compartamos sprint realmente, no tenemos equipo maduro para ello)… y ahora parece que esto es un mini-cascadita, ¿no?
Yo, como PO, lo que intento (¡y creo que consigo!) es estar hiper alerta y en contacto con UI/UX constantemente, por lo que dedico la mayor parte de mi tiempo a dual-track para tener dentro del tablero de Desarrollo tarea tras tarea que quede lista para que se pueda implementar. Nada de bloqueo en eso o morimos :)))
¿Alguna idea intermedia? xD
¡Muy bueno el post!
Lo de 3 columnas sobre todo aplica al Sprint Backlog, luego siempre habrá una 4a que es el Product Backlog. Y ahora aparecen las previas, las de UX, que el peligro que tiene es hacer un cascada, la otra opción… todos a un único sprint backlog. Des todas maneras… cultura, porque con cultura, evitamos los cascadas, con tableros… no siempre
Muchas gracias por la ayuda :))) La palabra CULTURA creo que es la clave, no tanto 3/4/5 columnas, sí. Voy a dejar de obsesionarme por el proceso, porque como todos sabemos…
«Individuals and Interactions over processes and tools»
jajaja, thanks!!!