¿Cuándo dejar de escribir historias de usuarios y comenzar a codificar?

Al descubrir historias para el primer sprint, ¿cómo sabes cuándo dejar de escribir y seguir adelante?

Le pregunté a algunas personas que conozco y, básicamente, la respuesta que obtuve es que depende del contexto en el que exista el proyecto y de la duración del proyecto en general.

¿Hay alguna forma estándar de saber cuándo dejar de escribir historias de usuarios y, de ser así, cuál es la base de esto y cómo se aplica a los sprints futuros?

Debe estimar cada historia una vez que la ha desarrollado; esto supone que obtiene sus historias en orden de prioridad y que están lo suficientemente elaboradas para el desarrollo.

Cuando haya estimado lo suficiente para una iteración, comience a codificar.

Cuando tiene una cartera de productos completa y buenas historias de usuario completas de todos los casos. Luego divídalos en iteraciones y comience a programar.

Las dos actividades no son antagónicas.

La redacción de historias trata sobre la definición de las necesidades deseadas bajo la restricción de proporcionar valor comercial.

Comenzar a codificar ocurre en medio de un sprint. Para comenzar un sprint, el único requisito previo es una acumulación de sprint definida, priorizada por el PO (el escritor de la historia) y seleccionada por el equipo.

Debe dejar de escribir historias (= detener el proyecto), cuando el beneficio marginal de implementar la historia versus el costo de implementación y el costo operativo actualizado de la función definida es negativa.

Debe comenzar a codificar en el contexto de un sprint, cuando se comprende la historia (análisis) y se definen las pruebas y la implementación (diseño), el enfoque clásico de desarrollo de software.

cuando las historias se vuelven lo suficientemente granulares como para convertirse en lógica programable ... y cuando los programadores pueden otorgar una cierta cantidad de puntos de historia que se ajustan a la línea de tiempo de los sprints ...

una historia que se estima en 50 horas / puntos de historia sería difícil (IMO) de asumir en una carrera de más de una semana ... desglosar la historia aún más permitiría que otros asuman varias partes de la tarea, pero si el código no puede se desarrolle en paralelo, entonces probablemente sea lo más corto posible.

¿Hay alguna forma estándar de saber cuándo dejar de escribir historias de usuarios y, de ser así, cuál es la base de esto y cómo se aplica a los sprints futuros?

No conozco personalmente un método estándar per se. Realmente se reduce a una combinación de su metodología y las expectativas de sus clientes.

He descubierto que es mejor comenzar a codificar tan pronto como tenga "suficientes" historias de su cliente para comenzar. Como han dicho otros, esto podría ser para una sola iteración, sin embargo, podría ser para más. Su medida suficiente debe guiarse por la frecuencia con la que tiene la intención de liberar el código de trabajo a su cliente, y en lugar de que su cliente le brinde una lista interminable de historias (muchas de las cuales probablemente nunca se realizarán, o podrían cambiar o no) haga su fecha límite de lanzamiento principal), es mejor pedirle a su cliente las primeras 3-5 funciones más importantes y de mayor prioridad. Cuando los haya completado y entregado a su cliente, usted recopilará las siguientes características 3-5 más importantes, etc. Pida más o menos dependiendo de la duración de sus iteraciones.

Su cliente o contrato o fecha límite tal vez lo guíen en cuanto a cuándo dejar de pedir historias, pero mientras tanto, ha estado pidiendo historias y deteniéndose tan a menudo como ha tenido iteraciones. Cuando, de común acuerdo, usted y el cliente sientan que el producto es lo suficientemente completo, puede decidir qué hacer con las historias sobrantes que el cliente aún no le haya dado.

La principal ventaja de este enfoque es que terminas entregando el mayor valor al cliente por adelantado, y a medida que el proyecto crece y pasa el tiempo, la cantidad de valor que estás entregando al cliente disminuye hasta el punto en que el cliente puede hacer un decisión sobre el "último 20% de las características" que podrían haber deseado y que en realidad nunca se utilizarían. También reduce el tiempo perdido en elementos triviales y de baja prioridad, poniendo la responsabilidad (y el estrés) de priorizar y programar las iteraciones de nuevo en el cliente, y todo basado únicamente en las necesidades del cliente. Sin embargo, eso no significa que no deba brindar orientación al cliente para evitar cuellos de botella de programación difíciles que pueden ser evidentes a medida que habla de los requisitos con el cliente.

Lea el Desarrollo de software Lean de Poppendeicks si desea una descripción más detallada de este enfoque en un contexto más amplio.

nunca dejas de escribir historias ... Es solo que cuando tienes suficientes historias para el sprint 1, harás la planificación del sprint y tu equipo comenzará a trabajar de acuerdo con el backlog del sprint ...

El propietario del producto continuará preparando la cartera de pedidos del producto, es decir, escribiendo más historias de usuarios, dividiendo historias grandes, es decir, épicas, en una más pequeña, elaborando más sobre los criterios de aceptación de historias, priorizando ...