Separando el qué del cómo: diseño en un entorno ágil [cerrado]

Question

En un entorno ágil (scrum), ¿cómo se consigue que la gestión de productos cree elementos o historias de trabajo pendientes lo suficientemente pequeños sin que ellos hagan todo el diseño, que no es su especialidad?En otras palabras, ¿cómo se separa el qué (requisitos comerciales) del cómo (diseño) en el desarrollo ágil?

Answer 1

Con scrum, el gestión de productos debe ser una sola persona:el dueño del producto .

Lo que quieres hacer se hace durante el planificación de sprint, donde debe estar presente todo el equipo (propietario del producto, scrummaster, desarrolladores).

El qué debe definirse como historias de usuarios por el dueño del producto .Se supone que las historias de usuario son de alto nivel, lo que limita al propietario del producto a expresar los requisitos comerciales en Las historias de una frase deberían funcionar..

p.ej. Como usuario de StackOverflow, me gustaría ver mi reputación.

Uno de los objetivos de la planificación del sprint es decidir las historias que se deben realizar durante el sprint.Entonces, cuando el propietario del producto elige las historias, el equipo puede subdividirlas y hablar brevemente sobre el diseño (el como) y estimarlos.

En pocas palabras, el qué debe ser realizado por el propietario del producto, el cómo por el equipo.Si este proceso se explica claramente al propietario del producto, no intentará diseñarlo todo.Si lo intenta de todos modos, el scrummaster lo detendrá.

Answer 2

Lo primero que debes hacer, y esa es la causa de una gran cantidad de fracasos en los Proyectos Scrum, es enseñar a tu gerencia de producto a desempeñar el rol de Product Owner.Tienes que demostrarle que él es responsable del ROI del proyecto y, para eso, es responsable de priorizar las historias/elementos/necesidades/características del negocio o lo que sea que estés usando para componer tu cartera de productos de una manera que se aproveche al máximo. Los elementos valiosos tienen mayor prioridad.

Estoy a favor de utilizar historias de usuarios como elementos del backlog del producto y luego, en la planificación del sprint, dividir en tareas más pequeñas las historias seleccionadas para componer el backlog del sprint.

Lo que siempre debe tener en cuenta al escribir, o ayudar a su PO a escribir, sus historias de usuario es que las historias deben INVERTIR. Iindependiente, nortenegociable, Vvalioso para los clientes, miestimable, Scentro comercial y testable.

Creo que al principio utilizar la siguiente plantilla podría resultar útil para mantener la orden de compra centrada en los objetivos comerciales:

"Como - tipo de usuario -, quiero -algún objetivo- para que -algún motivo-".

Un ejemplo de historia sería "Como usuario de stackoverflow, quiero votar una respuesta para que se pueda encontrar fácilmente la respuesta más valiosa".

No olvide hacer que la orden de compra escriba o defina la prueba de aceptación para cada historia de su Sprint Backlog, ya que puede usarse como criterio básico para determinar si una historia está completamente implementada.

Para el ejemplo anterior, dos posibles pruebas de aceptación son:

"Prueba para votar una respuesta"

"Prueba para rechazar una respuesta"

Con esta historia y dos pruebas de aceptación, el equipo sabe que el usuario de stackoverflow puede votar las respuestas y que el estado de la historia se actualice. Listo, es necesario que el sistema permita al usuario votar hacia arriba o hacia abajo por una respuesta sin generar excepciones.

Answer 3

No olvides que los elementos del backlog de producto deben clasificarse en orden de importancia, utilizando un sistema de ponderación (números primos, fibonacci,...), de modo que si tienes elementos en tu backlog de importancia similar (es decir,2 elementos con un peso de 21), entonces, en teoría, ambos deberían intentar insertarse en el sprint por delante de los 13 y 8.

Answer 4

Durante la (re)estimación del trabajo pendiente (después de la priorización), el equipo debe realizar un modelado para comprender el alcance total de la historia del usuario y poder estimar con precisión la complejidad.Este no es el alcance total del modelado que puede tener lugar (los equipos pueden hacer más desarrollo), pero es un excelente lugar para comenzar y podrá aprovechar la presencia del cliente/propietario del producto para responder preguntas allí. y luego.

Como resultado de esto, la discusión resultante lo ayudará a trabajar con el propietario del producto para dividir sus requisitos en una granularidad significativa y adecuada.