Scrum: ¿Está bien que el diseño / UX de la historia del usuario ocurra en el mismo sprint que la implementación?

9

Actualmente estoy en un sprint (dos semanas) donde el diseñador tiene la tarea de definir los requisitos y la experiencia de usuario de una historia de usuario en particular.

En el mismo sprint, debo implementar este diseño. Durante la planificación del sprint, tuve que adivinar cuánto tardaría esta historia de usuario indefinida.

Hoy finalmente recibí el diseño. Desafortunadamente, el diseño es incompleto / vago y se parece más a los requisitos de un cliente que a un diseño. Sin embargo, a partir de esto, todavía puedo ver que no he estimado lo suficiente.

Para empeorar las cosas, esta no es la primera vez. En el último sprint, sucedió exactamente lo mismo. Lo marqué en nuestra retrospectiva y el scrum master no tenía una respuesta sobre cómo resolver esto, en lugar de decir "eso es solo desarrollo para ti". Irónicamente, se molesta si la quema no está en el objetivo ...

Ahora voy a tener que pedir / trabajar con el diseñador para hacer su trabajo. Esto me va a detener, ya que he completado todas mis otras tareas.

Entonces mi pregunta es

A) ~~¿cómo manejas las dependencias en la planificación de sprint?~~ EDITAR: ¿Está bien que el diseño / UX de la historia del usuario ocurra en el mismo sprint que la implementación?

B) ¿cómo debo acercarme ahora al sprint? ¿Volver a estimar la historia actual del usuario y ver cómo se quema el burndown y ser visto como incompetente / improductivo? O agregue una nueva tarea al sprint actual siguiendo las líneas de "ayudar al diseñador a crear un diseño adecuado"

agile scrum planning

— Alano
fuente

Vale la pena mencionar que su pregunta en la línea de asunto es muy diferente de las preguntas al final de su texto. Sería útil si editaras eso para elegir uno u otro.

— pdr

14

¿Cómo manejas las dependencias en la planificación de sprint?

Idealmente, las dependencias que no son de desarrollo se manejan antes de la planificación del sprint, de modo que tenga una buena definición del elemento de la cartera de pedidos para contrastar el esfuerzo.

Pero, si eso fue "solo desarrollo para ti" el último sprint, entonces probablemente sería solo desarrollo para ti este sprint, por lo que realmente deberías haber aumentado tu estimación allí y luego en las próximas tareas que están en un estado similar. Esto no es ser vengativo, y sería un error dejar que se presente como tal.

Lo que hace es mostrar la incertidumbre de la estimación sin un diseño relativamente sólido para estimar. Tal vez, esto alentará a sus gerentes a asegurarse de que un elemento de la cartera de pedidos del producto esté correctamente definido; pero en el peor de los casos te cubrirá la espalda. Nadie se queja cuando un trabajo llega por debajo del presupuesto.

Sin embargo, no hiciste eso, y ahora tu pregunta es ...

¿Cómo debo acercarme ahora al sprint?

El propósito completo de Scrum como herramienta de gestión de proyectos es identificar problemas temprano, lo cual ha hecho. Señale a su administración, déjelos decidir qué hacer con el sprint. Si intentan culparte, sé humilde y pregunta cómo te sugieren que abordes situaciones similares en el futuro, para evitar el mismo problema, incluso si realmente no crees que sea justo.

Al final del día, estos son problemas de gestión de proyectos, y si intenta resolverlos dentro de su propia burbuja, se está preparando para fallar. Y, cuando lo haga, se enojará porque caerá sobre usted, no sobre los gerentes que no lograron resolver el problema cuando se lo señaló.

— pdr
fuente

Gracias por la respuesta. Para ampliar, mi scrum master quiere que seamos realmente ágiles para que podamos cambiar / iterar en una historia de usuario tan pronto como se haya codificado. Por lo tanto, no le gusta demasiada documentación / diseño inicial y en su lugar debemos codificar / planificar a medida que avanzamos. Por supuesto, esto me lleva a la situación en la que me he encontrado. Sin embargo, el manifiesto ágil parece apoyar su postura. Entonces, ¿estamos siendo demasiado ágiles para nuestro propio bien?

— Allan

