La mejora de la calidad historia de usuario [cerrada]

https://stackoverflow.com/questions/2202026

18-09-2019
|

Pregunta

Utilizamos Scrum. Estamos experimentando problemas durante sprints cuando nos encontramos con los casos de uso no son suficientemente granular para capturar el esfuerzo necesario para completar el sprint.

En particular, nos encontramos con que se suministran con wireframes de interfaz de usuario que contienen mucha más complejidad que las historias originales habrían implicado (por ejemplo, la funcionalidad duplicada por razones de usabilidad). Esto lleva a la tabla de quemado que parece que todo se ha completado en el día final de la carrera de velocidad.

Pasamos el lunes en el comienzo de cada 2 semanas de sprint repasando las historias creadas por el equipo del proyecto, durante el cual nos normalmente refinar las historias un poco y descomponerlas en tareas, estimar las horas para cada una de crear el gráfico burndown. Durante el día de hoy no se siente como que tenemos tiempo para mejorar de manera significativa la calidad de las historias.

La mejor manera de romper el ciclo de historias incompletas / insuficientes para nuestras carreras?

¿Es esta una falla del equipo de proyecto para clavar las historias suficientemente desde el principio, o deberíamos (es decir, el equipo de desarrollo) tomar parte de la responsabilidad?

Solución

Así que estás diciendo que:

Los clientes / usuarios hablan con equipo de proyecto
Equipo de proyecto escribe historias y crea estructuras alámbricas
equipo de desarrollo se descompone en tareas historias y estimaciones

¿Hay una posibilidad de que el equipo de desarrollo realmente hablando con los clientes / usuarios? historias de usuario son vistos a veces como una manera de comenzar una conversación, en oposición a la exigencia de documentos / especificaciones.

Edit: Algunos enlaces:

EDIT: Martin Fowler hizo una entrada en el blog ayer sobre ConversationalStories que cubre esta mucho mejor que hice.

Otros consejos

¿Está ejecutando retrospectivas de velocidad? Al final de la retrospectiva que debe tener puntos de acción de alta prioridad para mejorar en lo que sucedió en el sprint anterior. Las mismas cosas van mal no debería ser repetidamente .

Es el dueño del producto accesible durante una carrera de velocidad? Si no es posible que tenga que añadir extra a cualquier estimación como el detalle de una historia de usuario es incompleta.

sugerencia @Pascal para dedicar el 5% de su sprint hacia el aseo pila de producto es una buena. Esto debería permitir a las historias de usuario a estar en un lugar más detallada antes del inicio de su carrera de velocidad.

Pasamos el lunes en el inicio de cada 2 semanas durante el sprint de ir historias como creados por el proyecto equipo, tiempo durante el cual normalmente refinar las historias un poco y descanso ellos en tareas, estimar las horas para cada para crear el burndown gráfico. Durante el día de hoy no se siente como tenemos tiempo de manera significativa mejorar la calidad de las historias.

Suena como esto está la sesión de planificación de Sprint, ¿tiene control sobre lo que las historias de usuario que está cometiendo para completar durante el sprint? ¿Cómo se puede cometer si usted no tiene suficiente detalle?

Esto le llevará de nuevo a tener una buena retrospectiva y Solución: las cuestiones planteadas.

La mejor manera de romper el ciclo de / historias incompletas insuficientes para nuestras carreras?

Retrospectivas, la planificación, la cartera de aseo.

¿Es esta una falla del equipo de proyecto para clavar las historias suficientemente desde el principio, o deberíamos (es decir, el equipo de desarrollo) tomar algo de la responsabilidad?

Es la responsabilidad del equipo en su conjunto. Encontrar culpa isnt va a dar valor, pero todos asumir la responsabilidad dará todos la oportunidad de completar el proyecto con éxito.

Tal vez durante esas sesiones de planificación lunes por la mañana se puede involucrar a todo el que está escribiendo el usuario historias / wireframes y trabajar juntos para averiguar lo que los detalles no se encuentra en ellos, lo que haría que detalle sus estimaciones más fácil y precisa. Tal vez una plantilla de lo que deberían incluir podría elaborar.

