En agile (scrum), ¿cómo hace para desglosar una historia de usuario?

7

En ágil (scrum), ¿cómo debería uno idealmente dividir las cosas en una historia de usuario?

El tamaño del equipo es de aproximadamente 6 desarrolladores si eso marca una diferencia, y las iteraciones son de 3 semanas.

¿Se está rompiendo una historia de usuario con puntos y horas ágiles, o son SOLAMENTE puntos de usuario para una historia de usuario determinada?

¿También deberíamos dividir una historia de usuario en tareas?

En el flujo de trabajo real de una historia de usuario, tiene cosas como:

  1. recopilación de requisitos
  2. revisión de la historia del usuario por parte de los gerentes, etc.
  3. qa tareas relacionadas en el flujo de trabajo del usuario

¿Cómo se manejan estas cosas en un entorno ágil?

    
pregunta codecompleting 14.09.2011 - 16:45

3 respuestas

6

Una historia de usuario se crea normalmente a partir de un requisito dado por el cliente o usuario potencial del sistema. A menudo tiene el formato "Como {rol}, quiero {objetivo} > para que {beneficios}". El conjunto colectivo de historias de usuario captura los requisitos funcionales del sistema que se está construyendo. El cliente o el representante del cliente prioriza cada historia de usuario, generalmente basada en el valor agregado al tener la funcionalidad especificada en la historia.

Una vez escritas, las historias de los usuarios se clasifican y estiman. Hay una serie de técnicas para hacer esto. El método de estimación más común que he visto es la cantidad de esfuerzo necesario para completar la tarea, en valores arbitrarios. Existe una unidad base en la que todos pueden estar de acuerdo y usar esto como un marco común para proporcionar estimaciones sobre el esfuerzo requerido. Los he visto como valores sin unidad llamados "puntos de la historia", pero no veo por qué no puedes estimar la historia del usuario en horas. La clave es ser consistente en todas las historias de usuario.

Para la primera iteración, el equipo calcula la cantidad de puntos de historia que pueden completar en una iteración determinada y ascienden a esa cantidad de puntos en la acumulación para una iteración. Si está calculando en horas, puede determinar cuántas horas dedicará su equipo de desarrollo al proyecto durante la iteración y reducir esas horas de trabajo. Después de la iteración, determina la cantidad de puntos u horas que completó y reduce esa cantidad de trabajo para la siguiente iteración.

Durante todo el proceso, su acumulación general de historias está cambiando. Es posible que se eliminen las funciones, se pueden agregar nuevas funciones o se puede cambiar la prioridad. Sin embargo, nada de esto afecta el trabajo que se bajó para la iteración actual. Solo entre iteraciones debe ajustar lo que está trabajando. Por lo general, tendrá un representante de atención al cliente en el sitio o alguien que pueda actuar como voz del cliente y se pondrá en contacto con las personas adecuadas de la organización del cliente. Continuamente refinan los requisitos y los criterios de aceptación en todo el proyecto.

Depende de usted cómo desglosar las historias de usuario en tareas. Puede ser una preferencia indocumentada del ingeniero, o puede haber un análisis detallado de exactamente lo que implica la historia de cada usuario. Eso es algo que debe especificarse adaptando el proceso para satisfacer las necesidades de su organización, equipo y proyecto.

Debería tener una definición de done , que puede ser se utiliza para determinar cuándo se puede enviar una historia de usuario en particular. Esto define todo, desde el diseño, la implementación, las pruebas, el control de calidad, los criterios de aceptación y la documentación. Puede especificar qué herramientas y métodos utiliza para asegurarse de que se realiza una característica determinada según lo especificado por una historia de usuario. Una vez que la historia del usuario se haya completado e integrado, el producto debería estar en un estado potencialmente enviable, lo que significa que empaquetarlo y entregarlo al cliente agregaría algún valor a sus operaciones o satisfacería algunas de sus necesidades.

En última instancia, necesita adaptar los procesos para que funcionen para su organización, equipo y proyecto. Hacer algo "por el libro" suele ser una receta para los problemas. El hecho de que algo se haya documentado y funcione bien para ciertos equipos que trabajan en ciertos proyectos no significa que se ajuste a todo lo que necesita hacer.

Le puede interesar este artículo de InfoQ sobre la estimación de historias de usuarios , así como Introducción a las historias de usuario de Scott Ambler .

    
respondido por el Thomas Owens 14.09.2011 - 17:11
2

Es ágil, ya que se ajusta al manifiesto ágil .

No es Scrum, ya que Scrum sugiere que debes usar puntos de complejidad para estimar todo.

Pero ninguna de estas cosas es tan importante. De hecho, sostengo que la adherencia estricta a Scrum, a pesar de todas las pruebas de que no debería serlo, no es ágil.

Esta es la pregunta que debería hacerse: ¿es útil para usted?

¿Cómo mejora el proceso de realización del trabajo? ¿Qué ofrece en términos de visibilidad? ¿Cómo ayuda a sus usuarios a obtener el producto que desean? ¿Qué ofrece a la calidad?

Si no puedes responder esas preguntas, entonces no te molestes en hacerlo. Si no está seguro, inténtelo, mida y ajuste según corresponda.

    
respondido por el pdr 14.09.2011 - 17:07
1

Donde trabajo, tenemos un par de condiciones diferentes que harán que una historia se divida en varias historias:

  1. Los puntos de póquer son demasiado altos o la historia parece demasiado vaga como para intentar estimarla. Si la historia tiene más de X puntos, entonces es demasiado grande para tratarla como una historia para completar en un sprint. Esto evita que el equipo se comprometa demasiado, ya que a veces una gran historia puede ser difícil estimar cuántas horas tomará y qué tan rápido puede hacerse. "Como visitante del sitio, quiero comprar productos para poder tenerlos en mi casa", sería el tipo de historia que es demasiado vaga. Amazon.com no se construyó en un sprint de 2 semanas.

  2. No es probable que la historia termine en un sprint y hay una manera fácil de dividir la historia en varias partes. Por ejemplo, una primera parte puede ser investigar y diseñar una solución. Otra parte es implementar esa solución. Cada parte se puede hacer en un sprint, pero no parece probable que ambas se realicen en el mismo sprint.

A veces puede ser al ver la lista de tareas que acompaña a una historia que mostrará que cae en ese segundo caso o que se requerirá tanto control de calidad como se reconstruirá una parte importante de la funcionalidad que la historia debe ser subdividido.

    
respondido por el JB King 14.09.2011 - 18:50

Lea otras preguntas en las etiquetas