¿Cómo incorporar UX/UI en sprint correctamente cuando se requieren maquetas para estimar una historia?

Disculpas si ya se ha hecho la pregunta, realmente no pude encontrar la respuesta al mirar alrededor.

Estoy luchando por encontrar una manera de manejar UX/UI de una manera ágil. Me gustaría ser "totalmente" ágil y que el diseño sea parte del sprint para las historias de usuario donde se necesita, pero cada vez que intento hacer esto, causa cualquiera de estos dos problemas (a veces ambos):

  1. Los desarrolladores necesitan al menos algunos esquemas/bocetos para comprender los requisitos y poder estimar con precisión
  2. El diseñador tarda tanto en entregar los diseños para la historia que los desarrolladores ya no tienen tiempo para implementar la historia en el sprint. A veces, los diseños pueden incluso ser más largos que nuestras iteraciones de sprint de 2 semanas.

He pensado en obtener al menos los wireframes antes de que la historia pueda incluirse en el backlog del sprint, algo así como una Definición de Listo, pero siento que esto es más una cascada que un enfoque ágil. Más aún si es necesario realizar diseños con anterioridad para que la historia se estime con precisión.

En el caso de mantener los elementos de diseño hechos antes del sprint, ¿cómo maneja esto en SCRUM? Es decir: ¿cómo planifica el trabajo que debe realizarse antes del sprint/planifica la capacidad de sus diseñadores? Estaba pensando en tener tareas de diseño separadas que se vinculen a las historias, de esa manera podríamos agregarlas al trabajo pendiente del sprint para que el diseñador pueda trabajar en las tareas de las historias que estarán en el próximo trabajo pendiente del sprint mientras los desarrolladores trabajan en el actual. tareas de sprint.

La razón por la que estaba pensando en tareas separadas vinculadas a las historias es porque las historias en sí mismas no se pueden poner en el sprint ya que los desarrolladores no podrían entregar su versión de la historia. ¿Pensamientos?

Todo esto es un olor a proceso. Está tratando el diseño como "aguas arriba" del desarrollo y las pruebas, cuando las tres disciplinas deberían trabajar juntas para crear una mentalidad colaborativa de prueba primero.
@ToddA.Jacobs Como mencioné, me encantaría poder hacerlo, traté de que trabajaran juntos, pero ha creado bloqueadores, que es la razón principal de esa publicación. ¿Cómo propondría resolver la solución y hacer que las disciplinas trabajen juntas sin que los diseños bloqueen el desarrollo?
No hay una bala mágica. El liderazgo, la influencia, el entrenamiento, la educación, la estructura de la organización o la intervención de la gestión son todas opciones. Encuentra el problema, soluciona el problema. Si carece de la influencia o la autoridad para hacer estas cosas, escale a la alta dirección.

Respuestas (6)

Me gustaría ser "totalmente" ágil y que el diseño sea parte del sprint [...]

Creo que aquí hay un malentendido, que es que en Agile no hay "nada por adelantado" y que la iteración actual es el único lugar donde las cosas deben suceder. Si existe este malentendido, las personas intentan planificar y trabajar solo para el sprint actual, que no siempre es el mejor enfoque para todas las situaciones, como habrá notado.

Si los diseños son complejos y tardan en construirse y es esencial que los desarrolladores sepan cómo se ven para saber cómo estimar y qué trabajo implica, entonces obviamente necesita los diseños antes de planificar su sprint actual. Eso significa que el diseñador debe trabajar antes que los desarrolladores para acordar con el PO lo que se necesita desde el punto de vista de UX/UI y preparar los diseños con anticipación.

