Administrar historias de usuarios para un proyecto grande

Question

Estamos empezando un proyecto bastante grande con muchos subproyectos. actualmente no usamos ningún tipo de proceso con nombre, pero espero obtener algún tipo de proceso ágil/scrum por la puerta trasera.

El área en la que me centraré más es tener una buena cartera de trabajo para todo el proyecto y, al menos en mi cabeza, la idea de una iteración donde se toman algunas cosas de la acumulación, se analizaron con más detalle y se desarrollaron a un plazo razonable.

Me pregunto qué técnicas utilizan las personas para dividir los proyectos en cosas que van en la acumulación, y una vez que se crea la acumulación de datos, se mantiene y ordena. también cómo se mantienen las relaciones entre los elementos (es decir, esto debe hacerse antes de que sea posible hacerlo, o esta era una historia, ahora es 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 mantiene su retraso en línea de alguna manera para que pueda ver cómo otros lo hacen.

Otra cosa que conseguiría 1 de mí es ejemplos de historias de usuarios reales de proyectos reales (el "un usuario puede iniciar sesión en" La historia no me ayuda cosas de imagen en mi proyecto.

Gracias.

Answer 1

Te aconsejaría que pienses detenidamente antes de adoptar una herramienta, especialmente porque parece que tu proceso probablemente sea fluido al principio cuando encuentres tus pies. Mi opinión es que es más probable que una herramienta te limite que habilitarte en esta etapa, y no encontrarás un sustituto para un good card-wall in physical space. En vez de eso, te sugiero que concentres tus esfuerzos en la tarea que tienes entre manos y tomas una herramienta cuando sientes que realmente la necesitas. En esa etapa, es más probable que tenga una idea clara de sus requisitos.

He ejecutado varios proyectos ágiles ahora 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 su mayoría, encontramos que una pizarra y tarjetas de índice (una por cada 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: algunas (quizás solo pequeñas) funciones de superficie. Nunca te permitas escribir historias sobre detalles técnicos que no podrías demostrar a un usuario.

La habilidad al programar las historias es tratar de priorizar las cosas que menos conoces primero (planificar lo que quieres aprender, en lugar de lo que quieres hacer) mientras también comienzas con las historias que te permitirán desarrolle las características principales de su aplicación, utilizando historias posteriores para ajustar la funcionalidad (y la complejidad técnica) a su alrededor.

Si está seguro de que puede dejar alguna pieza del rompecabezas para más tarde, no se preocupe por entrar en detalles: solo escriba una sola historia que represente la gran conversación que necesitará para tener más tarde, y seguir con las cosas más importantes. Si necesita tener una idea del tamaño de lo que está por venir, mire una técnica de estimación de delphi de banda ancha llamada planning poker.

Los libros de Mike Cohn, particularmente Agile Estimating and Planning, le ayudarán mucho en esta etapa y le brindarán algunas técnicas útiles para trabajar.

Buena suerte!

Answer 2

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

My Agile Wall (Plus A Few Tricks)

Answer 3

Así que aquí hay algunos consejos: Utilizamos RallyDev.
Creamos una vista de los paquetes en los que residen nuestros requisitos. Las historias grandes se etiquetan como épicas y se colocan en el retraso acumulado de publicación de la publicación para la que están destinadas. Las historias infantiles se agregan a las epopeyas. Hemos encontrado que es mejor mantener las historias muy detalladas. Las historias de grano grueso hacen que sea difícil estimar y ejecutar la historia de forma realista.

Así que en general:

1. Organizar por la liberación

2. Mantenga iteraciones entre 2-4 semanas

3. propietarios producto y el proyecto administradores agregar historias a la acumulación de liberación

4. El equipo de desarrollo estima las historias basadas en tamaños camiseta, puntos, etc ...
5. En la primavera de planificación meeetings el equipo de desarrollo se selecciona el trabajo para la iteración de la cartera de pedidos liberación.

Esto es lo que hemos estado haciendo durante los últimos 4 meses y hemos encontrado que funciona bien. Muy importante para mantener el tamaño de las historias pequeñas y granulares.

Recuerde la Invest y acrónimos inteligentes para evaluar las historias de usuario, una buena historia debe ser: I - Independiente N - Negociable V - Valioso E - estimables S - Pequeño T - comprobable

inteligente :

S - específicos M - medible A - Alcanzable R - Relevant T - Time-caja

Answer 4

Comenzaría diciendo Keep it Simple ... use una hoja de cálculo compartida con tracking (y backup). Si ve problemas de escalado o sincronización de tal manera que mantener el retraso acumulado en un estado consistente es cada vez más lento, cambie. Esto validará y justificará automáticamente los costos de gastos/reciclaje.

He leído algunas cosas buenas sobre Mingle from Thoughtworks.

Answer 5

Al igual que DanielHonig también usamos RallyDev (en una escala pequeña) y parece que podría ser un sistema útil para que al menos investigue.

Además, un gran libro sobre el método de desarrollo de la historia del usuario es User Stories Applied de Mike Cohn. Ciertamente, recomendaría leerlo si aún no lo has hecho. Debe responder muchas de sus preguntas.

Answer 6

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

Help a BA! Managing User Stories ...

Answer 7

Muchas de estas respuestas han sido con sugerencias sobre las herramientas a utilizar. Sin embargo, la realidad es que su proceso será mucho más importante que las herramientas que utiliza para implementar el proceso. Manténgase alejado de las herramientas que intentan meter una metodología en la garganta. Pero también, tenga cuidado de simplemente implementar un viejo proceso no ágil usando una nueva herramienta. Aquí están algunos hechos fuertes a considerar para determinar las herramientas para los procesos:

1. Una mala proceso instrumentado con una herramienta de software dará lugar a una mala IMPLEMENTACIÓN herramienta de software .
2. Los procesos cambiarán según el grupo que esté administrando. Lo importante de es la gente, no el proceso. Implemente algo con el que puedan trabajar con éxito, y su proyecto será exitoso.

Dicho todo esto, aquí están algunas pautas para ayudarle a:

• de inicio con una aplicación pura de un proceso documentado,
• Haga sus iteraciones pequeña,
• Después de cada iteración charla con sus equipos y pregunte qué cambiarían ellos , implemente los cambios que tengan sentido.

Para organizaciones más grandes, si está utilizando SCRUM, use un mecanismo de conexión en cascada. Los maestros de Scrum se reúnen con sus equipos. Luego los Scrum Masters se reúnen en stand-ups de 6 - 9, con un Super-Scrum-MAster responsable de informar los elementos del scrum del Scum-Master al siguiente nivel ... y así sucesivamente ...

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