Hemos tenido (y seguimos en algunos aspectos) este mismo problema. Creo que este problema es una que carece de un análisis inicial y la falta de desarrolladores pasar suficiente tiempo estimar una historia de usuario.

Es posible comenzar con una historia como:

As an administrative user I can create a new widget.

bien, ¿qué significa eso? Después de algunos análisis, que podría significar:

As an administrative user I can create a new widget in created status with complex data validation errors.

Así que después de que una lista de campos, qué tan grande, y cuáles son los campos requeridos son para guardar en la base de datos. Una maqueta básica IU hasta sería bueno también.

Otra historia de usuario para el siguiente sprint podría ser:

As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.

A continuación la lista de las reglas de validación complejas.

Pasamos el lunes en el comienzo de cada 2 semanas de sprint repasando las historias creadas por el equipo del proyecto, durante el cual nos normalmente refinar las historias un poco.

Al inicio del sprint, las historias deben estar listos. Si necesita refinar ellos un poco, creo que (el equipo de desarrollo, el ScrumMaster, el equipo del proyecto) debe hacer que un poco por delante, durante el sprint anterior.

La mejor manera de romper el ciclo de historias incompletas / insuficientes para nuestras carreras?

Está quizá subestimando historias o son demasiado grandes y demasiado vaga. En ambos casos, esto suena como un problema de estimación y una buena manera de mejorar es reducir el tamaño de las historias. Para trabajar en este tema, se podría dedicar un poco de tiempo (por ejemplo, 5% de cada Sprint) Cartera de Producto de la preparación el fin de preparar las historias más importantes y reducir su tamaño al ponerlos sobre la dieta si es necesario antes el siguiente sprint. Y esto va a hacer que la planificación de Sprint cumplir más suave.

¿Es esta una falla del equipo de proyecto para clavar las historias suficientemente desde el principio, o deberíamos (es decir, el equipo de desarrollo) tomar parte de la responsabilidad?

La responsabilidad no es que en mi humilde opinión importante (excepto tal vez por razones políticas, pero que no producen mucho valor de todos modos), tanto el equipo de desarrollo y el equipo del proyecto están trabajando juntos y "no" juntos. Lo que es importante aquí es inspeccionar y adaptar para eliminar el obstáculo. Por lo tanto, es responsabilidad del equipo de desarrollo para hacer de este problema visible (que es un impedimento). Y es la responsabilidad ScrumMaster para trabajar en este impedimento. El fracaso sería no trabajar en él. Preparación de la Pila sesiones son una forma de hacerlo. Y al final, estoy seguro de que el equipo del proyecto va a mejorar y obtener una mejor comprensión de lo que el equipo de desarrollo está a la espera. Y a los dos para producir mejores resultados.

Un montón de buenas ideas aquí ya están en el scrum aspectos de su problema. Basado en su comentario:

particular, nos encontramos con que se suministran con wireframes de interfaz de usuario que contienen mucha más complejidad que las historias originales habrían implicado (por ejemplo, la funcionalidad duplicada por razones de usabilidad).

También tengo una preocupación que puede que tenga que trabajar en ti proceso de desarrollo, así sin embargo. Acceder a la funcionalidad de múltiples ubicaciones en una interfaz de usuario debe ser una adición simple que consume casi nada de tiempo. Si usted está encontrando que trata de un problema común a continuación, su funcionalidad está también estrechamente ligado a elementos de la interfaz en particular. Su equipo puede necesitar para mejorar sus habilidades de diseño (por ejemplo: uso de patrones).

Esto es interesante. Parece que usted está haciendo la planificación de Sprint en el sprint? Y que la Pila del Sprint está comprometida antes de la Planificación del Sprint? Si es así, ¿cómo está el equipo de comprometerse con el sprint backlog sin discutir los detalles de las historias?

Un enfoque alternativo podría ser que el propietario del producto consciente de que ciertas historias no se pueden añadir a la acumulación de velocidad debido a la falta de claridad. En particular, que los criterios de aceptación no se entienden completamente. Esto podría provocar la conversación necesaria con el propietario del producto. Lo ideal es que no debe llegar a esto. Debe ser discutido y resuelto en la retrospectiva.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow