¿Quién hace el UX en un proyecto scrum?

OKAY. Digamos que estás trabajando en un proyecto de scrum de libro de texto. Tienes un scrum master que colabora con el propietario de un producto. El próximo sprint es pesado en la interfaz de usuario: cuando tus codificadores comiencen a construir pantallas, realmente querrás tener algo de idea de cómo se verán.

¿Quién hace el wireframing y cuándo? El dueño del producto? Alguien que apoya al dueño del producto? El maestro scrum? Si tienes un experto en UX, ¿trabajan junto a los codificadores después de el sprint ha comenzado, o le suministran alámbricos y maquetas por adelantado que se encuentran junto a sus tarjetas de historia y restricciones para guiar e informar el trabajo que están haciendo los desarrolladores?

Estoy bastante seguro de que necesitamos ayuda con UX, ya ves, pero realmente no estoy seguro de dónde aplicarla ...

EDITAR: Permítanme reformular la pregunta.

¿Cómo ofrece una experiencia de usuario consistente y de alta calidad en un proyecto ágil?

El diseñador de interacción

UX! = UI Necesita un diseñador de interacción experimentado para ofrecer una buena experiencia de usuario, contrario a la creencia popular de que no un programador. Para todos los programadores que piensan que pueden hacer UX (eso me incluye a mí) déjenme decir esto. Ser bueno en el diseño de interacción requiere al menos tanto tiempo como ser bueno en la programación. ¿Cuánto tiempo has pasado haciendo diseño de interacción pura?

En la fase inicial es responsabilidad de los diseñadores de interacción:

1. Extraer los objetivos reales de la solución del propietario del producto.
2. Defina las personas que usarán la solución.
3. Escriba escenarios que sean historias sobre cómo se usará la solución.
4. Compile un documento de diseño que deje poco espacio para la ambigüedad desde el punto de vista de UX

Durante el proyecto, es tarea de los diseñadores de interacción asegurarse de que se sigan esas pautas y abordar cualquier problema adicional que surja (y lo hará).

Estoy seguro de que muchos programadores se enfrentarán a este enfoque, ya que todos sienten que son la excepción que puede diseñar interfaces "maravillosas", probablemente no lo sean. Por otro lado, una buena relación de diseñador de interacción - programador es a menudo muy agradable para el programador y no tiene que luchar contra una "estúpida especificación". Desafortunadamente, los buenos diseñadores de interacción son difíciles de encontrar en mi experiencia, pero están ahí afuera.

Como siempre, recomiendo profundamente los libros de Alan Coopers sobre el tema ("Acerca de la cara" y "Los reclusos están dirigiendo el asilo")

Sugiero organizar el trabajo del tipo UX de la misma manera que el resto del equipo. Debe ser considerado un miembro igual del equipo, participar en enfrentamientos y comunicarse estrechamente con los programadores.

Idealmente, las maquetas deben hacerse al menos un sprint por adelantado, pero para las características más pequeñas, podría tener sentido considerar la creación de maquetas como una subtarea de una historia planificada para la iteración actual.

Como siempre con ágil, use el sentido común, experimente con diferentes enfoques y manténgase en el que funcione bien para su situación particular.

En mi opinión, este es un caso especial que debe manejarse de manera especial. Scrum Master definitivamente no participará en esto, no es su papel en absoluto. El equipo generalmente es un grupo de desarrolladores y la mayoría de ellos no tiene experiencia con UX y será una pérdida de tiempo forzarlos a esto. Contratará a un experto en UX y el experto no será parte del equipo: el equipo debe ser multifuncional y el experto en UX probablemente no sea un desarrollador. Además, el experto UX no estará en el proyecto durante toda su duración. El experto en UX trabajará con el propietario del producto un sprint por delante para preparar maquetas y estructuras de alambre para las próximas historias de usuarios para que el equipo sepa lo que tendrá que hacer en el próximo sprint: habrá maquetas disponibles durante la reunión de planificación.

Editar:

Investigué un poco más porque sabía que había leído sobre esto en alguna parte y finalmente lo encuentro en Triunfar con Agile: Desarrollo de software usando Scrum por Mike Cohn . Mike discute exactamente el papel del diseñador UX en el equipo. Su descripción inicial es similar a la mía y considera que es un cambio natural cuando la compañía cambia el método de desarrollo de cascada a Scrum, pero luego concluye que no es una forma recomendada. La razón es que si los diseñadores de UX no son parte del equipo, pueden pensar en sí mismos como un equipo separado y no tienen que compartir el compromiso del equipo de desarrollo.

A pesar de esto, la respuesta de @Adam Byrtek parece ser la correcta. Haga que el tipo UX forme parte del equipo y permítale cooperar con los desarrolladores en las historias de usuario implementadas actualmente. No le tomará todo el tiempo al tipo de experiencia de usuario, por lo que también cooperará con el propietario del producto o el cliente para preparar maquetas y estructuras de alambre para los próximos sprints.

Estoy suscrito al cuadro de alerta de Jakob Nielsen (principalmente debido a sus críticas sobre prácticas de diseño web molestas) y recuerdo que recientemente leí algunos artículos sobre el tema (aunque apenas entiendo el proceso de desarrollo ágil completo), tal vez serían de cualquier uso para usted:

• Proyectos ágiles de experiencia de usuario
• Proyectos de desarrollo ágil y usabilidad

Para "libro de texto Scrum":

En primer lugar, los Scrum Masters no colaboran con los propietarios de productos, bueno, en ningún sentido aparte de eso, todo el equipo, incluidos SM y PO, colabora para construir el sistema.

En segundo lugar, se supone que los equipos Scrum son homogéneos con los miembros del equipo multifuncional. Entonces no tendrías un "UX Guy".

Además, probablemente no construirías el UX a Sprint antes del código funcional. Las características se entregan completamente dentro de un solo Sprint. Si el UX asociado con una característica es demasiado complejo para entregar junto con el código funcional en un único Sprint, entonces se divide toda la característica en algo que se puede hacer, incluidos los elementos UX, en un solo Sprint.

¿Quién hace UX en un proyecto de cascada? ¿Quién desarrolla el mainframe en un proyecto XP?

La metodología del proyecto no importa. Cada proyecto de tecnología requiere ciertos roles especializados. A veces, un proyecto puede salirse sin un "diseñador de interacción" totalmente autorizado y vinculado (lo que sea que eso signifique). A veces necesitas a alguien que se especialice. Pero lo mismo podría decirse de cualquier otro papel.

Entonces, en su segunda pregunta sobre cómo ofrecer una experiencia de usuario de alta calidad usando Agile. Lo logramos en el último proyecto scrum en el que estuve involucrado al involucrar al analista de negocios y al cliente temprano y con frecuencia. Además, teníamos un desarrollador que tenía un buen ojo para UX. Tiende a hacer pequeños ajustes a las IU en las que los desarrolladores estaban trabajando después de haber realizado las confirmaciones.

No entregamos UX perfecto al final de cada sprint. Las demostraciones generalmente exponen un problema o dos desde una perspectiva UX. Pero los arreglamos para el próximo sprint (si valía la pena para el cliente) y para cuando lanzamos a producción teníamos una experiencia de usuario muy sólida.

Si por UX te refieres al diseñador de interfaz de usuario, son solo otro rol o recurso para el equipo. El diseño de la interfaz de usuario, como cualquier diseño, corta un proyecto. Hay una cantidad razonable de trabajo de arquitectura / diseño que se debe hacer por adelantado y hay una cantidad que se puede hacer a medida que avanza.

Cabe señalar que las tareas de diseño de la interfaz de usuario a menudo no encajan en el mismo alcance que un sprint de desarrollo. Al diseñar un componente de la interfaz de usuario, el diseño puede requerir numerosos sprints para implementar.

En la práctica, tiendo a encontrar que los diseñadores de UI / UX necesitan un plazo de entrega razonable para tratar aspectos que deben ser consistentes en toda la solución. Me gusta pensar en ello como arquitectura de software. El diseño de componentes específicos a menudo se puede hacer un sprint antes de la implementación, pero tiendo a encontrar que una vez que los diseñadores se ponen en marcha, pueden superar la implementación. Los sprints posteriores tienden a ser buenos lugares para implementar / explorar la apariencia, así como para obtener retroalimentación de usabilidad a medida que la solución comienza a tomar forma. Los resultados de estos ejercicios posteriores se retroalimentan en la planificación del próximo sprint.