¿Cómo se maneja el trabajo duplicado en las historias?

La idea de dividir el trabajo en historias de negocios es reducir las dependencias entre las tareas. Pero, ¿cómo manejas historias donde una obra compartida es común en ellas?¿Cómo se maneja el trabajo duplicado en las historias?

Por ejemplo, si tiene dos historias, ambas muestran información recuperada de un único servicio web, pero en dos páginas diferentes, ¿cómo maneja la tarea común de crear el código para llamar al servicio web?

¿Los combinas en una sola historia? ¿Creas una tercera "historia" con solo la tarea técnica para crear el código de servicio web común? ¿Conservas el original y dejas que los dos desarrolladores que eligen la historia lo discutan entre ellos?

¿Cuál es el enfoque más ágil?

Fuente

2011-05-06 Ricardo Gladwell

Depende de la cantidad de trabajo para llamar al servicio web. Si se trata de un pequeño porcentaje del tamaño total de la historia, en realidad no importa; si se realizan en la misma iteración, simplemente deja que los desarrolladores hablen de ello durante la presentación para ver quién lo hará.

Si, en cambio, llamar al servicio web es más trabajo, quizás incluya ESCRIBIR el servicio web, entonces debería ver si puede dividir ese trabajo en una tercera historia. Tal vez esta tercera historia contenga todo el trabajo para llamar/escribir el servicio web, y luego solo trabajo suficiente en la interfaz para demostrar que funciona para el negocio. Luego, en la siguiente iteración, puede abordar las dos historias (originales) restantes. El beneficio es que demuestras valor al negocio y al mismo tiempo no te empantanas con los detalles de la interfaz.

Fuente

2011-05-06 14:00:04

Gracias por la respuesta, creo que el consenso es que las historias que dependen de otras historias están bien, siempre que se separen en sprints/iteraciones separadas. –

Sí, ese tipo de cosas sucede todo el tiempo. Casi siempre se basa en el trabajo realizado en iteraciones anteriores. Si tienes dos historias que dependen unas de otras en la misma iteración, también está bien, porque los miembros del equipo hablan al menos una vez al día en el standup/Scrum diario. Pero si uno depende completamente de otro y no puede trabajar en uno hasta que el otro termine, entonces debe ponerlos en iteraciones separadas. –

Gracias por la información, ¿tiene alguna referencia para este enfoque para duplicar el trabajo en las historias? –

Crear una tarea adicional para hacer las cosas comunes es el camino a seguir.

Fuente

2011-05-06 09:44:06

¿Pero no es estrictamente no ágil? Las tareas puramente técnicas no pueden ser revisadas por el negocio, tienen altas dependencias en otras historias/tareas, no pueden ser controladas por QA y significa que el trabajo no se puede completar en paralelo, entre otros problemas. Es como volver al modelo descendente de cascadas de hacer cosas. –

Debe completar este código común de antemano. Idealmente, en el sprint anterior, mientras que los otros recursos están trabajando en otra cosa, y en el sprint actual, pueden volver a trabajar en las piezas independientes. Su plan para completar piezas dependientes antes, seguir ágil no significa que eliminará mágicamente las dependencias, es solo una forma de manejarlas. –

@Ricardo Gladwell: no hay "estrictamente" en Agile. El objetivo es reflejar las cosas que experimentan los usuarios y no obsesionarse con las tareas y los horarios. Ser "flexible" y construir cosas que son "útiles" es en lo que debes enfocarte. La idea de "estricto" te hace menos ágil. Por lo tanto, sea menos estricto y cree cosas más útiles que los usuarios realmente necesitan. –

En nuestro entorno, creamos tres historias en su caso, una para llamar al servicio web y las otras dos como dependencia (la herramienta que utilizamos permite crear "avisos de bloqueador" vinculando tareas con dependencias) El resultado es el mismo que si hubiera una historia que incluyera el servicio web y una sin ella, excepto en este caso, puede priorizar los dos usos de ese servicio web y cuando una historia que lo requiera se debe, necesariamente, a la historia de implementar el servicio web tendría que ser retirado primero.

Fuente

2011-05-16 13:59:41 Paul

Gracias por los comentarios, pero me gustaría evitar historias técnicas como "llamar al servicio web" si es posible. –

Eso es justo. Entonces, si sabes qué historia es una prioridad más alta, vincularé la tarea técnica a esa historia y seguiré usando las dependencias para asegurarme de que se haga primero. Aquí hay un ejemplo de cómo podría funcionar: http://imageshack.us/photo/my-images/542/screenshot20110517at110.png/ – Paul

Esa es la trampa 22: también me gustaría que los desarrolladores puedan trabajar en cualquier historia en una primavera/iteración en paralelo. Creo que el consenso es separar historias dependientes en diferentes sprints/iteraciones. –

¿Cómo se maneja el trabajo duplicado en las historias?

Respuesta

Cuestiones relacionadas