¿Cuál es un buen proceso para escribir tarjetas de historia?

Question

Estamos definiendo nuestras tarjetas de historia para el próximo proyecto.

• tenemos una buena idea de lo que quiere el cliente a través de talleres
• Tenemos un documento requisito de negocio que será firmada por ellos.

Nuestros proces de storys que definen es el siguiente

1. Tomamos una característica que el cliente quiere y escribimos una historia
2. Tenemos una breve discusión diseño amognst el equipo
3. A continuación, determinar una estimación para la tarjeta
4. Si la tarjeta es más de 3 días la descomponemos aún más y volvemos a repetir desde el paso 2

Desafortunadamente, el cliente quiere una estimación de cuánto tiempo le llevará a todo el proyecto, por lo que debemos definir todas las historias por adelantado.

Esto toma un tiempo y puede ser muy agotador

¿Qué otros métodos se pueden utilizar para definir las tarjetas de historia? Esto puede tomar otras formas de reunir requisitos en tarjetas de historias.

EDIT:

1. Esta no es la primera vez que hemos hecho esto es, el proceso normal
2. El cliente es un cliente interno
3. estoy interesado en la forma de escribir las cartas que termina codificando contra

Answer 1

Sugeriría algo que llamamos un "juego de planificación de lanzamiento". Es muy similar a lo que haces para una iteración, sin embargo, lo hicimos en un nivel superior. Es decir, tomaríamos el conjunto de características o puntos de función que el usuario quería para un lanzamiento en particular, y estimaríamos que íbamos a estar manera desactivados. A continuación, puede agregar todas esas estimaciones para tener una idea aproximada de cuándo cree que, en función de su información actual, puede entregar su producto.

