Diseñadores UX trabajando un Sprint por delante

13

Nuestros diseñadores de UX generalmente tienen una historia en Sprint X que los desarrolladores implementarán en Sprint X + 1 (los diseñadores de UX y los desarrolladores / evaluadores están en un solo equipo). Creo que esto tiene sentido porque si no tienes maquetas de pantalla y especificaciones claras, realmente no puedes estimar el trabajo durante la planificación de Sprint.

Sin embargo, en Scrum solo se supone que tiene historias de usuario que proporcionan valor al usuario. En nuestro caso, las historias de diseño de UX no proporcionan ese valor (son más como una actividad de preparación de pedidos pendientes). Por lo general, los entrenadores Scrum no recomiendan tener especificaciones completas antes del inicio del Sprint, una recomendación que me resulta difícil de entender.

Entonces, ¿ve alguna desventaja en nuestro enfoque? Parece funcionar para nosotros, pero va en contra de los principios de Scrum.

Eugene
fuente
3
¿Por qué el diseño UX no proporcionaría valor al usuario? Suponiendo que sigas buscando y sigas usando diseñadores UX, no puedo ver que haya una alternativa, y si no tienes una alternativa, ¿cómo puede haber desventajas?
Michael Shaw
Porque una maqueta de pantalla y una lista de requisitos de IU no proporcionan un valor directo al usuario. Estos proporcionan valor solo después de implementado en la historia del próximo Sprint.
Eugene
Su problema podría ser que no tiene diseñadores o, idealmente, ingenieros de UX, sino artistas gráficos. Simplemente usan Photoshop, ¿verdad? ¿Sin CSS JS o XAML o Interface Builder o alguna técnica de front-end? Entonces no tienes diseñadores. Necesitas diseñadores reales. Entonces no tendrás esta confusión.
RibaldEddie
No. Tenemos diseñadores de interacción con el usuario y diseñadores gráficos. Ambos trabajan un sprint antes del desarrollo
Eugene
10
¿Cómo interactuar con su base de clientes usando maquetas y prototipos no aporta valor al usuario? El valor no se define como código de envío. La tangibilidad es muy buena, pero no es esencial para el valor.
BobDalgleish

Respuestas:

15

Sin embargo, en Scrum solo se supone que tiene historias de usuario que proporcionan valor al usuario.

El valor no se mide solo en líneas de código enviable.

Parece estar insinuando que tener una interfaz de usuario bien diseñada no proporciona ningún valor. Claro que lo hace. Obviamente, hay valor para el usuario final, pero también hay valor para su equipo de desarrollo, que es una parte interesada perfectamente válida. Si no tiene las herramientas y los materiales para hacer su trabajo, no puede entregar valor al usuario final.

No te obsesiones con el dogma scrum. Scrum está ahí para hacerte más eficiente. Si hacer una historia de UX un sprint antes de implementar la interfaz de usuario te ayuda a entregar un mejor software, hazlo.

Bryan Oakley
fuente
2
"El software de trabajo es la medida principal del progreso", no UX. UX no vale nada si no está funcionando el software. Tendría razón si abogara por tener UX al mismo tiempo o más tarde con la función real, pero no lo hace, por lo que esta respuesta es completamente incorrecta.
Sklivvz
3
@Sklivvz: Creo que tenemos que estar de acuerdo en estar en desacuerdo. Si bien es cierto que el software de trabajo es la medida principal del progreso, no es la única medida. Debe hacerse una cierta cantidad de diseño por adelantado antes de que un equipo pueda comenzar a codificar. UX no es algo que puedas agregar al final.
Bryan Oakley
44
@BryanOakley Estoy de acuerdo en que se debe pensar un poco en todo el trabajo por adelantado, no solo en el ux. Sin embargo, el valor de ese trabajo lo deciden las partes interesadas. Si el trabajo ux se realiza un sprint por delante, el ciclo de retroalimentación se ha extendido al menos un sprint. Sugeriría que este es un riesgo innecesario. UX no es diferente del diseño, la arquitectura, el diseño de la base de datos o el formato del informe. Se PUEDE hacer todo en un sprint, con elementos de la cartera de productos que se crean como segmentos verticales de funcionalidad.
Derek Davidson PST CST
Se puede hacer en un Sprint, pero sin saber cuál será la experiencia del usuario, ¿cómo puede planificar el resto del trabajo? Si no conoce el diseño detallado del software, aún puede planificar el trabajo. Pero si ni siquiera sabe cómo será la pantalla y la funcionalidad, ¿cómo puede planificar algo?
Eugene
1
Al trabajar de forma incremental, como es la forma ágil habitual. Los desarrolladores producen un prototipo en colaboración en tiempo real con un diseñador ux o en base a sus propias ideas sobre ux; Una vez que un prototipo está funcionando, un diseñador lo revisa y proporciona una lista de cambios. Una historia no necesita planificación detallada; todo lo que necesita es una estimación del tamaño (y algunas disputas incluso eso).
Jules
13

