Recopilación de requisitos con Scrum

Question

Mi equipo de desarrollo está trabajando para el método de Scrum, prácticamente. Tenemos una cartera de pedidos de productos priorizados, que dividimos en sprints seguidos por un gráfico de burndown.

Problema es que los gerentes de producto (que reúnen los requisitos de las partes interesadas) nos darán un resumen de los requisitos, por ejemplo, unos días antes del comienzo de un sprint o conjunto de sprints.

A continuación, echemos un vistazo a ellos, revise con lo que es factible (técnicamente y en un tiempo razonable). Esto es enviado a revisión por la gerencia, otras administraciones de productos y partes interesadas, y por lo general revisado/ajustado aún más, que tiende a seguir en un círculo hasta que todo se haya establecido.

Mientras tanto, la fecha de inicio del sprint está sobre nosotros y comenzamos a aprovechar los requisitos que estamos seguros que son estables. Una vez que terminan, nos quedan días interminables de ajustar el código a medida que los requisitos cambian ligeramente.

Si bien soy consciente de que los requisitos no deben considerarse fijos, siento que estamos manejando esto mal, y tratando de adaptar un enfoque de requisitos de cascada al desarrollo ágil.

¿Alguien tiene alguna sugerencia de mejora o experiencia en este tipo de problema?

Editar: Este es probablemente el peor escenario para nosotros, ¡a veces los requisitos son bastante estables y realmente usamos Scrum correctamente! Sin embargo, con mayor frecuencia estamos viendo el escenario anterior en nuestros sprints, por lo que he hecho la pregunta. Sé que lo anterior no es realmente correcto Scrum, ese es el tipo de problema :)

Answer 1

Traiga a sus partes interesadas a los scrums; invocarlos elimirá cualquier "susurro chino" a través de los gerentes de producto. Además, son ellos los que deben priorizar el registro de respaldo, no los desarrolladores. Cuando las partes interesadas están en los scrums, también ven mejor las ramificaciones del cambio y, aunque no dejarán de hacer cambios, tendrán un mejor concepto de cómo los cambios afectan la iteración.

En cambiantes requisitos; ver el Manifiesto ágil ... "¡Abrazar el cambio!"

Bondad,

Dan

Answer 2

Sí. Y esto es importante: No acepte cambios en las historias después de que comience un sprint.

Esto requerirá mucho esfuerzo en nombre de los scrum masters para decirles a los propietarios del producto que esto no está permitido. Lo importante para ellos es enfatizar que los desarrolladores se comprometen a estimar y entregar las historias como se especifica, y cualquier cambio niega ese esfuerzo.

En algunos casos, los requisitos cambian legítimamente después de que comienza un sprint. Aquí, considere abortar el sprint por completo. (Eso debería llamar su atención.)

Si el propietario de su producto considera que esto es demasiado inflexible, considere reducir la longitud del resorte. He trabajado en una tienda que usó un sprint de una semana, que creo que es el mínimo, ya que las historias terminaron siendo muy pequeñas.

Para más información, vea Agile Project Management con Scrum de Ken Schwaber.

Answer 3

Tenemos a alguien en el equipo que está a cargo de corregir los requisitos en nombre del propietario del producto. A veces tenemos requisitos just-in-time, a veces, tenemos que volver a trabajar. QA acepta que los requisitos se revisen formalmente en los últimos sprints del lanzamiento.

El equipo solo debe comprometerse para tareas claramente definidas por el propietario del producto, de lo contrario no pueden ser estimadas. ¿Quizás podría acortar su iteración para que solo se puedan planificar requisitos estables?

Si su proceso exige este ciclo de revisión, entonces quizás pueda restringir sus elementos de Sprint a aquellos aprobados por el gerente de producto/administración/parte interesada.

Answer 4

Parece que en realidad nadie es el propietario del Producto acumulado (es decir, no tiene un Propietario de Producto único) y parece que los Elementos más importantes del Producto Pendiente no están listos antes de cada iteración. Estos son obvios impedimentos importantes, deben ser resueltos, su ScrumMaster debería funcionar en ellos.

Answer 5

"Mientras tanto, la fecha de inicio del sprint está sobre nosotros y comenzamos a agarrarnos a los requisitos que estamos bastante seguros que son estables. Una vez que los hemos terminado nos quedamos con días interminables de ajustar el código ya que los requisitos cambian ligeramente".

No llame a eso un método ágil o scrum.

Eso es una locura.

Si está retocando las cosas después de que comienza el sprint, no lo está haciendo bien.

Está habilitando (de hecho, su alentador) mal comportamiento. Si no pueden obtener los requisitos antes de comienza el sprint, tiene dos opciones.

1. Wait. No hay nada malo con esto Es más barato a largo plazo.

2. Inicio. Sin embargo. Como los requisitos se fijan para la duración del sprint, debes terminar el sprint sin "ajustes". Los cambios se vuelven parte de la acumulación.

   • Puede hacer sprints más cortos.

   • Simplemente puede acumular los ajustes hasta que tengan la idea de que están causando sus propios problemas.

Además, una gran cantidad de revisión por la dirección no es muy ágil. No es per se incorrecto. Pero indica una falta de confianza. Agile significa colaboración e interacción entre desarrolladores y propietarios de productos. No significa otra capa de revisión de gestión.

Answer 6

Estoy de acuerdo con los demás; su Product Owner es inexistente. Realmente no puedes comenzar un sprint hasta que tengas suficientes requisitos sólidos para comprometerte, y tu Product Owner está de acuerdo con ese compromiso. Una vez que se realiza el compromiso, ninguna de las partes puede cambiarlo en el contexto de Scrum a menos que abandone el sprint y vuelva a planificar. Por supuesto, no estás haciendo esto.

Además, afirmaría que su Scrum Master no está cumpliendo con sus responsabilidades como Guardián del proceso. ¿Por qué le permite iniciar un sprint cuando no tiene una cartera de pedidos de productos válida para elegir sus artículos de sprint acumulado? ¿Incluso tienes un Scrum Master?

Entiendo que su equipo solo está tratando de hacer el trabajo, pero lo que realmente está sucediendo es que está generando un mal comportamiento por parte de los gerentes de producto, que no necesitan tener un retraso en el trabajo. historias de usuario definidas listas antes del comienzo del sprint.

Existe una razón por la cual Scrum tiene un Scrum Master y un Propietario de Producto, y requiere un acuerdo entre el Propietario del Producto y el equipo en la acumulación de Sprint antes de que comience el sprint. No tener estos roles asignados y no seguir el proceso de Scrum hace que las cosas se rompan. Sí, es más fácil evitar las partes de Scrum que señalan el mal comportamiento, pero no cambiarás el mal comportamiento hasta que se reconozca. Recuerde, la definición de locura está haciendo lo mismo una y otra vez mientras espera resultados diferentes. Tendrá que cambiar lo que hace si quiere cambiar los resultados.