¿Cuál es una buena solución para recopilar documentación de reglas comerciales? [cerrado]

Question

Me encuentro con una situación, común, estoy seguro, en la que la documentación de mi regla de negocios se extiende a través de correos electrónicos, documentación (ahora desactualizada) y mensajes instantáneos. Esto apesta.

Puedo pensar en 2 alternativas: Sharepoint (odio, la función de búsqueda es terrible) o un wiki.

Algunas cosas que me gustaría ver en la solución ideal:

• Fácilmente actualizable : no me hagas abrir Word para actualizar los documentos
• Vista diferencial : a veces solo necesita ver las novedades
• Suscribible : Notificación de nuevos cambios página por página
• Basado en roles : la edición y visualización de páginas pueden estar vinculadas a roles
• Adjuntos : Fácil inclusión de maquetas, archivos, etc.
• Buscar : es una publicación de Google World, quiero poder buscar y encontrar al instante: Sharepoint pierde en esta categoría, a menos que el que utilizamos esté configurado incorrectamente
• Restricción de archivos adjuntos : Idealmente, la solución no permitiría cargar un montón de documentos de Word que luego llamaríamos nuestra documentación. Me gustaría que la documentación tenga un formato consistente (y simple). Aplicación de archivos adjuntos como PDF, txt, etc.

Siguiendo mi comentario de la wiki parece que hay al menos 3 wikis que hacen lo que quiero (Incentivo, SharePoint-Wiki-Plus, ThoughtFarmer). Pensador Granjero, ama ese nombre.

Answer 1

+ 106 para un Wiki, es la mejor solución que he encontrado hasta ahora para la documentación, especialmente la documentación técnica. En mi opinión, las ventajas de "bueno" Los motores Wiki sobre documentos de Office en un VCS son (pero ya lo sabe, ya que esta lista de características está muy cerca de sus requisitos):

• son simplemente más rápidos y fáciles de usar que los documentos de Office en un VCS (no es necesario abrir el cliente VCS, verificar la última versión, opcionalmente bloquearlo, abrir word, guardar, registrar, liberar el bloqueo)
• están basados ??en texto, por lo que crea diferencias (a diferencia de la palabra) y esto es imprescindible
• ofrecen mecanismos de notificación (por ejemplo, correo, RSS) y, por lo tanto, la información se envía a usted (a diferencia de un VCS donde necesita extraer el documento cuando no están actualizados)
• no hay ningún documento bloqueado por otro problema del usuario " porque alguien olvidó liberarlo (si está usando un bloqueo exclusivo, que suele ser el caso en documentos que no puede fusionar)
• las páginas se pueden refactorizar, reorganizar y ensamblar fácilmente en documentos más grandes
• son realmente colaborativos
• proporcionan un soporte mucho mejor para el código (por ejemplo, puede apuntar directamente al código fuente en un VCS con un formato mucho mejor que en word)
• pueden indexar el contenido de páginas y documentos adjuntos (pdf, documentos de oficina, etc.) y hacer que se puedan buscar

El único problema que he enfrentado al usar un Wiki para la documentación es que es más difícil versionar su documentación al mismo tiempo que su código (es decir, usted entrega la versión xyz y desea "bloquear" la documentación de esta versión) . He usado exportaciones para resolver esto, pero no es perfecto.

Ya he trabajado con TWiki Foswiki , Confluence y XWiki . Todos son "buenos" Los motores Wiki (como se definieron anteriormente) y todos cumplen con sus requisitos. Por lo tanto, la elección final puede depender de sus limitaciones (licencia, precio, tecnología) y preferencias personales.

A partir de hoy, elegiría Confluence si una herramienta comercial es una opción, XWiki si no.

Answer 2

Una idea más extravagante es investigar FitNesse . Es un wiki, cuyo objetivo principal es describir las reglas comerciales (o los requisitos de aceptación) como pruebas.

Answer 3

Estoy desarrollando uno.

Hace aproximadamente un año busqué un software de gestión de requisitos en la red y encontré al menos 30 de ellos, en aproximadamente 3 categorías:

• No tiene precio (y se comercializa, por ejemplo, en empresas aeroespaciales)

• Caro (por ejemplo, $ 1000 por asiento), que mis empleadores nunca han elegido usar

• Barato o gratuito, pero faltan características que me parecen importantes

También hay herramientas de uso general (por ejemplo, Wiki, o correos electrónicos y documentos de Word y / u hojas de cálculo), que también faltan características que me parecen importantes.

---

  

Creo que deberías elaborar re: "faltan características que me parecen importantes".

Hay cosas que puede hacer con un Wiki de uso general:

• Crear una lista de características
• Describa cada característica (quizás una página / sección separada para cada característica)
• Haga esto en colaboración (control de versiones, notificaciones de actualización, páginas de discusión)

Pero, hay algunas cosas que creo que no puedes hacer con un Wiki de uso general, incluso cosas bastante básicas:

• Definir atributos personalizados (por ejemplo, " Fecha de inicio " ;, " Costo estimado " ;, etc.); asocie estos valores de atributo con sus características; enumere las características (en una tabla o cuadrícula) con sus atributos (para que puedan ordenarse, por ejemplo, ordenados por "Importancia" o por "Dificultad")

• Ayuda con la trazabilidad (la trazabilidad no es demasiado difícil cuando solo hay dos etapas, por ejemplo, `` requisitos '' e `` implementación ''; pero es más difícil cuando hay varias etapas, por ejemplo, `` casos de uso '', `` especificaciones funcionales " ;, " arquitectura " ;, " detalles de implementación " ;, " casos de prueba " ;, " resultados de la prueba " ;, e " informes de errores ")

• Admite información estructurada, es decir, subsecciones y no solo secciones de nivel superior.

Incluso simplemente editar no es tan bueno como debería ser. La gente de negocios puede preferir usar una interfaz de usuario de MS Word para editar: pero MS Word produce documentos, es decir, silos de información; pero si no usas MS Word, entonces ¿qué estás usando? ¿Un editor WYSIWYG en el navegador? ¿O sintaxis de rebajas?

Answer 4

Me gusta usar la función Wiki integrada en FogBugz para esto, suponiendo que ya la use para el seguimiento de funciones / errores. Es útil tener esa información en la misma herramienta.

Answer 5

Drupal cumple con los requisitos enumerados, es altamente extensible con un montón de módulos (ver algunos a continuación) y está disponible bajo GPL.

• editor de Wysiwig
• Vista diferencial
• Suscripciones
• Gestión de acceso de usuarios
• Gestión de archivos adjuntos
• se puede configurar con la funcionalidad Wiki

Answer 6

Hemos utilizado JIRA en un proyecto anterior para almacenar alrededor de 750 reglas comerciales diferentes. JIRA es principalmente una herramienta de seguimiento de errores, pero es tan poderosa y personalizable que puede usarla para todo tipo de situaciones de flujo de trabajo / proceso / base de conocimiento. (Por cierto, no trabajo para la empresa que lo produce).

• Fácilmente actualizable: sí
• Vista diferencial: hay disponible un historial de cambios completo
• Suscribible: sí, tiene la idea de " listas de observación "
• Basado en roles: sí, modelo de seguridad rico en funciones
• Archivos adjuntos: sí, cada regla puede tener sus propios archivos adjuntos
• Búsqueda: sí, búsqueda de texto completo disponible
• Restricción de archivos adjuntos: hmm - no estoy seguro acerca de este y exactamente lo que está tratando de hacer.

Algunos consejos si decides seguir este camino ...

• Utilice los ID personalizables de JIRA en otro lugar para referirse a la regla, p. MYPRJ-334
• Tenga pautas claras sobre lo que significan los estados que planea usar, propuesto, aprobado, implementado, verificado, descartado.
• La única definición de una regla está en la descripción: todos los comentarios son solo comentarios
• Puede vincular Regla para usar casos, componentes, lo que sea

Es un gran enfoque y realmente lo recomendaría.