Las principales desventajas son estas:

  1. Estás tramando: si tus diseñadores llegan tarde, tus desarrolladores se quedan sin trabajo; Si sus desarrolladores llegan tarde, su diseñador eventualmente trabajará más de una iteración por adelantado. No es una situación estable, no es sostenible .

  2. Sus diseñadores están trabajando por adelantado, usted está pagando costos por historias que pueden o no ser desarrolladas. Incluso si sucede raramente, todavía está tirando dinero.

  3. Sus diseñadores UX están tomando decisiones por adelantado sin involucrar a los desarrolladores. Le faltan ideas útiles y aumenta el riesgo de que los diseños sean totalmente erróneos o poco realistas. Esto es bastante común porque el diseño de UX no es un ejercicio "abstracto": debe elaborarse a partir de las características de la aplicación (incluido lo que es factible / aconsejable hacer o no técnicamente)

  4. Excluir o desautorizar a sus desarrolladores no es una forma sostenible de ejecutar un proyecto.

  5. Los diseñadores no están entregando valor: esto significa que es difícil, si no imposible, priorizar su trabajo correctamente. Por lo general, el trabajo del desarrollador se prioriza utilizando diferentes preocupaciones, valor, factibilidad en el próximo sprint, cantidad de esfuerzo. Se negocian y cambian muchas historias de tiempo para hacerlas "adecuadas" o debido a una discusión útil: si algo de esto cambia la IU (y puede suponer que lo hace si no es un simple detalle de implementación), ¿qué hace? con la historia? Ya no puedes jugarlo.

  6. Supone que una historia que puede encajar en una iteración para los diseñadores encaja en una iteración para los desarrolladores: ¿cómo puede dividir las historias para que esta suposición sea correcta?

Sklivvz
fuente
Los comentarios fueron en gran medida fuera de tema, por lo que se han eliminado.
ChrisF
1
Usted dice "Sus diseñadores UX están tomando decisiones ... sin involucrar a los desarrolladores". ¿Cómo lo sabes? El hecho de que estén trabajando un sprint por delante no implica que no estén trabajando con los desarrolladores. Quizás los desarrolladores son sus partes interesadas. Esto también va al punto 4: está asumiendo que los desarrolladores están siendo excluidos, pero ese no es necesariamente el caso. En cuanto a "Los diseñadores no están entregando valor", no podría estar más en desacuerdo. ¿No ves ningún valor en UX correctamente diseñado? Si bien creo que plantea algunos puntos dignos de discusión, está haciendo muchas suposiciones que podrían no ser ciertas.
Bryan Oakley
@bry o trabajan en ux o no. Seguramente estar involucrado en el proceso ux califica como "trabajando" en una historia. Con respecto a su evaluación de valor ... No agregan valor si trabajan por adelantado porque no producen nada que pueda implementarse. Si algo nunca llega al cliente, no tiene valor para ellos.
Sklivvz
re: "estar involucrado en el proceso ux califica como" trabajar "en una historia". No necesariamente. La gente viene y me hace preguntas todo el tiempo, eso no significa que estoy trabajando en sus historias.
Bryan Oakley
2
@BryanOakley seguramente, pero los problemas aún se aplican: compare "enviar de vuelta" un diseño porque no es realista ejecutarlo frente a hacerlo bien la primera vez porque se hace mientras un desarrollador está trabajando en él. Además, hay problemas que solo se descubren durante la implementación, y en ese momento el diseñador está haciendo la próxima historia ...
Sklivvz
6

Me gusta por dos razones:

  1. parece funcionar para ti; ¡Es difícil discutir con éxito!
  2. el equipo de UX toma la historia y comienza la conversación temprano , y las conversaciones son una especie de punto de las historias
Steven A. Lowe
fuente
4

Un requisito básico de Scrum es que el equipo de scrum tenga todas las habilidades necesarias para crear un producto potencialmente liberable. En la situación que describe, esto no está sucediendo.

El equipo UX no está produciendo productos potencialmente liberables y el equipo scrum no es capaz de producir cortes verticales de funcionalidad, ya que no tienen todas las habilidades requeridas. Estas son disfunciones.

