Muchas historias de usuarios comparten las mismas tareas técnicas: ¿qué hacer?

7

Una pequeña introducción a mi caso:

Como parte de un producto más grande, se le pide a mi equipo que realice un IDE pequeño para un DSL. El usuario de este producto podrá realizar llamadas de función en el código y también se nos solicitará que proporcionemos algunas bibliotecas de funciones útiles. El equipo, junto con el PO, puso en la pared un cierto número de historias de usuarios relacionadas con las distintas bibliotecas para el usuario de IDE. Al estimar la primera de esas historias, el equipo decidió que el mecanismo de llamada de función hubiera sido una tarea atractiva pero no completamente obvia, por lo que la estimación de esa historia de usuario se elevó de una simple 3 a una más peligroso 5.

Llegando al problema:

El equipo luego pasó a las historias de usuario con respecto a las otras bibliotecas, en realidad 10 historias, y agregó esos 2 puntos del " mecanismo de llamada de función " a cada una de esas historias de usuario. ¡Esto elevó inmediatamente el total de puntos para el producto de 20 puntos! Todos en el equipo saben que el PO puede recoger cada historia de usuario para la próxima iteración en cualquier momento, por lo que no debemos aislar esa parte en una historia de usuario, ¡pero esos 20 puntos se sienten tan poco realistas!

He propuesto una solución, pero no estoy del todo satisfecho:

Creamos una "historia de diseño" y pusimos esos 2 puntos molestos por encima. Sin embargo, cuando nos dimos cuenta y lo demostramos a nuestros clientes, ¡no pudimos mostrar algo realmente valioso para ellos sobre esa historia!

Aquí el problema es si debemos ignorar el principio de tener historias de usuario aisladas (sin ninguna dependencia entre ellas).

¿Qué harías o, mejor aún, qué has hecho en situaciones como esta?

(una pequeña nota al pie: siguiendo una sugerencia, he movido esta pregunta desde stackoverflow)

    
pregunta Marco Ciambrone 31.01.2011 - 10:55

3 respuestas

5

Si necesita estimar varias historias de usuario que tienen algunos elementos en común, pero aún no sabe en qué orden se implementarán, entonces dividiría las tareas que componen cada historia en tres grupos :

  1. Tareas comunes, necesarias una vez : tareas que se realizan para varias historias, pero que solo tienen que hacerse en realidad una vez para la primera historia. El mencionado mecanismo de llamada de función probablemente entraría en esta categoría.
  2. Tareas comunes y repetidas : tareas que se realizan en varias historias y deben ejecutarse de nuevo para cada historia.
  3. Tareas específicas : tareas que son específicas para una historia en particular.

Luego, calcula cada tarea, donde las tareas comunes deben estimarse solo una vez.

En la presentación al cliente / PO, daría dos estimaciones para cada historia: una con todas las tareas "comunes, necesarias una vez" incluidas y otra con ellas excluidas.
Solo mantenga un registro detallado de las tareas, su clasificación y estimación a la mano si el cliente desea obtener información más detallada sobre la diferencia entre las estimaciones. Las tareas en sí no son negociables, pero conocerlas podría ayudar al cliente / PO, especialmente si el conjunto de tareas comunes no es el mismo para cada historia.

    
respondido por el Bart van Ingen Schenau 31.01.2011 - 12:08
4

Por qué el software es difícil.

  

Creamos una "historia de diseño" y pusimos esos 2 puntos molestos por encima. Sin embargo, cuando nos dimos cuenta y lo demostramos a nuestros clientes, ¡no pudimos mostrar algo realmente valioso para ellos sobre esa historia!

Correcto. La historia de usuario simplista SCRUM es simplista. A veces, el software real es lo suficientemente complejo como para que el enfoque simplista no funcione. Esto no debería ser una sorpresa.

  

Aquí el problema es si debemos ignorar el principio de tener historias de usuario aisladas (sin ninguna dependencia entre ellas).

¿Cuál es tu alternativa? ¿Sobrevalorar cada historia de usuario porque cada una tiene un costo oculto por única vez? Eso es igualmente tonto.

Sí. Tienes que alejarte de lo simplista.

  

¿Qué harías o, mejor aún, qué has hecho en situaciones como esta?

Alejarse de lo simplista. Hay inversiones únicas que hacen que un grupo de historias sea menos costoso. Debes hablar con la gente sobre la arquitectura en lugar de pretender que tu única interacción es una lista de historias que se construirán.

Agile significa que realmente tiene que hablar con el PO y los clientes.

Agile significa que un proceso simplista no puede y no funcionará.

    
respondido por el S.Lott 31.01.2011 - 12:31
1

Usted sabe que solo tiene que hacer el trabajo adicional una vez, por lo que colocar el mismo trabajo adicional en 5 historias no tiene sentido. Si no desea una historia de diseño que el usuario no pueda ver, entonces lo mejor que puede hacer es seguir adelante ahora mismo y elegir una de las cosas que dependen de ese trabajo de diseño y decir que tiene que ser la primera. y añadir esos puntos a ese. Tome notas sobre las otras historias que tienen que venir más tarde, y si, por alguna razón, cambia de opinión, siempre puede mover los puntos.

    
respondido por el Michael Kohne 31.01.2011 - 12:39

Lea otras preguntas en las etiquetas