Como ejemplo, una de nuestras historias de usuario podría ser "El usuario quiere poder jugar contra otro jugador humano". En nuestra planificación de sprint, probablemente dividiría esto en algunas tareas, tales como: mostrar servidores, elegir el servidor al que conectarse, conectar al servidor. Entonces, el diseñador idealmente me diría cómo se muestran los servidores, qué filtros de lista están disponibles, qué sucede si no hay servidores, etc. Por supuesto, esta lista de cosas solo está disponible para mí una vez que la ha diseñado y en este caso está ocurriendo. en el mismo sprint Esta lista también está sujeta a cambios / iteraciones durante el sprint.

— Allan

1

@Allan: Lo que su scrum master no comprende es que, si el diseñador tiene que completar su trabajo antes de que un desarrollador pueda comenzar su trabajo, ES un diseño inicial. Hacer que suceda dentro del sprint no elimina ninguno de los costos del diseño inicial, pero lo hace menos visible Y hace que sea más difícil estimar su desarrollo. Si puede encontrar una manera de interactuar con su diseñador, eso es genial, hágalo parte del sprint y haga el esfuerzo apropiado para una tarea de colaboración. Pero desde el principio está bien, siempre y cuando sea honesto y, preferiblemente, antes del sprint.

— pdr

Si eso es típico de sus historias de usuario, diría que sus historias son demasiado grandes. Dado su ejemplo, esperaría ver "el usuario puede ver la lista de servidores", "el usuario puede conectarse al servidor y ver la lista de oponentes disponibles" como historias.

— Jules

6

En primer lugar, existe una gran diferencia entre las dependencias entre historias / tareas y la incertidumbre en el alcance / esfuerzo de una historia / tarea.

Las dependencias se manejan dando a la tarea / historia dependiente una prioridad menor que la tarea / historia de la que depende y posiblemente una anotación de que no puede comenzar antes de que se complete la otra tarea / historia.

La incertidumbre debe abordarse en la reunión de planificación aclarando el trabajo que debe hacerse en la historia. Si no es posible eliminar suficiente incertidumbre, lo más probable es que la historia no cumpla con su "Definición de Listo" y no deba aceptarse en el sprint.
Si, por alguna razón, la historia realmente necesita entrar en el sprint, su única opción es agregar un amortiguador de riesgo a la estimación.

Para el sprint actual, si no puede trabajar en una historia, solo informe eso en la próxima reunión diaria y realice el trabajo que sea posible para alcanzar la meta general del equipo. También puede anotar la historia como bloqueada y por qué.
Después de que un sprint ha comenzado, en principio es imposible agregar nuevas tareas al sprint.
Además, si una tarea resulta ser más trabajo de lo estimado, entonces no cambia la estimación, pero sí informa fielmente cuál es el progreso y el esfuerzo restante en la tarea.

Al final, en Scrum, es el equipo el que promete entregar algo. Si esa promesa no se puede hacer, entonces es un fracaso de todo el equipo, nunca de un individuo dentro del equipo.

— Bart van Ingen Schenau
fuente

Esta fue una buena respuesta también. Si pudiera marcar dos respuestas como correctas lo habría hecho.

— Allan

3

Durante la planificación del sprint, tuve que adivinar cuánto tardaría esta historia de usuario indefinida.

Ese es el error que cometiste. Nadie puede obligar al equipo a aceptar una tarea en el sprint y es su trabajo afirmar que la tarea no puede estimarse ni aceptarse en el sprint a menos que haya al menos una estructura alámbrica (por ejemplo). Parece que tu scrum master es en realidad un gerente de proyecto, lo que solo empeora las cosas.

¿Cómo abordar dicha tarea si es necesario lograrla dentro del sprint (por razones comerciales válidas)? Bueno, primero debe establecer una fecha límite para el diseño, después de lo cual no podrá implementarlo. Por ejemplo: la historia es aceptada, pero el diseño debe entregarse dentro de la primera semana e implementarse dentro de la segunda. Luego, debe trabajar muy de cerca con el diseñador para asegurarse de que se pueda implementar en el sprint. Scrum asume un equipo multifuncional y depende de usted organizar su trabajo con el diseñador. Dicho esto, si acepta la tarea en el sprint, que depende del equipo decidir, depende del equipo gestionar el trabajo de una manera que se complete dentro del sprint y gestionar los riesgos asociados. No debe esperar a que otro termine su trabajo para hacer su trabajo. Es posible que esté a punto de revelar una disfunción mayor en su organización.

