diseñadores de 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 / probadores están en un equipo). Creo que esto tiene sentido porque si no tienes simulaciones 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 tienes historias de usuario que proporcionan valor al usuario. En nuestro caso, las historias de diseño de UX no proporcionan tal valor (son más como una actividad de preparación de trabajos atrasados). Por lo general, los coaches de 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.

    
pregunta Eugene 15.03.2014 - 16:17

8 respuestas

15
  

Sin embargo, en Scrum solo debes tener historias de usuario que   proporcionar valor al usuario.

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

Parece que estás dando a entender que tener una IU bien diseñada no proporciona ningún valor. Claro que lo hace. Obviamente, hay un valor para el usuario final, pero también lo es 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 un sprint de UX Story One antes de implementar la IU te ayuda a entregar un mejor software, hazlo.

    
respondido por el Bryan Oakley 15.03.2014 - 22:37
12

Las principales desventajas son estas:

  1. Estás a punto: si tus diseñadores llegan tarde, tus desarrolladores se quedan sin trabajo; Si sus desarrolladores llegan tarde, su diseñador eventualmente trabajará con 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 desarrollarse. Incluso si esto sucede raramente, todavía estás tirando dinero.

  3. Sus diseñadores de UX toman 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 ser elaborado a partir de las características de la aplicación (incluido lo que es factible / aconsejable hacer o no técnicamente)

  4. Excluir o desempoderar 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 se cambian muchas historias de tiempo para hacerlas "ajustadas" o debido a una discusión útil: si algo de esto cambia la interfaz de usuario (y puede asumir que si no es un mero detalle de implementación), ¿qué hace? con la historia? No puedes jugar más.

  6. Está asumiendo 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?

respondido por el Sklivvz 15.03.2014 - 21:04
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 historias
respondido por el Steven A. Lowe 15.03.2014 - 19:00
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 de UX no está produciendo un producto potencialmente liberable y el equipo de scrum no es capaz de producir segmentos verticales de funcionalidad ya que no tienen todas las habilidades necesarias. Estas son disfunciones.

Sklivvz ha escrito un excelente post sobre los problemas que las disfunciones anteriores podrían provocar. 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 todos están contentos con ella, 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.

    
respondido por el Derek Davidson PST PSM II CSP 16.03.2014 - 11:45
4

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

Primero : las historias de los usuarios deben estar alineadas con las necesidades del usuario, no solo con el trabajo acumulado. Las historias de 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 adaptable y adaptable a diversas implementaciones y aún así tiene claro el valor para el usuario (acceso más fácil a la actividad de la cuenta).

Segundo : alineación 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 como una implementación en sprint X + 2 o X + 3. Con una nitidez estrecha y un equipo 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 has estado trabajando juntos durante menos de 6 meses, es probable que esto sea un problema.

Retrocede un paso, y reevalúa. En el lado positivo, tenemos a los diseñadores y desarrolladores de UX trabajando codo con codo, lo que es una bendición. Comience por asegurarse de que sus historias tengan un valor claro para los usuarios.

    
respondido por el atimba 20.03.2014 - 20:31
2

Uno de los posibles problemas que veo es que en Scrum el alcance para el 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 en el alcance? Si decides arreglar el alcance para Sprint N + 1 al inicio de Sprint N, perderás algo de flexibilidad.

    
respondido por el Frank Bakker 03.10.2015 - 14:37
1
  

Sin embargo, en Scrum solo debes tener historias de usuario que   Proporcionar valor al usuario. En nuestro caso las historias de diseño de UX no   proporcionar dicho valor (son más como una actividad de preparación de trabajos pendientes).

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

    
respondido por el mverardo 20.03.2014 - 21:50
0

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 incorrectamente. Scrum no es una herramienta universal, es un medio para un fin.

Creo que su grupo ha etiquetado incorrectamente quiénes son sus usuarios y está planeando para la audiencia incorrecta.

El grupo UX usa scrum de la manera clásica, el valor del usuario y la adaptación ágil a las entradas de algunos usuarios finales mágicos. Ellos son los que tienen usuarios. Su grupo está haciendo un mal uso de 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 le parece mal, en realidad no necesita ni se beneficia de scrum de ninguna manera porque está en un grupo de servicio y su trabajo fluye hacia delante de las personas de UX que ya han hecho las partes ágil / scrum. .

No hay nada realmente malo allí, solo hay un proceso diferente en lugar de lo que se te dijo.

    
respondido por el Patrick Hughes 04.10.2015 - 00:07

Lea otras preguntas en las etiquetas