Quelle est la bonne solution pour collecter la documentation sur les règles métier? [fermé]

Question

Je suis confronté à une situation courante, commune, j'en suis sûr, où la documentation de mes règles métier est répartie entre des courriers électroniques, une documentation (maintenant obsolète) et des messages instantanés. Ça pue.

Je peux penser à 2 alternatives: Sharepoint (déteste, la fonctionnalité de recherche est terrible) ou un wiki.

Certaines choses que j'aimerais voir dans la solution idéale:

• Facile à mettre à jour : ne me force pas à mettre Word à jour pour mettre à jour la documentation
• Vue Diff : il suffit parfois de voir les nouveautés
• Abonné : notification des modifications apportées page par page
• Basé sur les rôles : la modification et l'affichage des pages peuvent être liées à des rôles
• Pièces jointes : inclusion facile de maquettes, fichiers, etc.
• Rechercher : c'est un monde Google, je veux pouvoir rechercher et trouver instantanément - Sharepoint perd cette catégorie, sauf si celle que nous utilisons est mal configurée
• Restriction des pièces jointes : dans l'idéal, la solution ne permettrait pas le téléchargement d'un ensemble de documents Word que nous appellerions ensuite notre documentation. J'aimerais que la documentation ait un format cohérent (et simple). Application des pièces jointes au format PDF, txt, etc.

Suite à mon commentaire sur le wiki, il semble qu'il existe au moins 3 les wikis qui font ce que je veux (Incentive, SharePoint-Wiki-Plus, ThoughtFarmer). ThoughtFarmer, aime ce nom.

Answer 1

+ 106 pour un wiki, c'est la meilleure solution que j'ai trouvée jusqu'à présent pour la documentation, en particulier la documentation technique. OMI, les avantages de "bon" Les moteurs de wiki sur les documents Office dans un VCS sont (mais vous en êtes déjà conscients car cette liste de fonctionnalités est très proche de vos besoins):

• ils sont simplement plus rapides et plus faciles à utiliser que les documents Office dans un VCS (inutile d’ouvrir le client VCS, de vérifier la dernière version, de le verrouiller éventuellement, d’ouvrir un mot, d’enregistrer, d’enregistrer, de libérer le verrou)
• ils sont basés sur le texte, donc vous faites des diffs (contrairement à word) et ceci est un must
• ils offrent des mécanismes de notification (courrier, RSS, par exemple) et les informations vous sont alors transmises (contrairement à un VCS dans lequel vous devez extraire un document quand il est périmé)
• il n'y a pas de "document bloqué par un autre problème d'utilisateur" parce que quelqu'un a oublié de le libérer (si vous utilisez un verrou exclusif, ce qui est souvent le cas sur des documents que vous ne pouvez pas fusionner)
Les
• pages peuvent être facilement refactorisées, réorganisées, assemblées dans des documents plus volumineux
• ils sont vraiment collaboratifs
• ils prennent beaucoup mieux en charge le code (par exemple, vous pouvez pointer directement sur le code source d’un VCS avec un formatage bien supérieur à celui de Word)
• ils peuvent indexer le contenu des pages et des documents joints (pdf, documents bureautiques, etc.) et le rendre consultable

