utilizzando un wiki per i requisiti


9

Sto cercando modi per migliorare la gestione dei requisiti. Attualmente, abbiamo un documento Word pubblicato su un sito Web. Sfortunatamente, non possiamo (per quanto ne sappia) esaminare i cambiamenti da una revisione a quella successiva. Preferirei di gran lunga essere in grado di farlo, proprio come con un wiki o VCS (o entrambi, come il wiki su bitbucket!).

Inoltre, ogni documento descrive le modifiche che gli sviluppatori devono rispettare entro una determinata scadenza. Non esiste una raccolta di funzionalità di app accumulate documentate ovunque, quindi a volte è difficile distinguere tra un bug e una funzionalità (mal progettata) quando si tenta di apportare correzioni rapide ad app legacy.

Quindi ho avuto un'idea su cui volevo ricevere feedback. Che dire:

  1. Usando un wiki in modo da poter rintracciare chi ha cambiato cosa quando (principalmente per vedere anche se sono state apportate modifiche dall'ultima volta che si è guardato).
  2. Avere una, diciamo, pagina wiki per prodotto piuttosto che una per scadenza, tenere il passo con tutte le funzionalità del prodotto piuttosto che le modifiche che dovrebbero essere implementate. In questo modo, posso guardare una particolare revisione della pagina per vedere cosa dovrebbe fare l'app in un determinato momento e posso vedere le modifiche alla pagina dall'ultima versione per i requisiti da implementare entro la prossima scadenza .

Waddayathink?

Risposte:


9

Sì, è una buona soluzione, se organizzi la pagina in una struttura semplice, facile da navigare.

Scegli una wiki con una semplice sintassi. ( Dokuwiki è semplice e non richiede un DB)

Modifica: se si utilizza un sistema di controllo della versione, ovvero SVN o BZR, provare Trac , dove è possibile definire il traguardo, mantenendo richiesta di bug e funzionalità e definire il proprio flusso di lavoro per gestire un bug! Wiki è incluso!


DokuWiki è fantastico, molto facile da configurare e include il supporto LDAP se lavori all'interno di un'azienda.
Vecchio account

2

Una wiki è una buona strada da percorrere. Penso che sarebbe meglio se i documenti fossero ancora in versione. È possibile disporre di documentazione mobile compatibile con le funzionalità più recenti. Scatta ancora foto in questo modo è facile per qualcuno che guarda indietro per trovare la documentazione per quel software tre versioni fa, senza dover guardare attraverso la cronologia del documento, che è fatta per inversioni rapide e non adatta a guardare indietro di anni o mesi.

Ho iniziato a utilizzare Media Wiki, ma ora stiamo usando Xwiki. Ha un buon editor di GUI che chiunque dovrebbe essere in grado di usare senza alcuna formazione. Ha anche un'idea chiamata 'spazi' ogni spazio crea un nuovo spazio dei nomi in modo che prodotti diversi possano avere una pagina chiamata "caratteristiche", piuttosto che caratteristiche_prodotto_x o qualcosa di stupido, ciò quindi riduce notevolmente la necessità di gestire più installazioni wiki. Inoltre ci sono strumenti per integrare word e xwiki, che ti permettono di salvare documenti Word direttamente nella wiki. Detto questo, è molto più ricco di funzionalità.


1

Mi piace il tuo approccio wiki per progetto. Hai citato bitbucket, suppongo che tu li stia usando come repository host. Altrimenti darei anche un'occhiata ai wiki su GitHub.

Se sei disposto a spendere un po 'di soldi, controlla Lighthouse . È il mio modo preferito per tenere traccia delle richieste di funzionalità e dei bug al momento. Sono anche molto affezionato all'utilizzo di Pivotal Tracker, pivotal era gratuito ma ora si sta muovendo verso un modello a pagamento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.