— Maxim Krizhanovsky
fuente

Gracias Darhazer Sí, el scrum master también es el gerente del proyecto. El scrum master ha declarado que debe haber una planificación y documentación mínimas. En su lugar, debemos construir características a medida que avanzamos, con revisiones continuas durante el sprint para iterar / cambiar lo que fue construido según lo determinado por el administrador del proyecto (de ahí que el diseño y la implementación ocurran en el mismo sprint). Habiendo venido de un rol en el que el diseño era bastante sólido desde el principio, me estoy adaptando difícilmente a esta cultura de código por cable.

— Allan

3

"... scrum master también es el gerente del proyecto". - no está bien. "... planificación y documentación mínimas ..." - ¿Qué ES exactamente en sus Definiciones de Listo y / o Listo? "... revisa durante el sprint para iterar / cambiar lo que se construyó según lo determinado por el gerente del proyecto ..." - esa debería ser la decisión del Equipo, no el scrum master, ciertamente no el gerente del proyecto y (si DEBE ser alguien ) debería ser el dueño del producto!

— Phill W.

@PhillW. No tenemos una definición de listo. Solo tenemos una cartera de pedidos con diferentes estados de detalle para una función. El detalle se desarrolla a medida que avanzamos. Hecho es oficialmente cuando las partes interesadas firman, pero en realidad eso es por hitos y es el gerente / scrum master / productor (la misma persona) quien dice cuándo se hace. He estado haciendo "scrum" durante un año, no mucho después de comenzar hice un poco de autoaprendizaje sobre scrum ya que sentí que nuestra forma de hacerlo era extraña. Cuanto más leía, más sentía que estábamos haciendo scrum "Cargo cult". Pero la política me dificulta hacer algo al respecto ...

— Allan

1

¿Las tareas sobre diseño se expresan como historias y cuáles son las definiciones de su equipo de

una historia esta lista
se hace una historia

Cada historia debe tener sus propios requisitos y condiciones de aceptación, pero creo que es una buena práctica tener un conjunto de reglas que sean aplicables a todas las historias. Por ejemplo, una historia está lista si (¡y solo si!): Los estudios de arquitectura de extremo a extremo están terminados, el diseño está disponible, la historia ha sido estimada por el equipo. Las condiciones mínimas de aceptación podrían ser: la prueba automatizada se realiza, está bien y se ha integrado al traje de pruebas, se realiza la revisión del código.

Si una historia no está lista, no la inserte en su sprint. Si no se cumplen las condiciones de aceptación, entonces no está terminado.

En su caso, el equipo podría decidir que para estar listo, una historia de desarrollo debe tener un diseño completo (al menos una estructura metálica, ajustar esto a su propia realidad). Si es así, no puedes manejar el diseño y el desarrollo en el mismo sprint. El equipo también podría decidir que una historia de UX / diseño debería producir al menos un diseño de estructura alámbrica. Si no es el caso, entonces la historia no se acepta y, por lo tanto, las historias que dependen de ella no pueden comenzar.

Debería convencer fácilmente a sus gerentes de que tener reglas firmes es bueno: reevaluar la complejidad durante el sprint es una mala práctica. Significa que la velocidad del equipo es incierta y que ellos, como gerentes, tienen una mala visión del trabajo del equipo y del futuro.

— Keufran
fuente

0

Un Sprint generalmente comienza cuando la historia es clara: en esta etapa, se establece y prioriza la cartera de productos. Si comenzó sin tener el diseño, entonces debería haber quedado claro qué se puede hacer sin el diseño y qué no ...

Si tiene que improvisar mientras el diseño está 'chocando' entre el cliente y la OP, entonces su OP debe informar al equipo sobre las nuevas características tan pronto como aparezcan: este es el significado de 'flexibilidad' en Scrum: adaptarse a la actual situación. El equipo de desarrollo, el Scrum Master y el propietario del producto deben comunicarse de forma permanente, de lo contrario no hay una reacción en tiempo real al cambio.

Un poco más de entrenamiento no puede dañar ... ¿Quizás trabajar con el diseñador sería una oportunidad para que adquieras nuevas habilidades de UX? ... eso es observar que el vaso está medio lleno en lugar de medio vacío :))

— ScrumMasterChangeFacilitator
fuente