Imagine que coloco cada requisito como una característica en mi rastreador de errores. ¿Sería una buena idea? ¿Hay mejores herramientas?¿Usaría el rastreador de errores para rastrear el desarrollo de requisitos iniciales?
Yo diría que definitivamente es una buena idea, ya que puede seguir más tarde cómo evolucionan los requisitos y las ideas. También puede realizar un seguimiento de su progreso, estimaciones de tiempo, tiempo gastado, etc.
Esto es lo que yo y mucha gente hacemos. Coloque las especificaciones como errores y luego resuelva los errores cuando sean funciones completas.
Es una forma excelente de evaluar la prioridad relativa de resolver errores y agregar nuevas características. De alguna manera, un proyecto vacío tiene muchos errores, porque no hace nada!
El seguimiento de errores se trata de cerrar las entradas. La gestión de productos/requisitos se trata de mantenerlos vivos.
BTW - algunos sistemas de seguimiento de errores admiten la administración de requisitos, pero no es lo mismo.
En general, creo que el uso de un sistema de seguimiento como este para administrar un proyecto funciona muy bien.
La parte importante es que desea poner elementos accionables en su base de datos; solo enumerar los requisitos no ayudará si ese requisito no se traduce directamente en el código/diseño de alto nivel que desea implementar. Entonces, para un requerimiento, podría ingresar un problema para descomponer el requisito en características, generando nuevos registros para implementar las características.
Hacemos esto - Transferimos el Work Breakdown Structure (WBS) desarrollado a partir del Marketing Requirements Document(MRD) en el rastreador de errores. Luego podemos rastrear/monitorear el progreso en los elementos de trabajo individuales. El inconveniente es que potencialmente tiene las definiciones de los requisitos en dos lugares, pero para un equipo pequeño como el nuestro no ha sido un problema.
Hemos intentado una sola vez rastrear solo en el rastreador de fallos pero nos resultó difícil reconstituir el documento completo cuando necesitábamos entregarlo a usuarios externos y/o usuarios no técnicos.
Solo para aquellos que no lo sepan: WBS es http: //en.wikipedia.org/wiki/Work_breakdown_structure y MRD es http://en.wikipedia.org/wiki/Marketing_Requirements_Document –
sí. mi error. Voy a actualizar y corregir. – MikeJ
Depende de qué tan complejos sean los requisitos de seguimiento de sus requisitos. Un sistema completo de seguimiento de requisitos soportará sub-requisitos a muchos niveles y posible integración con otras herramientas de gestión de proyectos. Si el proyecto es simple y sus necesidades son menos complejas, entonces podría usar fácilmente un rastreador de errores.
Bug Tracker es por defectos, incluso documentos. El seguimiento de los defectos en sus documentos de requisitos es tan importante, si no más importante, para el seguimiento de defectos en el software. Cuanto antes encuentres los defectos, más barato es.
Para los requisitos funcionales iniciales, solo generaría un rastreador independiente como una lista de compras. Como están incorporados en la lista, marca el ítem.
Me disculpo por la caja de herramientas inicial, pero mucha gente olvida que los documentos también pueden tener defectos, no solo el software.
Puede verlo como una gestión de problemas, en la que los separa (defectos, nuevas funciones, mejoras, tareas, etc.). Todas estas cosas finalmente terminan en un producto con una cierta versión. ¡Entonces la idea es buena de todos modos! (También puede confirmar el nuevo desarrollo con el ID del problema) – Verhagen
Al hacerlo, crear las notas de la versión también es sencillo. – Verhagen