usando un wiki para requisitos

Estoy buscando formas de mejorar la gestión de requisitos. Actualmente, tenemos un documento de Word publicado en un sitio web. Desafortunadamente, no podemos (que yo sepa) mirar los cambios de una revisión a la siguiente. Preferiría poder hacerlo, al igual que con un wiki o VCS (¡o ambos, como el wiki en bitbucket!).

Además, cada documento describe los cambios que se espera que los desarrolladores cumplan en un plazo determinado. No existe una colección de características de aplicaciones acumuladas documentadas en ningún lado, por lo que a veces es difícil distinguir entre un error y una característica (mal diseñada) cuando se intentan hacer correcciones rápidas a aplicaciones heredadas.

Así que tuve una idea sobre la que quería recibir comentarios. Qué pasa:

1. Usando un wiki para que podamos rastrear quién cambió qué cuándo (principalmente para ver si se realizaron modificaciones desde la última vez que se revisó).
2. Tener una, por ejemplo, una página wiki por producto en lugar de una por fecha límite, manteniéndose al día con todas las características del producto en lugar de los cambios que deberían implementarse. De esta manera, puedo ver una revisión particular de la página para ver qué debe hacer la aplicación en un momento dado, y puedo ver los cambios en la página desde la última versión para los requisitos que se implementarán en la próxima fecha límite .

Waddayathink?

Sí, esa es una buena solución, si organiza la página en una estructura simple, fácil de navegar.

Elija un wiki con una sintaxis simple. ( Dokuwiki es simple y no requiere una base de datos)

Editar: si usa un sistema de control de versiones, que es SVN o BZR, pruebe Trac , donde puede definir hitos, mantener la solicitud de errores y características, y definir su propio flujo de trabajo para gestionar un error. Wiki está incluido!

Un wiki es un buen camino a seguir. Creo que sería mejor si los documentos todavía estuvieran versionados. Puede tener documentación flotante que se mantenga con las características más actuales. Aún así, tome fotos instantáneas de esa manera, es fácil para alguien que mira hacia atrás encontrar documentación para ese software hace tres versiones, sin tener que mirar a través del historial del documento, que está hecho para reversiones rápidas y no es adecuado para mirar años o meses atrás.

Comencé a usar Media Wiki, pero ahora estamos usando Xwiki. Tiene un editor de GUI bastante bueno que cualquiera debería poder usar sin ninguna capacitación. También tiene una idea llamada 'espacios', cada espacio crea un nuevo espacio de nombre para que diferentes productos puedan tener una página llamada "características", en lugar de product_x_features o algo tonto, esto reduce en gran medida la necesidad de administrar múltiples instalaciones wiki. También hay herramientas para integrar Word y xwiki, lo que le permite guardar documentos de Word directamente en la wiki. Todos dijeron que es mucho más rico en funciones.

Me gusta tu enfoque wiki por proyecto. Mencionaste bitbucket, supongo que los estás usando como tu host de repositorio. Si no, también echaría un vistazo a los wikis en GitHub.

Si estás dispuesto a gastar un poco de dinero, compra Lighthouse . Es mi forma favorita de rastrear solicitudes de características y errores en este momento. También me gusta mucho usar Pivotal Tracker, pivotal era gratis pero ahora se está moviendo hacia un modelo pago.