Gestionar historias de usuarios para un proyecto grande [cerrado]

Question

Recién estamos comenzando un proyecto bastante grande con muchos subproyectos.Actualmente no utilizamos ningún tipo de proceso con nombre, pero espero tener algún tipo de proceso ágil/similar a scrum por la puerta trasera.

El área en la que me centraré más es en tener un buen trabajo pendiente para todo el proyecto y, al menos en mi cabeza, la idea de una iteración en la que algunas cosas se tomen del trabajo pendiente, se analicen con más detalle y se desarrollen en un plazo razonable. .

Me pregunto qué técnicas utiliza la gente para dividir los proyectos en elementos que se incluirán en el trabajo pendiente y, una vez creado el trabajo pendiente, cómo se mantiene y ordena.también cómo se mantienen las relaciones entre elementos (es decir, esto debe hacerse antes de que sea posible hacerlo, o esto era una historia ahora son cinco)

No estoy seguro de cómo espero que sea la respuesta a esta pregunta.Creo que lo que puede ser más útil es si hay un proyecto de código abierto que mantenga su trabajo pendiente en línea de alguna manera para que pueda ver cómo lo hacen otros.

Otra cosa que obtendría +1 de mi parte son ejemplos de historias de usuarios reales de proyectos reales (la historia de "un usuario puede iniciar sesión" no me ayuda a imaginar las cosas en mi proyecto.

Gracias.

Answer 1

Le aconsejaría que piense detenidamente antes de adoptar una herramienta, especialmente porque parece que su proceso será fluido al principio a medida que se familiarice.Mi sensación es que en esta etapa una herramienta puede limitarlo más que habilitarlo, y no encontrará que sustituya a una buen muro de cartas en el espacio físico.En lugar de eso, te sugiero que concentres tus esfuerzos en la tarea que tienes entre manos y tomes una herramienta cuando sientas que realmente la necesitas.En esa etapa, es más probable que tenga una idea clara de sus necesidades.

He dirigido varios proyectos ágiles y nunca hemos necesitado una herramienta más compleja que una hoja de cálculo, y eso en un proyecto con un presupuesto de más de un millón de libras.En general, encontramos que una pizarra y fichas (una por historia de usuario) es más que suficiente.

Al identificar sus historias, asegúrese de expresarlas siempre en términos que tengan sentido para sus usuarios: alguna (quizás solo pequeña) pieza de funcionalidad que surja.Nunca te permitas escribir historias sobre detalles técnicos que no pudiste demostrarle a un usuario.

La habilidad al programar las historias es tratar de priorizar primero las cosas que menos sabes (planificar lo que quieres aprender, en lugar de lo que quieres hacer) y al mismo tiempo comenzar con las historias que te permitirán desarrollar las características principales. de su aplicación, utilizando historias posteriores para envolverlas en funcionalidad (y complejidad técnica).

Si estás seguro de que puedes dejar alguna pieza del rompecabezas para más tarde, no te preocupes por entrar en los detalles: simplemente escribe una tarjeta de una sola historia que represente la gran conversación que necesitarás tener más adelante y listo. Sigamos con las cosas más importantes.Si necesita tener una idea del tamaño de lo que está por venir, consulte una técnica de estimación Delphi de banda ancha llamada planificación del póquer.

Los libros de Mike Cohn, particularmente Estimación y planificación ágiles Le ayudará mucho en esta etapa y le brindará algunas técnicas útiles con las que trabajar.

¡Buena suerte!

Answer 2

Al igual que DanielHonig, también utilizamos RallyDev (a pequeña escala) y parece que podría ser un sistema útil para que al menos investigues.

Además, es un gran libro sobre el método de desarrollo de historias de usuario. Historias de usuarios aplicadas por Mike Cohn.Sin duda recomendaría leerlo si aún no lo has hecho.Debería responder a muchas de tus preguntas.

Answer 3

No estoy seguro de si esto es lo que estás buscando, pero aún así puede resultarte útil.Max Pool de codesqueeze tiene un vídeo que explica su "muro ágil".Es genial ver su proceso, incluso si no necesariamente se relaciona con su pregunta:

Mi muro ágil (más algunos trucos)

Answer 4

Así que aquí tienes algunos consejos:Usamos RallyDev.
Creamos una vista de los paquetes en los que se encuentran nuestros requisitos.Las historias grandes se etiquetan como épicas y se colocan en la lista de lanzamientos pendientes del lanzamiento al que están destinadas.A las epopeyas se añaden cuentos infantiles.Hemos descubierto que es mejor mantener las historias muy granulares.Las historias toscas hacen difícil estimar y ejecutar de manera realista la historia.

Entonces en general:

1. Organizar por lanzamiento

2. Mantenga iteraciones entre 2-4 semanas

3. Los propietarios de productos y los gerentes de proyectos agregan historias al retraso de lanzamiento

4. El equipo de desarrollo estima las historias basadas en tamaños de camiseta, puntos, etc.
5. En Spring Planning Meeetings, el equipo de desarrollo selecciona el trabajo para la iteración del acumulador de lanzamiento.

Esto es lo que hemos estado haciendo durante los últimos 4 meses y hemos descubierto que funciona bien.Es muy importante mantener el tamaño de las historias pequeño y granular.

Recuerde las siglas Invest y Smart para evaluar historias de usuarios, una buena historia debe ser:I - independiente n - negociable V - valioso e - estimable s - pequeño t - comprobable

Elegante:

S - M - Medible A - R - T - Time -Boxed Relevante

Answer 5

Yo empezaría diciendo "Mantenlo simple".utilice una hoja de cálculo compartida con seguimiento (y copia de seguridad).Si ve problemas de escalado o sincronización tales que mantener el trabajo pendiente en un estado consistente requiere cada vez más tiempo, cambie.Esto validará y justificará automáticamente los gastos/costes de reconversión.

He leído algunas cosas buenas sobre Mézclate desde Thoughtworks.

Answer 6

Aquí está mi respuesta a una pregunta similar que puede darle algunas ideas.

¡Ayuda a un BA!Gestionar historias de usuarios...

Answer 7

Muchas de estas respuestas han sido sugerencias sobre herramientas a utilizar.Sin embargo, la realidad es que su proceso será mucho más importante que las herramientas que utilice para implementar el proceso.Manténgase alejado de herramientas que intentan imponerle una metodología.Pero también tenga cuidado con simplemente implementar un proceso antiguo y no ágil utilizando una nueva herramienta.A continuación se presentan algunos hechos importantes a considerar al determinar las herramientas para los procesos:

1. Un mal proceso instrumentado con una herramienta de software dará como resultado una mala implementación de la herramienta de software.
2. Los procesos cambiarán según el grupo que esté administrando.Lo importante es la gente, no el proceso.Implemente algo en lo que puedan trabajar con éxito, y su proyecto tendrá éxito.

Dicho todo esto, aquí tienes algunas pautas que te ayudarán:

• Comience con una implementación pura de un proceso documentado,
• Haz que tus iteraciones sean pequeñas,
• Después de cada iteración, hable con sus equipos y pregunte qué cambiarían, implementen los cambios que tienen sentido.

Para organizaciones más grandes, si utiliza SCRUM, utilice un mecanismo de pie en cascada.Los Scrum Masters se reúnen con sus equipos.Luego los Scrum Masters se reúnen en grupos de 6 a 9, con un Super-Scrum-MAster responsable de reportar los elementos del scrum del Scum-Master al siguiente nivel...Etcétera..

Es posible que descubra que tener reuniones semanales de super-scrum será suficiente en el nivel más alto de su jerarquía.