Qual è una buona soluzione per la raccolta della documentazione delle regole aziendali?

Question

Mi trovo in una situazione, sono sicuro, in cui la mia documentazione sulle regole aziendali si estende su e-mail, documentazione (non aggiornata) e IM. Questo puzza.

Posso pensare a 2 alternative: Sharepoint (lo odio, la funzione di ricerca è terribile) o una wiki.

Alcune cose che mi piacerebbe vedere nella soluzione ideale:

• facilmente aggiornabile: Non farmi tirare su Word per aggiornare la documentazione
• vista Diff: A volte avete solo bisogno di vedere cosa c'è di nuovo
• Sottoscrivibile: Notifica di nuovi cambiamenti in una pagina per pagina
• Ruolo basa: Modifica e visualizzazione delle pagine può essere legato a ruoli
• Allegati: Facile inserimento di prototipi, file, ecc
• Ricerca: E 'un mondo post google, voglio essere in grado di cercare e trova istantaneamente - Sharepoint perde in questa categoria, a meno che quello che usiamo sia configurato in modo errato
• Limitazione allegato: Idealmente, la soluzione non consentirebbe l'upload di un gruppo di documenti Word che chiameremmo la nostra documentazione. Mi piacerebbe che la documentazione avesse un formato coerente (e semplice). Applicazione degli allegati come PDF, txt e così via.

Facendo seguito a mio commento wiki Sembra che ci sono at least 3 wikis che faccio quello che voglio (Incentive, SharePoint-Wiki-Plus, ThoughtFarmer). ThoughtFarmer, ama quel nome.

Answer 1

+ 10⁶ per Wiki, è la soluzione migliore che ho trovato finora per la documentazione, in particolare la documentazione tecnica. IMO, i vantaggi di "buoni" i motori di Wiki su documenti di Office in un VCS sono (ma siete già a conoscenza di che, come questa lista presenta è molto vicino alle vostre esigenze):

