¿Cuál es un buen proceso para escribir tarjetas de cuentos? [cerrado]

Question

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

• Tenemos una buena idea de lo que el cliente quiere a través de talleres
• Tenemos un documento de requisitos comerciales que será firmado por ellos.

Nuestro proceso de definición de historias es el siguiente

1. Tomamos una función que el cliente quiere y escribimos una historia
2. Tenemos una breve discusión de diseño entre el equipo
3. Luego determinamos una estimación para la tarjeta
4. Si la tarjeta dura más de 3 días, la desglosamos más y volvemos a repetir desde el paso 2

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

Esto lleva un tiempo y puede ser bastante agotador

¿Qué otros métodos se pueden usar para definir las tarjetas de la historia? Esto puede tomar ¿Qué otras formas de reunir los requisitos en las tarjetas de historia?

EDITAR:

1. Esta no es la primera vez que lo hacemos, es el proceso normal
2. El cliente es un cliente interno
3. Estoy interesado en cómo escribes las tarjetas contra las que terminas codificando

Answer 1

Sugeriría algo que llamamos " lanzamiento del juego de planificación " ;. Es muy similar a lo que haces para una iteración, sin embargo, lo hicimos a 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 saber que íbamos a estar lejos . Luego, puede agregar todas esas estimaciones juntas para tener una idea aproximada de cuándo cree que, con base en 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 pero de margen de maniobra porque, al igual que sus clientes, no puede predecir el futuro (o al menos yo puedo ' t).

Answer 2

No se puede saber cuándo se hará todo y seguir un proceso ágil. Incluso si trabaja muy duro para estimar todo, cuanto mayor sea el trabajo, mayor será su 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 menos.

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

Usted: ¿Cuándo necesita estas funciones?

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

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

C: Por supuesto.

Usted: si entregara todas estas características mañana, ¿sería eso lo suficientemente pronto?

C: Por supuesto.

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

C: Todavía es demasiado tarde.

Usted: 3 meses?

C: Eso es demasiado tarde, más bien 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 funciones 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: OK, si agregamos la función X, tendremos que eliminar una función. ¿Cuál no necesitas?

C: podemos hacerlo solo con una parte de la función Y.

Tú: OK. Tomaremos esta lista y elaboraremos una estimación más detallada.

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

He encontrado una y otra vez que la razón subyacente para las estimaciones y la planificación & "; todo &"; es que quieren una promesa de entrega de algo para una fecha. Trabajar hasta la fecha objetivo funciona mucho mejor porque:

1. Obliga al cliente a ayudar a hacer las compensaciones

2. Expone la razón real de las estimaciones

3. Reduce el número de cosas para estimar.

4. Ayuda a identificar qué características son importantes para cada sprint.

Answer 3

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

Normalmente usamos Planning Poker con 13 o 21 como el mayor valor permitido antes de que una historia deba dividirse. Para la planificación del lanzamiento, estimamos en & Quot; días ideales " ;, para la planificación de iteración en " horas ideales " ;. Funciona bien para nosotros.

Answer 4

¿Cómo planea lanzar la aplicación al cliente? ¿Estás haciendo entregas incrementales? ¿O es esta la planificación de una entrega inicial?

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 comprar algo de tiempo extra ... en caso de que el cliente cambie de opinión sobre una característica ( lo harán). Con suerte, esto facilitará la estimación de la fecha de entrega final ...

Si puede convencer a su cliente de que debe entregar de forma incremental, encontrará que creará menos historias redundantes a medida que cambien las especificaciones. Además, no tendrá que hacer tanto trabajo inicial y, a medida que avance el desarrollo, puede escribir el próximo lote de historias mientras el desarrollo está en marcha.

Espero que esto ayude.

Answer 5

Normalmente solo pido títulos de historias por adelantado. Trato de ver si puedo clasificarlos al menos en un orden de magnitud. Doy una estimación muy aproximada basada en el número de títulos y mi velocidad / título estimado. Por lo general, haré que el cliente divida los títulos en (1) lo que necesita tener ahora, (2) lo necesita pero puede esperar, y (3) esto sería bueno.

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

Cuando llegamos aproximadamente un mes después de comenzar con las historias grupales (2), me siento nuevamente con el cliente (en una sesión de planificación más centrada, usu. hablando con ellos todo el tiempo), para comenzar el proceso nuevamente con las historias grupales (2).

Las historias que se agregan a medida que avanza el proyecto se colocan en el grupo correcto y se manejan según corresponda para ese grupo; si es una versión actual, suficientes detalles para trabajar, si es posterior, solo el título como marcador de posición.

La otra cosa que hago es asegurarme de que el cliente entienda que es un proceso cooperativo y que terminaremos con lo que quieren. Pueden elegir cuándo parar, incluso si quedan historias en el tablero. Mientras les brinde el valor que les importa, seguimos desarrollando. Deben confiar en que estoy haciendo lo correcto para ellos y que estoy trabajando diligentemente. Necesito confiar en que me darán la mejor información posible sobre lo que quieren tan pronto como sea posible.

Answer 6

Si está intentando ser fiel a XP, le sugiero que vaya aquí y lea sobre la diferencia entre la planificación de lanzamiento y la planificación de iteración. No debería hacer una estimación de tarea individual hasta que esté listo para comenzar a codificar.

Stories! = Tareas. Las historias se dividen en tareas, que luego haces & Lt; Estimación de 3 días para. Estimar las historias es más abierto y debería poder decidir sobre los umbrales para las estimaciones de historias que funcionen mejor para usted y su equipo después de haberlo hecho por un tiempo. (IE & Lt; 1 semana, 2 semanas, & Gt; 2 semanas, etc.)

La parte más importante de la estimación es hacer un seguimiento del tiempo real empleado y realizar ajustes en su proceso de estimación. XP se trata de comentarios.