Esto debería darles a sus clientes una idea de cuándo va a lanzar, pero aún debe insistir en que necesita un poco más de margen de maniobra porque, al igual que sus clientes, no puede predecir el futuro (o al menos yo puedo 't).

Answer 2

¿Cómo planea liberar la aplicación al cliente? ¿Estás haciendo entregas incrementales? ¿O está planeando un entregable inicial?

Te sugiero dividir el desarrollo en sprints de dos o tres semanas y luego agregar una semana adicional para cada sprint en el presupuesto de entrega para comprarte algo de tiempo extra ... solo en caso de que el cliente cambie de opinión sobre una característica (ellos van a). Con suerte, esto hará que la estimación de la fecha de entrega final sea más fácil ...

Si puede convencer a su cliente de que debe realizar entregas incrementales, encontrará que creará menos historias redundantes a medida que cambie la especificación. Además, no tendrá que hacer tanto trabajo inicial, y a medida que avance el desarrollo puede escribir el siguiente lote de historias mientras el desarrollo está en marcha.

Espero que esto ayude.

Answer 3

Normalmente, solo pido por adelantado los títulos de las historias. Intento ver si puedo clasificarlos por lo menos dentro de un orden de magnitud. Doy una estimación muy aproximada basada en el número de títulos y mi velocidad/título estimado. Usualmente haré que el cliente rompa los títulos en (1) necesidad de tener ahora, (2) necesarios pero puede esperar, y (3) estos serían buenos.

Empiezo abordando el grupo (1) y obtengo suficiente información para dividirlos en un conjunto de versiones. En este punto, por lo general, puedo proporcionar una mejor estimación utilizando la información más detallada para proporcionar estimaciones de título. Solo planifico las historias del grupo (1). Si hay demasiadas historias grupales (1) para encajar en un lanzamiento, las dividimos en versiones/iteraciones múltiples y coherentes.

Cuando tenemos aproximadamente un mes comenzando con las historias del grupo (2), me vuelvo a sentar con el cliente (en una sesión de planificación más enfocada, usu hablando con ellos todo el tiempo), para comenzar el proceso de nuevo con el grupo (2) historias.

Historias que se agregan a medida que el proyecto avanza, se coloca en el grupo correcto y se maneja según corresponda para ese grupo; si es actual, suficientes detalles para trabajar, si fuera posterior, solo el título como marcador de posición.

Lo otro que hago es asegurarme de que el cliente comprenda que se trata de un proceso cooperativo y terminaremos con lo que ellos quieren. Ellos pueden elegir cuándo detenerse, incluso si quedan historias en el tablero. Mientras entregue valor que les importe, seguiremos desarrollando. Necesitan confiar en que estoy haciendo lo correcto para ellos y trabajando diligentemente. Necesito confiar en que me darán la mejor información posible sobre lo que quieran tan pronto como sea posible.

Answer 4

No puede saber cuándo se hará todo y seguir un proceso ágil. Incluso si trabajas muy duro para estimar todo, cuanto mayor sea el trabajo, mayor será tu porcentaje de error. La mayoría de las estimaciones para proyectos de tamaño mediano terminan siendo 2 veces menos, y las más grandes hasta 10 veces.

En cambio, le pediría al cliente una fecha de objetivo funcional. La conversación es la siguiente:

Usted: ¿Cuándo necesita estas funciones?

(C) ustomer: ¿Cuándo puede entregarlos?

Usted: Vamos a enmarcar los límites primero. Si entregué todas estas características en 10 años, ¿sería demasiado tarde?

C: Por supuesto.

Usted: Si entregué todas estas características mañana, ¿eso sería lo suficientemente pronto?

C: Por supuesto.

Usted: ¿Qué tal dentro de 1 año?

C: Eso todavía es demasiado tarde.

Usted: 3 meses?

C: Eso es un poco tarde, más como 2 meses. Tenemos que estar listos para usar esto con nuestro equipo de gestión en enero.

Usted (piensa): ¡Ah, ja!

Usted: No podemos entregar todas estas características en 2 meses. Creo que podríamos entregar estas 4 historias en 1 mes, y estas 3 tiendas en el próximo mes.

C: Realmente necesitaremos la función X para enero.

Usted: De acuerdo, si agregamos la característica X, tendremos que eliminar una función. ¿Qué no necesitas?

C: Podemos ver con sólo una parte de la función Y.

Usted: OK. Tomaremos esta lista y elaboraremos un presupuesto más detallado.

C (pensar): ¡Ja! ¡Obtuve lo que quería!

He encontrado una y otra vez que el motivo subyacente de las estimaciones y la planificación de "todo" es que quieren una promesa de entrega de algo por una fecha. Trabajando a través de la fecha límite funciona mucho mejor porque:

1. Fuerzas del cliente para ayudar a que las compensaciones

2. expone la verdadera razón de estimaciones

3. reduce el número de cosas que estimar.

4. Ayuda a identificar qué funciones son importantes para el sprint.

Answer 5

Si estás tratando de ser fiel a XP entonces sugeriría que vaya here y leer sobre la diferencia entre la liberación y Planificación iteración. No debe hacer una estimación de tarea individual hasta que esté listo para comenzar a codificar.

Stories! = Tareas. Las historias se dividen en tareas, para lo cual se hace la estimación de 3 días de <. La estimación de las historias es más abierta y usted debería poder decidir los umbrales para las estimaciones de la historia que funcionen mejor para usted y su equipo después de haberlo hecho por un tiempo. (IE < 1 semana, 2 semanas,> 2 semanas, etc.)

La parte más importante de la estimación es realizar un seguimiento con el tiempo real empleado y realizar ajustes en el proceso de estimación. XP tiene que ver con la retroalimentación.

Answer 6

No rompería historias tan pequeñas para la planificación de versiones (que parece ser lo que quieres hacer). La planificación del lanzamiento será menos precisa, de todos modos (porque las cosas cambiarán con el tiempo), por lo que tiene sentido utilizar una unidad menos precisa para la estimación.

Normalmente utilizamos Planning Poker con 13 o 21 siendo el mayor valor permitido antes de que una historia deba dividirse. Para la planificación de versiones, estimamos en "ideal days", para la planificación de iteraciones en "horas ideales". Funciona bien para nosotros