• sono solo più facile e veloce da utilizzare rispetto ai documenti Office in un VCS (non è necessario aprire il client VCS, controllare l'ultima versione, opzionalmente bloccarlo, aprire word, salvare, check-in, rilasciare il blocco)
• sono basati sul testo in modo da rendere diff (a differenza della parola) e questo solo a deve avere
• offrono meccanismi di notifica (ad esempio, posta, RSS) e quindi le informazioni vengono inviate all'utente (a differenza di un VCS in cui è necessario estrarre il documento quando non sono aggiornati)
• non esiste un "documento bloccato da un altro problema utente" perché qualcuno ha dimenticato di rilasciarlo (se si utilizza il blocco esclusivo che si verifica spesso su documenti che non è possibile unire)
• pagine possono essere facilmente refactored, riorganizzato , assemblati in documenti più grandi
• sono veramente collaborativi
• forniscono un supporto molto migliore per il codice (ad es.si può puntare direttamente sul codice sorgente in un VCS con formattazione molto meglio che in parola)
• possono indicizzare il contenuto di pagine e documenti allegati (pdf, documenti d'ufficio, ecc) e rendere ricercabile

L'unico problema che ho affrontato quando utilizzo un Wiki per la documentazione è che è più difficile eseguire la versione della documentazione nello stesso momento del codice (es. Fornisci la versione xyz e vuoi "bloccare" la documentazione di questa versione). Ho usato le esportazioni per risolvere questo problema ma non è perfetto.

ho già lavorato con TWiki Foswiki, Confluence e XWiki. Sono tutti "buoni" motori Wiki (come sopra definiti) e tutti soddisfano le tue esigenze. Quindi la scelta finale può dipendere solo dai tuoi vincoli (licenza, prezzi, tecnologia) e preferenze personali.

A partire da oggi, sceglierei Confluence se uno strumento commerciale è un'opzione, XWiki in caso contrario.

Answer 2

Drupal soddisfa i requisiti elencati, è altamente estendibile con un sacco di moduli (vedere alcuni sotto) ed è disponibile sotto GPL.

• Wysiwig editor
• Diff view
• Subscriptions
• User access management
• Attachment management
• Can be configured with Wiki functionality

Answer 3

sto sviluppando uno.

Circa un anno fa ho guardato per il software di gestione dei requisiti 'sulla rete e trovato almeno 30 di loro, in circa 3 categorie:

• Priceless (e ad esempio commercializzato a società aerospaziali)

• costoso (ad esempio, $ 1000 per postazione), che i miei datori di lavoro non hanno mai scelto di utilizzare

• caratteristiche economici o liberi, ma mancanti che mi sembrano importanti

Esistono anche strumenti generici (ad es. Wiki, o e-mail e documenti Word e/o fogli di calcolo), a cui mancano anche funzioni che mi sembrano importanti.

---

penso che si dovrebbe elaborare re: "mancano le caratteristiche che mi sembrano importanti".

Ci sono cose che si possibile fare con un Wiki general-purpose:

• creare una lista di caratteristiche
• descrivere ogni caratteristica (forse una pagina/sezione separata per ciascuna funzione)
• fare questo in modo collaborativo (controllo di versione, notifiche di aggiornamento, pagine di discussione)

Ma, ci sono alcune cose che credo non si può fare con un general-purpose Wiki, le cose ancora piuttosto semplice:

• definire gli attributi personalizzati (ad esempio "Data di inizio", "Costo stimato", ecc.); associare questi valori di attributo con le tue caratteristiche; elenca le caratteristiche (in una tabella o griglia) con i loro attributi (in modo che possano essere ordinate, ad esempio ordinate per "Importanza" o "Difficoltà")

• Aiutare con la tracciabilità (tracciabilità non troppo difficile quando ci sono solo due fasi, ad esempio "requisiti" e "implementazione", ma è più difficile quando ci sono diverse fasi, ad esempio "casi d'uso", "specifiche funzionali", "architettura", "dettagli di implementazione", "casi di test", "risultati di test", e "segnalazioni di bug")

• Supporto di informazioni strutturate, ovvero sottosezioni e non solo sezioni di livello superiore.

Anche il semplice montaggio non è bello come dovrebbe essere. Gli uomini d'affari potrebbero preferire utilizzare un'interfaccia utente di MS Word per la modifica: ma MS Word produce documenti, ad esempio "silos informativi"; ma se non usi MS Word, allora stai usando cosa? Un editor in-browser WYSIWYG? O sintassi markdown?

Answer 4

Un'idea più offensiva è quella di esaminare FitNesse. È un wiki, principalmente finalizzato a descrivere le regole di business (o requisiti di accettazione) come test.

Answer 5

Mi piace utilizzare la funzione Wiki integrata in FogBugz per questo, supponendo che lo si usi già per funzionalità/bug tracking. È comodo avere queste informazioni nello stesso strumento.

Answer 6

Abbiamo utilizzato JIRA su un progetto precedente per archiviare circa 750 diverse regole aziendali. JIRA è principalmente/kinda-di uno strumento di tracciamento dei bug, ma è così potente e personalizzabile che puoi usarlo per ogni tipo di situazioni di flusso di lavoro/processo/conoscenza base. (BTW - Non lavoro per l'azienda che lo produce).

• facilmente aggiornabile: sì
• vista Diff: una storia completa a cambiare è disponibile
• Sottoscrivibile: sì, ha l'idea di "watch-list"
• Role Based: sì, ricco di funzionalità di sicurezza modellare
• allegati: sì, ogni regola può avere un proprio allegati
• Cerca: sì, la ricerca full-text disponibili
• Allegato Restri ction: hmm - non sono sicuro di questo ed esattamente quello che stai cercando di fare.

Alcuni consigli se si decide di andare su questa strada ...

• Fare uso di altre parti di ID personalizzabile di JIRA per riferirsi alla regola per esempio MYPRJ-334
• Avere chiare linee guida su quali siano gli stati che si intende usare, proposti, approvati, implementati, verificati, eliminati.
• L'unica definizione di una regola è nella descrizione - tutti i commenti sono solo commento:
• È possibile collegare regola di utilizzare parte dei casi, i componenti qualunque

E 'un ottimo approccio e mi piacerebbe davvero lo consiglio.