Estoy tratando de integrar un equipo de UX de unos 14 diseñadores de UX en una organización de ingeniería de software de unos 100 desarrolladores. Uno de los muchos desafíos que estoy tratando de resolver es cómo lidiar con cosas como las pruebas de usabilidad. Estoy trabajando con muchas suposiciones aquí (corríjame si son malas suposiciones):
El trabajo del equipo de UX debe estar en la cartera de pedidos como historias de usuario. Punto de aclaración: en este momento, hay un retraso en el diseño y luego hay un retraso en la ingeniería. Así que no somos "full stack".
Una historia de usuario debe poder completarse en un sprint.
Así que aquí está mi pregunta:
¿Tiene algún sentido escribir una historia de usuario para una prueba de usabilidad? No parece centrado en el usuario. Por ejemplo, "Como usuario, quiero que se pruebe la usabilidad de la aplicación para que podamos identificar los problemas y solucionarlos". ¿Qué? Eso es una tontería. ¿Cómo deberíamos integrar este tipo de tareas en nuestro backlog?
Por lo general, lleva más de 4 semanas completar una prueba de usabilidad. Tenemos que reclutar a los participantes (demografía muy estrecha), planificar la prueba, ejecutar la prueba y luego informar sobre la prueba. No se puede hacer todo eso en un sprint de 2 semanas. ¿Ahora que? ¿Cómo escribo una historia para algo más pequeño que la prueba de usabilidad completa? ¿Una historia solo para escribir el plan de prueba, luego otra historia para reclutar a los participantes? Eso realmente parece estirar la definición de una historia de usuario.
Su pregunta se titula sobre la integración en un equipo Scrum, pero parece que no está organizado como lo estaría un equipo Scrum típico.
Por lo general, sus diseñadores de UX serían miembros del equipo, desarrollan software, al igual que sus programadores.
No debe crear historias de usuario para tareas de UX. Las historias de usuario deben cumplir con los criterios de INVEST . Las tareas de UX probablemente violarían:
En su lugar, debe integrar un diseñador de UX en sus equipos de ingeniería e incorporar las tareas de UX en su definición de hecho.
Su equipo (es decir, programadores y UX) asume la responsabilidad de completar todo el trabajo de UX. Los equipos autoorganizados significan que si hay demasiado trabajo para que lo haga el tipo de UX individual, entonces los otros miembros del equipo también deberían ayudar. Eso significa que tendrán que colaborar juntos para completar las tareas.
En cuanto a su segundo punto, parece que está aplicando un proceso de cascada a su prueba de UX. Esto limitará la velocidad a la que puede lanzar software. En Scrum, cada sprint debe entregar software potencialmente entregable. Si no ha realizado pruebas de UX, no debe publicar. Debe intentar dividir su trabajo de UX en secciones lo suficientemente pequeñas, trabajando en estrecha colaboración con los desarrolladores para hacer UX en funciones recién creadas.
Realmente no ha proporcionado suficientes detalles sobre el tipo de trabajo que realiza el equipo de UX, por lo que es difícil dar más consejos que aplicar las prácticas estándar de Scrum.
El mejor lugar para cumplir con este requisito sería la Definición de Listo de su equipo. Una política de proceso utilizada para garantizar la calidad.
Habla con tu equipo sobre cómo probar mejor la usabilidad en el ciclo de sprint. Estoy seguro de que tendrán muchas ideas interesantes y una política de definición de hecho es mejor para el equipo. Algunas sugerencias podrían ser;
Pair devs with UX
Have UX reviews
Get an end user to UAT
Descubrirá que este enfoque significa que una prueba de usabilidad completa al final de un período determinado será menos dolorosa.
También parece que las pruebas de usabilidad llevan mucho tiempo. ¿Puedo sugerirle que eche un vistazo al nuevo libro de Steve Krug, Rocket Science Made Easy ?
Si está lanzando software cada 2 a 4 semanas, puede hacer la prueba de usabilidad en un producto realmente lanzado, fuera del sprint, pero tan pronto como finalice la función. Obtendrá comentarios y eso se remonta a la acumulación. Hasta que reciba los comentarios, ha podido lanzar un producto funcional.
Si eres capaz de hacer todo eso en un sprint, hazlo por todos los medios. Si no es así, haga las pruebas fuera del sprint, pero trate de no dejar que el equipo de scrum haga todo el trabajo para preparar las pruebas.
Algunas pequeñas pruebas, como hacer que los usuarios reales usen las funciones antes de que se registren, son ideales. Tener un par de usuarios finales de guardia a quienes puede mostrar parte de su trabajo puede brindarle comentarios muy rápidos en muy poco tiempo.
Solo asegúrese de que el tiempo entre el lanzamiento del producto (incluso si es una versión beta o una versión candidata) y la recepción de sus comentarios sea lo más corto posible. De lo contrario, la retroalimentación llega demasiado tarde y la reelaboración será mucho más costosa.
Por mi propia experiencia recomendaría a:
Incluya la usabilidad en los criterios de aceptación. Si falla, hay que rehacer la historia. En el mismo sprint o en el siguiente sprint - siempre que haya tiempo y prioridad
Tienes que reducir tu esfuerzo. Siempre reclute participantes en un tiempo de 2 semanas (dependiendo de la duración del sprint). No importa qué mostrarles.
Un día antes, revisa lo que está listo y funcionando y muéstraselo. Haga una especie de plan de prueba estándar para ahorrar tiempo.
Invite a programadores o gerentes de producto a sus pruebas como observadores o filme. Después de la prueba, discútalo brevemente y prepare una presentación de PowerPoint para mostrarla al equipo de desarrollo al día siguiente. Muestre el video si es necesario.
¡Habla sobre tus recomendaciones con el equipo de desarrollo y listo! Ya no se necesita un 10 buscapersonas, se transporta por la boca, cara a cara.
Es más una prueba de partes del software. Después de un tiempo, podría ser útil probar todos juntos en una prueba de usabilidad clásica.
Incluso aquí puedo recomendar el blog Ucd UX del equipo de Autodesk UX. Tienen buenos consejos para un reclutamiento eficiente, pero no puedo encontrarlo ahora.
Perdido en Agileland