A la hora de promover un equipo multifuncional en Scrum (sobre todo si el equipo es inexperto en cuanto a trabajar con Scrum), van apareciendo distintas barreras o choques en cuanto a forma de trabajo entre los distintos perfiles que hay que ir eliminando.
Uno de los choques más típicos es el mantener el enfoque tradicional de que los desarrolladores van por un lado, son los que crean cosas y los testers van por otro, y son los que las rompen. En los equipos multifuncionales, ambos tienen que trabajar con el mismo objetivo: si uno no termina el trabajo, el equipo no ha terminado la historia de usuario; el testing debe tener un enfoque preventivo y no destructivo, etc. (Recuerda ¿Cómo enfoco el testing de forma ágil?)
No obstante, también existen otros roles que hay que saber integrar. Para mí otro ejemplo es el caso de perfiles que se dedican a la experiencia de usuario (UX).
A grandes rasgos, por diseño de experiencia de usuario me refiero a esas personas especializadas en que las aplicaciones software satisfagan al cliente en cuanto a facilidad de uso, accesibilidad…Aquellas que se encargan de que el diseño exterior de la aplicación permita que el usuario interactúe bien con ella, sin frustración, de forma intuitiva, etc.
Puede que haya empresas que no tengan a nadie con ese rol, que no les haga falta tener a nadie especializado exclusivamente en ello y en su lugar haya desarrolladores con algunos conocimientos en UX, pero en otras empresas es un perfil requerido.
La pregunta es, ¿dónde metemos esto dentro del proceso Scrum? En cuanto a experiencia de usuario hay principios, técnicas, heurísticas, y estos perfiles pueden guiar a los desarrolladores a la hora de diseñar las interfaces de la aplicación.
También podríamos decir que ya que al terminar una historia de usuario hay testers que verifican dicha historia, pues que también se incluyan en los criterios de aceptación temas de experiencia de usuario. Así el equipo de UX debe verificar la solución desde el punto de vista de diseño de experiencia de usuario antes de dar por terminada dicha historia.
¿Pero qué pasa si queremos hacer prototipos de diseño y recoger feedback de los usuarios para ver si ese diseño pensado es fácil de usar, los usuarios se sienten cómodos, etc.? Así en caso negativo podremos rectificar.
¿De qué me sirve que me digan que algo no es usable cuando ya he implementado una funcionalidad? ¿No debería haber sido un tema preventivo también? ¿No debería intentar detectarse eso antes?
Aunque pienso que el hecho de realizar sprints cortos y contrastar con el cliente las funcionalidades implementadas al final de cada sprint facilita detectar ese tipo de desviaciones y rectificar, me ha llamado la atención el concepto de sprint de diseño ideado por Google (ojo, hablamos de diseño de experiencia de usuario, de cómo percibe el cliente la aplicación, no de diseño software).
Sprints de diseño
Como he dicho, esta es una técnica que implementaron en Google, y que es promovida por Google Ventures, una empresa que parte de Google, y que entre otras cosas, se encarga de invertir y ayudar a startups.
En este caso, su idea de sprint de diseño es algo muy parecido al concepto de sprint cero (El Sprint cero y el Sprint de release ). Un sprint de diseño es un período de tiempo antes de comenzar los sprints normales Scrum del equipo, en el que se hace una investigación de lo que se va a llevar a cabo en los sprints, se definen correctamente las historias de usuario, etc. En este caso el objetivo del sprint de diseño es empezar el sprint del equipo teniendo un prototipo de diseño de la interfaz de la aplicación, contrastado con el usuario y recibiendo su feedback.
Te recomiendo que le eches un vistazo a la web de Google Ventures, ya que en diversos artículos cuentan cómo hacen estos sprint de diseño.
Son de una semana, y cada día se realizan ciertas actividades:
– El lunes es el día en el que todos los roles implicados en el sprint de diseño se coordinan, intercambian ideas e información para así partir del mismo contexto sobre lo que se quiere desarrollar o saber cuál es el problema a resolver.
– El martes cada persona diseña sus propuestas para resolver dicho problema.
– El miércoles se escoge una propuesta final entre todos.
– Al día siguiente se hace el prototipo y el viernes se muestra al usuario y se hacen las pruebas pertinentes para recoger su feedback.
Lo bueno de esto es que participan distintos roles en el proceso y no solo gente con perfil de diseño experiencia de usuario. Estos perfiles aportarán mucho y guiarán el proceso, pero es aconsejable que esté el CEO, gente de negocio, algún desarrollador, etc., para aportar cada uno su visión y acordar un diseño final.
Otra cosa interesante es que estos sprints de diseño y todas las actividades que se llevan a cabo en los distintos días no son reuniones típicas, sino que se realizan dinámicas y existen facilitadores para fomentar la creatividad e innovación.
Así, estos sprints se basan en la técnica de Design Thinking, utilizada para fomentar la innovación y creatividad y desarrollada por la Universidad de Standford.
Normalmente, este tipo de sprint se suele utilizar enfocado a dos cosas:
1 – Diseñar prototipos con una mejor experiencia de usuario, y tomarlos como base para empezar a desarrollar en el sprint del equipo.
2 – Idear alguna solución de éxito, creativa ante algún problema del día a día de los usuarios o un nuevo producto.
Para terminar aquí tienes un ejemplo de un sprint de diseño, en este caso de una startup llamada DXLab:
Parece que la tendencia actual es promover la colaboración y creatividad en los equipos a través de distintas técnicas, como las que comentamos en Técnicas para motivar a un equipo software y que las reuniones sean más efectivas. y [Opinión] ¿Muchas reuniones? ¿Pocas reuniones? ¿Realmente sirven?, los juegos ágiles, etc.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola Ana María,
Por fin escribo después de llevar mucho tiempo leyéndoos tanto a ti como a Javier, sois todo un referente!
Este post especialmente me gusta por tocar un tema a veces olvidado… el User Experience, ese gran desconocido! 😉
Lo único que puedo añadir a lo dicho es que, para mí, UX y QA tienen una relación intrínseca, porque la calidad sólo tiene sentido si se valora desde el punto de vista del usuario.
Desde la perspectiva de un rol multidisciplinar, el profesional de QA debe involucrarse en la definición y consolidación de UX, o incluso asumir ese trabajo por completo si no existiese ese perfil en el equipo.
La Experiencia de Usuario siempre ha de ser tenida en cuenta antes de comenzar el desarrollo, donde la etapa de prototipado con wireframes y diagramas de flujo es fundamental, y donde la obtención de feedback vía usability testing o A/B testing es tremendamente útil para conseguir una validación previa de la solución por parte del cliente, clave para un posterior éxito.
Gracias por todo lo que compartes, saludos!