Estamos comenzando a utilizar un proceso de Scrum para el desarrollo. Tenemos una buena pila de historias de usuarios ahora. Sin embargo, me pregunto, una vez que la historia de un usuario está completa, probada e implementada, ¿hace algo más con ella? Estamos usando pequeñas tarjetas de índice en este momento, creo que estaría bien tirarlas a la basura.Historias de usuario completadas: ¿descartar? ¿archivo?
Si las conserva, ¿qué hace con ellas más tarde?
Archívelos para referencia en proyectos futuros. Serán útiles cuando tenga que estimar puntos de historia. Muchas veces, historias que suenan similares ocurren en todos los proyectos.
La papelera parece un lugar apropiado.
Guárdalas (archívalas) para que si hay una disputa o argumento sobre algo en el futuro, tengas una referencia y puedas protegerte.
Disputa? Diría que si el sistema no funciona como lo quiere el PO, es hora de escribir una nueva historia de usuario (o quizás presentar un error si es más parecido). Lo que está escrito en una tarjeta de historia de usuario aceptada es irrelevante. – PEZ
Suena como la filosofía exactamente opuesta a cualquier proceso ágil. ¿Seguro que no estás hablando de documentos de requisitos de un proceso en cascada? – madlep
Yo diría que esto es realista en el escenario en el que se presenta ágil a una empresa basada en cascadas alocadas y para ayudar a resolver cualquier problema inicial. – Donnelle
PEZ es casi correcto. Recicle las tarjetas en lugar de destruirlas. :)
Realmente no tiene sentido mantenerlos. Si necesita un historial de cambios, puede obtenerlo de su SCM y probar los scripts.
Um - guárdelos y póngalos en el archivo del proyecto. CYA en todos los casos. Nunca se sabe cuándo volverá un cliente y le preguntará "¿por qué es así?" O "¿quién decidió que era así?". A continuación, puede sacar la historia del usuario y tener una copia de seguridad.
Mantenga siempre todo esto hasta que el período de garantía haya expirado en su software ... a menos que desee colocarlo en una posición en la que se le pida que "solucione" algo que realmente fue un cambio gratis.
Otra votación para su mantenimiento. Sé que es una mala palabra, pero las historias de los usuarios son parte de su documentación y cumplen una función importante.
Dentro de tres años, cuando usted (o el heredero) esté realizando cambios en el sistema, es útil contar con los documentos históricos para saber por qué hizo las cosas de la forma en que lo hizo.
También ayuda cuando la situación cambia y tiene que volver a escribir para poder repasar las historias de usuarios que satisface la aplicación y determinar si esas mismas historias se aplican o no a la nueva versión.
Las historias de usuario completadas son esencialmente la especificación final para su proyecto. Si comenzó con un documento o especificación de requisitos formales, hay muchas lecciones que aprender comparando las historias de usuario completadas con ese documento. Si no tiene un documento inicial, sus historias de usuario completas documentan la funcionalidad de su proyecto. En cualquier caso, creo que es muy valioso aferrarse a ellos para referencia futura, ya sea en proyectos post mortem o al estimar y planificar proyectos posteriores.
Me parece que nunca sabemos qué va a ser útil en el futuro, por lo que mi recomendación es etiquetarlos y archivarlos. Si está utilizando tarjetas físicas, escanearlas y luego hacer algo tan simple como agregar una etiqueta al archivo de imagen. Imagine mirar una nube de etiquetas más tarde para encontrar hilos comunes o para localizar y reutilizar su contenido.
Como con todo el scrum, si comienza a tomar demasiado tiempo, probablemente no valga la pena. No lo convierta en un proceso loco, simplemente archívelo rápidamente y olvídese.
Saludos, Reeves
lo general envolver cada iteraciones por valor de historias de usuario y tareas() en una banda de goma y una nueva tarjeta delante indicando la velocidad y los puntos estimados. Sin embargo, nunca he tenido ningún uso para ellos, a excepción de una reflexión nostálgica. Así que guárdelos para el archivo que diría: -9
¡Agárrense a ellos!
Escribo requisitos (en lugar de código), pero con frecuencia me encuentro releyendo viejas historias de usuario y pruebas de aceptación (las mías y otras).
Revisar viejas historias me puede ayudar a encontrar el fraseo más claro para conceptos complicados, en lugar de reinventar la rueda. A veces sirven como un recordatorio útil para los detalles que de otra manera podría olvidar documentar. Las historias escritas por otros me ayudan a acelerar las funciones en las que no participé, y probablemente serán una buena herramienta de aprendizaje para los nuevos empleados.
Podría continuar, pero permítanme decirlo de esta manera:
¿Qué es más probable que cause mayores problemas, manteniendo las historias y no necesitándolas, o necesitando las historias y no tenerlas?
La velocidad de un equipo cambia con la experiencia y los cambios de personal. Las viejas estimaciones no son realmente útiles. – ewalshe
Mi respuesta está en el contexto de un equipo relativamente estable. – moffdub
+1: Estimación basada en la experiencia. Esta es su información de referencia. Historia original y costo final para implementar. –