Las únicas cosas a las que debe prestar atención son:

  • que el diseñador no se convierta en un cuello de botella y un bloqueador en el trabajo de su equipo. Usted dice que "A veces, los diseños pueden incluso ser más largos que nuestras iteraciones de sprint de 2 semanas". Esta es una bandera roja. ¿Por qué tardan tanto? ¿Los diseños son muy complejos? ¿El diseñador es perfeccionista y tiene tendencia a enchapar en oro las cosas? ¿La orden de compra es el problema porque cambia constantemente de opinión sobre cómo debería verse el diseño? ¿Estás haciendo mal el refinamiento y no estás dividiendo el trabajo en partes más pequeñas y tienes que trabajar con una gran historia en lugar de unas pocas más pequeñas? ¿Un diseñador no es suficiente para el tamaño del equipo? ¿Necesitas contratar más diseñadores? ¿Qué está pasando? Averigüe las causas fundamentales del problema para encontrar una solución que realmente arregle los problemas, no los síntomas.
  • tratar de evitar el desperdicio. Si el diseñador trabaja por delante del equipo, es posible que le falte información que el equipo pueda ofrecer. Esto significa que corre el riesgo de que el diseñador cree algunos diseños que luego, durante una reunión de planificación, se descubre que son inadecuados de alguna manera y necesitan ser rehechos. Esto genera desperdicio. Y aquí vuelvo al "nada por adelantado" que mencioné anteriormente. Tienes que prestar mucha atención a la cantidad de trabajo que hace el diseñador antes de tiempo. Demasiado trabajo en un horizonte de tiempo amplio puede causar mucho desperdicio. Por lo tanto, debe hacer "lo suficiente" de trabajo y planificar con anticipación, para tener los diseños disponibles para los desarrolladores a tiempo, pero no tanto como para que los diseñadores terminen trabajando por su cuenta en lugar de estar involucrados en "inspeccionar, adaptar, experimentar y aprender" en bucle como el resto del equipo.
Hola Bogdan, muchas gracias por tu respuesta. Se parece mucho al enfoque que estoy pensando tomar al hacer un diseño por adelantado, pero ¿no estamos volviendo a caer en una forma de trabajo en cascada, aunque solo durante un par de semanas a la vez, haciendo diseños y LUEGO entregando a los desarrolladores? Por supuesto, los desarrolladores estarían disponibles para chatear con el diseñador durante su trabajo y viceversa para los diseñadores durante el trabajo de desarrollo para pequeños ajustes para mantenerlo ágil, pero todavía me pregunto si eso es realmente ágil entonces.
Tal vez estoy complicando demasiado la forma en que "imagina" ágil/scrum y trato de ser estricto con la regla. Siendo realistas, todavía podemos "adaptarnos al cambio" porque solo estamos diseñando un sprint por delante, no toda la UX/UI de la aplicación a la vez, por lo que no debería haber demasiados "desperdicios" o problemas de comunicación de esa manera.
@Paz: Idealmente deberías tener todas las actividades en el mismo sprint. Desafortunadamente, no vivimos en un mundo ideal. Y en el mundo real se aplican compensaciones. De hecho, existe el riesgo de volver a caer en un enfoque de estilo Waterfall, pero si está practicando Agile, entonces experimentará y luego inspeccionará y se adaptará . Esto le ayudará a encontrar el equilibrio adecuado.
¿Qué pasaría si tuviera una reunión entre el desarrollador, el diseño, etc., donde se diseñaron y acordaron las maquetas? Entonces, ¿el diseño tiene una historia en este sprint para pulir/finalizar las maquetas y los desarrolladores pueden comenzar a trabajar en la implementación del diseño basado en las maquetas preliminares?
@JeffC De hecho, pensé en hacer esto. Potencialmente, podría funcionar si logramos mantener las historias pequeñas y esto se puede planificar antes de que ocurra la planificación del sprint, como durante las actividades de refinamiento de PBI. Todavía corremos el riesgo de que la historia falle si las subtareas de diseño no se completan a tiempo durante el sprint en ese momento. Pero vale la pena intentarlo :)
@Paz estuvo de acuerdo... Creo que sería algo que necesitarías probar varias veces para que puedas aprender a estimar el tamaño de las diversas tareas/subtareas, pero debería ser factible.

Ya comprende que las actividades de UX/BA deben realizarse antes de que comience el Sprint, ya que los desarrolladores necesitan historias para la planificación. Su verdadera pregunta es cómo justifica este enfoque desde la perspectiva de Scrum (siempre es la pregunta con Scrum).

