¿Crea un nuevo documento de requisitos de producto (PRD) para cada versión?

Estoy seguro de que otras personas tienen tácticas diferentes con esto, pero esto es lo que haría:

  • Documente la mayor parte de la funcionalidad existente en un Wiki (con capturas de pantalla y versiones) en unidades que tengan sentido para su proyecto. (Por ejemplo, si su aplicación tiene cuatro vistas discretas, cada una de ellas sería una página wiki. Si tiene 10 módulos, cree uno para cada uno).
  • Para futuras versiones, documente los cambios como historias de usuarios o requisitos de productos y realice un seguimiento de estos en un sistema de gestión de tareas o de seguimiento de problemas.
  • A medida que las versiones se mueven a través del ciclo de vida, actualice la wiki, creando nuevas versiones de las áreas que se cambian. Con suerte, también puede vincular los elementos de seguimiento de problemas relevantes a esta versión.

El resultado final debería ser:

  • Las páginas wiki muestran la evolución y el estado actual del producto.
  • Los elementos de seguimiento de problemas muestran los cambios incrementales y su lógica para agregarlos, con suerte vinculados al control de origen para ver las confirmaciones

Sobre la base de la respuesta de Paul Unterberg, mantendría un PRD en una wiki y luego agregaría historias de usuarios como parte de un registro de cambios en el documento en evolución.

Actualice continuamente el PRD para describir la última versión del producto , mientras mantiene el registro de las historias de los usuarios como referencia.

Y si está utilizando un wiki, debe tener una función de historial si realmente necesita regresar y ver cómo ‘estaban’ las cosas.