project-management - tablero - scrum
Gestión de historias de usuario para un gran proyecto (7)
Estamos comenzando 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 más me concentraré es tener una buena cartera de trabajo para todo el proyecto y, al menos en mi cabeza, la idea de una iteración en la que se toman algunas cosas de la cartera, se analizaron con más detalle y se desarrollaron a una fecha límite razonable .
Me pregunto qué técnicas utilizan las personas para dividir los proyectos en cosas que van en la cartera de pedidos pendientes, y una vez que se crea la cartera de pedidos, 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 hacer eso, o esta era una historia, ahora son las cinco)
No estoy seguro de lo que espero sea la respuesta para 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 podría obtener +1 de mí es ejemplos de historias de usuarios reales de proyectos reales (la historia de "un usuario puede iniciar sesión" no me ayuda a visualizar cosas en mi proyecto).
Gracias.
No estoy seguro de si esto es lo que está buscando, pero aún puede ser útil. Max Pool de codesqueeze tiene un video que explica su "pared ágil". Es genial ver su proceso, incluso si no necesariamente se relaciona con su pregunta:
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 by Mike Cohn. Ciertamente, recomendaría leerlo si aún no lo has hecho. Debe responder muchas de sus preguntas.
Así que aquí hay algunos consejos: Usamos RallyDev.
Creamos una vista de los paquetes en los que viven 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.
Entonces, en general:
Organiza por el lanzamiento
Mantenga las iteraciones entre 2-4 semanas
Los propietarios de los productos y los gerentes de proyectos agregan historias al retraso
- El equipo de desarrollo estima las historias basadas en tamaños de camiseta, puntos, etc.
- En Spring planning meeetings, el equipo de desarrollo selecciona el trabajo para la iteración del retraso en la publicació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 las siglas de Invest and Smart para evaluar las historias de los usuarios, una buena historia debería ser: I - Independent N - Negociable V - Valuable E - Estimable S - Small T - Testable
Inteligente:
S - M específico - Medible A - R alcanzable - T pertinente - Tiempo en caja
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 de Thoughtworks .
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. Tengo la sensación de que es más probable que una herramienta te limite que habilitarte en esta etapa, y no encontrarás un sustituto para una buena pared de tarjeta en el espacio físico . 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) partes de la funcionalidad 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 intentar 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 desarrollar las características principales de su aplicación, utilizando historias posteriores para ajustar la funcionalidad (y la complejidad técnica) a su alrededor.
Si confías en que puedes dejar alguna parte del rompecabezas hasta más tarde, no te preocupes por entrar en detalles: solo escribe una sola historia que represente la gran conversación que necesitarás tener más adelante, y obtén 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 planificación de póker .
Los libros de Mike Cohn, particularmente Agile Estimating and Planning te ayudarán mucho en esta etapa y te darán algunas técnicas útiles para trabajar.
¡Buena suerte!
Aquí está mi respuesta a una pregunta similar que puede darte algunas ideas
Muchas de estas respuestas han sido con sugerencias sobre herramientas para usar. 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í hay algunos hechos importantes a considerar al determinar las herramientas para los procesos:
- Un mal proceso instrumentado con una herramienta de software dará como resultado una mala implementación de la herramienta de software.
- Los procesos cambiarán en función del grupo que esté administrando. Lo importante es la gente, no el proceso. Implemente algo en lo que puedan trabajar con éxito y su proyecto será exitoso.
Todo lo dicho, aquí hay algunas pautas para ayudarlo:
- Comience con una implementación pura de un proceso documentado,
- Haga sus iteraciones pequeñas,
- Después de cada iteración, hable con sus equipos y pregúnteles qué cambiarían, 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 encontrar que tener reuniones semanales de super scrum será suficiente en el nivel más alto de su jerarquía.