Puedo ver un par de formas de justificarlo:

  1. Las tareas de UX/BA son parte del sprint. Pero su trabajo no es entregar un software que funcione, sino que aún se trata de entregar valor . Que es todo lo que necesitamos desde la perspectiva de Scrum.
  2. Trate a UX/BA como propietarios de productos. PO tiene que estar preparando historias para la planificación.

En cuanto a la gestión de tareas: personalmente, devolvería esas tareas a TODO y se las daría a los desarrolladores. Solo para disminuir la cantidad de ruido adicional en el rastreador de tareas. Puedes decir que el trabajo de UX es preparar (describir) esas tareas para los desarrolladores.

PD: pareces mezclar Agile y Scrum mucho. Son 2 conceptos muy diferentes. Ágil es muy importante ya que es básicamente un sinónimo de Eficaz, mientras que Scrum... es solo una de muchas metodologías. No es el mejor, probablemente no el peor.

PPS: no intentes ser "totalmente ágil". Cuando dices esto, significa que estás tratando de seguir algunas ideas abstractas "al pie de la letra". Pero la idea principal de Agile es ser flexible y tomar decisiones que tengan sentido en su situación particular. Así que Agile siempre es diferente.

En Scrum, tienes una Definición de Listo. Igualmente importante es su Definición de Listo , es decir, qué trabajo está listo para la planificación del sprint.

Ahora, dado que se puede aplicar un nivel de "Terminado" a cada estación en un flujo de trabajo, es razonable suponer que esto incluye la transición del trabajo al propio Sprint Backlog. En otras palabras, antes de que el trabajo pueda planificarse en un Sprint, los elementos relevantes en el Product Backlog deben estar "Terminados" en términos de estar suficientemente bien descritos y entendidos. El Equipo de Desarrollo debe comprender lo suficiente de su alcance para poder planificarlo en un Sprint y enmarcar algún tipo de compromiso con respecto a su implementación para que se pueda cumplir un Sprint Goal.

— Caminando a través de una definición de Ready ( Scrum.org )

Es un error pensar que una historia debe diseñarse, desarrollarse y probarse completamente en un solo sprint. Pone al equipo precisamente en la misma situación que usted describe. El "diseño" de una historia podría incluir muchos artefactos fuera del código. Cuanto más grande sea la historia, más trabajo de preparación debe completarse antes de que el equipo pueda estimar el esfuerzo y diseñar la solución técnica. De hecho, una maqueta o visual de algún tipo es esencial. También tiene razón al identificar que este trabajo de diseño puede llevar más de un sprint.

Recuerde el objetivo principal de Agile y Scrum, francamente: adaptarse al cambio. La eliminación de Big Design Up Front no significa que no haya ningún diseño por adelantado. Diseñe lo suficiente para que los desarrolladores y evaluadores tengan la confianza de que pueden comenzar y completar el trabajo en un solo sprint.

En lugar de adaptar el flujo de trabajo de recopilación de requisitos para que se ajuste a un sprint, trabaje con los desarrolladores y evaluadores para definir qué está "listo" para la planificación del sprint. Deje que el equipo le diga qué información y artefactos de diseño necesitan. Esto podría hacerse informalmente como conversaciones o durante una sesión de preparación de trabajos pendientes. Esto significa que UX y BA deben trabajar por delante del equipo. Simplemente no se adelante demasiado porque UX y BA no pueden adaptarse al cambio.

Gracias @Greg, creo que resueno bien con tu respuesta y me hace pensar que estoy en el camino correcto. De hecho, estoy tratando de "minimizar" la cantidad de trabajo de diseño que se realiza por adelantado para seguir siendo "ágil" en ese sentido. Solo lo suficiente para que las historias estén en un estado "listo". Tengo un kanban para que mi diseñador tome las historias a través de su propio flujo y luego las marque como "listas para el desarrollo", que es cuando se pueden colocar en la acumulación de sprint que se ejecuta como SCRUM. Es demasiado pronto para decir si funcionará, pero al equipo parece gustarle el enfoque.