Le seul problème que j'ai rencontré lors de l'utilisation d'un wiki pour la documentation est qu'il est plus difficile de mettre à jour votre documentation en même temps que votre code (c'est-à-dire que vous fournissez la version xyz et que vous souhaitez "verrouiller" la documentation de cette version). . J'ai utilisé les exportations pour résoudre ce problème, mais ce n'est pas parfait.

J'ai déjà travaillé avec TWiki Foswiki , Confluence et XWiki . Ils sont tous "bons". Les moteurs de wiki (tels que définis ci-dessus) répondent tous à vos exigences. Le choix final peut donc dépendre de vos contraintes (licence, tarification, technologie) et de vos préférences personnelles.

À partir d’aujourd’hui, je choisirais Confluence si un outil commercial était une option, sinon XWiki.

Answer 2

Une autre idée fausse consiste à examiner FitNesse . Il s’agit d’un wiki principalement destiné à décrire des règles d’entreprise (ou des conditions d’acceptation) sous forme de tests.

Answer 3

J'en développe un.

Il y a environ un an, j'ai recherché un logiciel de gestion des exigences sur Internet et en ai trouvé au moins 30, dans environ 3 catégories:

• Inestimable (et commercialisé par exemple auprès d'entreprises aérospatiales)

• cher (par exemple 1 000 dollars par siège), que mes employeurs n'ont jamais choisi d'utiliser

• Pas cher ou gratuit, mais il manque des fonctionnalités qui me semblent importantes

Il existe également des outils à usage général (par exemple, un wiki, des courriers électroniques et des documents Word et / ou des tableurs), qui manquent également de fonctionnalités qui me semblent importantes.

  

Je pense que vous devriez préciser: "il manque des fonctionnalités qui me semblent importantes".

Il y a des choses que vous pouvez faire avec un wiki à usage général:

• Créer une liste de fonctionnalités
• Décrivez chaque fonctionnalité (peut-être une page / section distincte pour chaque fonctionnalité)
• Faites ceci en collaboration (contrôle de version, notifications de mise à jour, pages de discussion)

Mais il y a des choses que je pense que vous ne pouvez pas faire avec un wiki généraliste, même des choses assez basiques:

• Définissez les attributs personnalisés (par exemple, "Date de début", "Coût estimé", etc.); associez ces valeurs d'attributs à vos entités; répertorie les entités (dans une table ou une grille) avec leurs attributs (afin de pouvoir les trier, par exemple, selon "Importance" ou selon "Difficulté")

• Aide à la traçabilité (traçabilité pas trop difficile quand il n'y a que deux étapes, par exemple "exigences" et "mise en œuvre"; mais c'est plus difficile quand il y a plusieurs étapes, par exemple "cas d'utilisation", "," spécifications fonctionnelles "," architecture "," détails de mise en oeuvre "," cas de test "," résultats de test "et" rapports de bugs ")

• Supporte les informations structurées, c'est-à-dire les sous-sections et pas seulement les sections de niveau supérieur.

Même le simple montage n’est pas une bonne chose comme il se doit. Les gens d’affaires préfèrent peut-être utiliser une interface utilisateur MS Word pour la modification: mais MS Word produit des documents, c’est-à-dire des "silos d’informations"; mais si vous n'utilisez pas MS Word, vous utilisez quoi? Un éditeur WYSIWYG intégré au navigateur? Ou syntaxe de démarques?

Answer 4

J'aime utiliser la fonctionnalité Wiki intégrée à FogBugz pour cela, en supposant que vous l'utilisiez déjà pour le suivi des fonctionnalités / des bogues. C'est pratique d'avoir cette information dans le même outil.

Answer 5

Drupal répond à la configuration requise, il est hautement extensible avec beaucoup de modules (voir ci-dessous) et est disponible. sous GPL.

• éditeur Wysiwig
• affichage Diff -
• Abonnements
• Gestion de l'accès des utilisateurs
• Gestion des pièces jointes
• Peut être configuré avec la fonctionnalité Wiki

Answer 6

Nous avons utilisé JIRA sur un projet précédent pour stocker environ 750 règles de gestion différentes. JIRA est principalement / un peu un outil de suivi de bogues, mais il est si puissant et personnalisable que vous pouvez l'utiliser pour toutes sortes de situations de flux de travail / processus / base de connaissances. (BTW - je ne travaille pas pour la société qui le produit).

• facilement modifiable: oui
• Vue Diff: un historique complet des modifications est disponible
• Abonné: oui, l'idée de "listes de surveillance"
• Basé sur les rôles: oui, modèle de sécurité riche en fonctionnalités
• Pièces jointes: oui, chaque règle peut avoir ses propres pièces jointes
• Recherche: oui, recherche en texte intégral disponible
• Restriction concernant les pièces jointes: hmm - vous n'êtes pas sûr de celui-ci et de ce que vous essayez de faire.

Quelques conseils si vous décidez de suivre cette voie ...

• Utilisez les identifiants personnalisables de JIRA ailleurs pour faire référence à la règle, par exemple. MYPRJ-334
• Établissez des directives claires sur ce que signifie ce que vous envisagez d'utiliser, proposé, approuvé, mis en œuvre, vérifié, abandonné.
• La seule définition d'une règle se trouve dans la description - tous les commentaires ne sont que des commentaires
• Vous pouvez associer une règle à des cas d'utilisation, des composants quelconques

C'est une excellente approche et je le recommande vraiment.