Sklivvz ha escrito una excelente publicación sobre los problemas a los que podrían conducir las disfunciones anteriores. En resumen, no creo que estés practicando Scrum.

Pero no hay absolutamente nada de malo en eso. Si ha descubierto una forma de trabajar que ofrece valor para todos, y está contento con eso, continúe haciéndolo. Mi único consejo sería inspeccionar y adaptar con frecuencia.

Sin embargo, tenga en cuenta que si su objetivo es entregar software utilizando Scrum, deberá abordar las disfunciones identificadas.

Derek Davidson PST CST
fuente
Como dije en mi publicación original: "Los diseñadores de UX y los desarrolladores / evaluadores están en un solo equipo"
Eugene
2
@Eugene ¿En qué sentido están en el mismo equipo? Diría que si están trabajando un sprint por delante, no están en el mismo equipo. Por cierto, Scrum también tiene claro que no reconoce "sub-equipos", así que nuevamente, diría que su situación no suena como Scrum. Ciertamente no como lo sé.
Derek Davidson PST CST
Trabajan un sprint por delante con el resto del tiempo. El resto del equipo generalmente al menos revisa su trabajo y a veces ayuda con el diseño en sí.
Eugene
4

Aquí hay dos problemas, uno sobre el diseño centrado en el usuario y el otro sobre la alineación de sprint.

Primero : las historias de los usuarios deben estar alineadas con las necesidades de los usuarios, no solo con el retraso. Las historias UX deben tener un valor claro para los usuarios. Esto no requiere una especificación completa y una breve declaración como,

"Los usuarios tendrán un acceso más fácil a la actividad de la cuenta en una sola página en lugar de dividirse entre varias páginas"

es accesible y adaptable a diversas implementaciones y, sin embargo, sigue siendo claro sobre el valor para el usuario (acceso más fácil a la actividad de la cuenta).

Segundo : alineación de Sprint. UX diseña características en sprint X que los desarrolladores implementan en spring X + 1. En la práctica, esto sucede en muchas tiendas y, a veces, puede ser más parecido a la implementación en sprint X + 2 o X + 3. Con un equipo apretado y experimentado, esta configuración puede funcionar. Se vuelve desafiante si tiene un nuevo equipo o nuevos miembros que no están familiarizados con los conjuntos de habilidades, preferencias, hábitos, estilos de trabajo y tendencias de otros miembros del equipo. Si han estado trabajando juntos por menos de 6 meses, es probable que esto sea un problema.

Da un paso atrás y vuelve a evaluar. En el lado positivo, los diseñadores y desarrolladores de UX trabajan codo con codo, lo cual es una bendición. Comience asegurándose de que sus historias tengan un valor claro para los usuarios.

atimba
fuente
2

Uno de los posibles problemas que veo es que en Scrum el alcance del sprint N + 1 normalmente se determina justo antes de que comience. Entonces, ¿cómo puede hacer UX para las historias de sprint N + 1 en sprint N antes de saber qué historias estarán dentro del alcance? Si decides arreglar el alcance del sprint N + 1 al comienzo del sprint N, pierdes algo de flexibilidad.

Frank Bakker
fuente
1

Sin embargo, en Scrum solo se supone que tiene historias de usuario que proporcionan valor al usuario. En nuestro caso, las historias de diseño de UX no proporcionan ese valor (son más como una actividad de preparación de pedidos pendientes).

A mi modo de ver, están proporcionando mucho valor a sus usuarios. La cuestión es que su usuario no es el usuario final de la compañía, sino el equipo de desarrollo que implementará la función en sprint X + 1.

mverardo
fuente
1

Te estás quedando atrapado en la religión del proceso y en el camino veo que scrum / agile se usa mal y los usuarios se etiquetan mal. Scrum no es una herramienta universal, es un medio para un fin.

Creo que su grupo ha etiquetado erróneamente quiénes son sus usuarios y están planeando para el público equivocado.

El grupo UX está utilizando scrum de la manera clásica, valor de usuario y adaptación ágil a las entradas de algunos usuarios finales mágicos. Ellos son los que tienen usuarios. Su grupo está usando mal el scrum porque simplemente está completando la mecánica para hacer que un diseño existente funcione, no se requiere nada ágil y scrum está cumpliendo el rol de seguimiento de la administración.

Es por eso que esto le parece incorrecto, en realidad no necesita ni se beneficia de scrum de ninguna manera porque está en un grupo de servicio y su trabajo fluye hacia adelante desde las personas UX que ya han hecho las partes ágiles / scrum.

No hay nada realmente malo allí, solo hay un proceso diferente en lugar de lo que le dijeron.

Patrick Hughes
fuente