Veo dos posibles soluciones:

  1. Considere al diseñador de UX/UI como parte del equipo SCRUM. Todo lo que hace es una historia, como todas las demás historias. Ahora ha reducido el problema al desafío habitual de dividir una tarea que abarca más de un sprint, o más de un participante requerido, en partes lo suficientemente pequeñas como para no tener esos problemas. Estará allí en las reuniones diarias, puede obtener comentarios de los desarrolladores con frecuencia sobre lo que debe hacer para que sea posible crear "trabajo de codificación", etc. Personalmente, preferiría esta solución si puede hacer que funcione en su organización.

  2. Considere al diseñador de UX/UI como externo al equipo SCRUM. Luego, la salida de ese proceso de diseño es la entrada para la historia de usuario de SCRUM, lo que significa que en el momento en que la historia se lleva a un sprint activo, debe ser tal que los requisitos sean claros: se puede estimar el esfuerzo y hay un buena oportunidad para que se complete al final del sprint.

Claramente, ya estás pensando en términos de "2". Las historias se llevan al estado requerido en las sesiones de refinamiento. Estos pueden desacoplarse fácilmente de los otros artefactos de sprint; por ejemplo, si tiene sprints de 2 o 3 semanas, nada le impide dedicar 2 horas por semana a sesiones de refinamiento planificadas regularmente. En estas sesiones, el diseñador de UX/UI es como cualquier otra parte interesada y puede presentar el estado de su trabajo.

En este punto, es un buen momento para que los desarrolladores hagan preguntas sobre las partes del diseño que realmente tienen una influencia medible en el esfuerzo. Por ejemplo; si se va a diseñar un formulario, probablemente no importará demasiado si hay 5 o 6 atributos para presentar al usuario. Sin embargo , importará si es más un diálogo de estilo "asistente" y la pregunta es si habrá 2 o 10 pasos. Junto con el propietario del producto, los desarrolladores y el diseñador, intente refinar tanto como sea necesario para que los desarrolladores puedan al menos comenzar con las partes funcionales de la implementación. Este también es un buen momento para que los desarrolladores creen un entendimiento por parte del diseñador sobre cuáles de sus elecciones influyen en el esfuerzo o no.

Si la implementación del diseño es más grande y toma más de un sprint, aún así divídalo en partes más pequeñas e impleméntelas por partes, asegurándose de que el diseñador comprenda qué partes son difíciles de cambiar más adelante.

Al final del día, como de costumbre, es decisión del propietario del producto cuándo pedirle al equipo que realmente comience a trabajar en él durante la planificación del sprint; y es responsabilidad del equipo de desarrollo decidir si entienden los requisitos lo suficiente como para hacerlo, y hacer preguntas todo el tiempo que sea necesario.

Consideraría esta (opción 1.) la mejor respuesta. Siempre habrá dependencias. ¿Por qué no incorporar al/a los diseñador(es) en el equipo Scrum y dejar que trabajen por delante? Luego, la entrada para la estimación debería estar lista al comienzo del próximo sprint. O haga una estimación en una reunión a mitad de un sprint y prepare el trabajo pendiente si es necesario.
Yo también, @Bim. He añadido una pequeña frase para que quede más claro.

Podría volverse "totalmente ágil" usando algo llamado "Design Sprint". el caso es que todo el equipo no podrá trabajar en el diseño y el desarrollo al mismo tiempo. El proceso de diseño centrado en el usuario siempre necesita un enfoque anticipado del equipo técnico. Además, el proceso de UX debe considerar la experiencia técnica del equipo, las tecnologías utilizadas y los marcos.

Hay mucha información en la web sobre Design Sprints y Agile/Scrum, pero para resumir, debe manejar los Design Sprints y los Sprints de desarrollo de manera paralela; en mi experiencia, no duran la misma cantidad de tiempo. Por lo general, los Design Sprints son más largos, porque debe considerar la investigación Lean y las pruebas de usuario.

En esta situación, haría que el "diseño de interfaz de usuario" fuera parte del proceso general basado en Sprint.

No estoy seguro de lo que quieres decir con esto. ¿Puede proporcionar más información/aclaración?
¿Cómo incorporar UX/UI en sprint correctamente cuando se requieren maquetas para estimar una historia?
RespuestasAquíPolítica de privacidad1y, 0v