Come decidi quanti documenti di requisiti aziendali hai bisogno e come strutturarli? [chiuso]

Question

Come decidi quanti documenti di requisiti aziendali hai bisogno e come strutturarli? [chiuso]

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

0

Negli ultimi due anni, ho lavorato su due progetti.

Il primo, abbiamo usato una metodologia molto agile. È stato molto guidato dagli sviluppatori. In quanto tale, i cambiamenti sono stati molto rapidi e rapidi. La qualità del codice era alta perché era un nuovo sistema. C'è stata un'enfasi sulla proprietà di gruppo del progetto e sulla condivisione delle conoscenze. La maggior parte del trasferimento di conoscenze con nuovo personale, ecc., È stata condotta semplicemente camminando attraverso il codice o il sistema e la maggior parte dei membri del personale del progetto ne sapeva abbastanza del progetto.

Il progetto che pensavo avesse avuto successo, ma uno dei rimpianti che ho è che la quantità di documentazione era probabilmente inadeguata a lungo termine. Abbiamo avuto un sacco di user story che erano specifiche a breve termine solo rilevanti per lo sprint, e una serie di specifiche principali che delineavano i processi aziendali a lungo termine che avremmo tenuto aggiornato. Non avevamo specifiche tecniche diverse da una pagina OneNote con accessi utente e collegamenti per testare le impostazioni / server ecc.

Il problema era mantenere un equilibrio tra l'inserimento di un numero sufficiente di file in modo che fosse utile e non così tanto che nessuno vorrà leggerlo ed essere un peso da mantenere. Non penso che abbiamo mai trovato quell'equilibrio. Le specifiche principali erano probabilmente troppo generiche per essere utili a qualcuno che voleva capire il sistema.

Il secondo progetto è completamente opposto. È un vecchio sistema ed è molto grande. Usiamo una metodologia cascata. Questo progetto è molto guidato dai tester. Come tale, probabilmente abbiamo troppa documentazione: ci sono migliaia di pagine in centinaia di documenti di parole e ci sono duplicati ovunque. (ad esempio documenti con testi di introduzione identici o molto simili)

C'è una grande enfasi nel mantenere perfetto questo mastodontico documento. La creazione di una semplice modifica al sistema richiede l'identificazione dei documenti interessati e delle modifiche minori a tutti loro.

Documentiamo le cose a livelli che probabilmente non sono necessari (ad esempio ho trovato un documento l'altro giorno in cui è stata documentata la finestra di dialogo File Save in IE) e c'è un'enfasi sull'essere corretti oltre la leggibilità.

In breve, abbiamo una mezza dozzina di Business Analysts e il loro compito consiste più nel mantenere la documentazione aggiornata che nelle analisi effettive.

Penso che entrambi questi progetti abbiano delle cattive pratiche e che cosa sarebbe ottimale tra i due. Questo equilibrio dipende probabilmente anche dal sistema, quindi come decidi la quantità di documentazione necessaria e anche come strutturarla in modo che la manutenzione non diventi più costosa che vantaggiosa.

EDIT - Ciao, scusa dovrei averlo menzionato prima che tutte le risposte arrivassero (ero solo in grado di controllare). Sono principalmente focalizzato sui requisiti di business non tecnici qui - quelli che possono essere consumati non solo dagli sviluppatori (il pubblico può includere BA, manager, tester, stakeholder, ecc.)

documentation

posta RoboShop 25.09.2013 - 05:28

fonte

3 risposte

Leggi altre domande sui tag documentation

Come progettare (solo il contorno) un'applicazione PHP di classe enterprise Terminalogy "Controller" in MVC e "ViewController" in IOS

score 2 · Answer 1

Per la documentazione di progettazione / architettura, raccomando il seguente approccio ai nostri architetti e sviluppatori:

Utilizzare la documentazione come contratto ai confini del team e al di fuori del mondo (API, schema del database). Dovrebbe essere disponibile prima che inizi lo sviluppo delle parti corrispondenti. E poiché è un contratto, nessuna parte può cambiarlo senza l'accordo delle parti interessate
non inserire nulla nella documentazione che si trova nel codice o che è meglio spiegato come commento nel codice. Quindi non gonfiarlo con elenchi di metodi interni e i loro parametri.
Ma spiega tutto nella documentazione che NON è nel codice. Ciò comprende:
- panoramica del sistema - per l'istruzione dei nuovi membri del team, o semplicemente per evitare di spiegarlo ancora e ancora
- qualsiasi linea guida o strategia che desideri seguire per sviluppo (tipo di contratto per la tua squadra)
- decisioni sull'architettura o sul design e perché hai scelto un'alternativa rispetto ad altre. Probabilmente hai messo un sacco di lavoro e di pensiero in queste decisioni, e vorrai evitare che qualcuno cambi queste decisioni senza conoscere l'impatto. Alcune di queste decisioni creano un debito tecnico, ed è una buona idea averlo scritto in modo che tu possa lavorarci più tardi.
- qualsiasi deviazione dalle linee guida che potresti avere nella tua azienda, qualsiasi perché. Per trasparenza.
- rischi che vedi e il loro potenziale impatto (ad esempio un tuo sistema potrebbe avere una dipendenza da un componente che non è ancora pronto, o potresti perdere alcune risorse chiave). Questo è particolarmente importante se qualcun altro ti ha obbligato a correre questi rischi.

score 1 · Answer 2

Non penso che ci sia una risposta "corretta" a questa domanda. In realtà la documentazione deve essere succinta e il più semplice possibile per il gruppo di utenti di destinazione.

Vale anche la pena pensare a come il sistema potrebbe crescere durante il processo di pianificazione e apportare modifiche alla struttura della documentazione fin dall'inizio e anche garantire che tutte le persone che contribuiscono ai documenti seguano uno schema particolare (modelli, ecc.).

Pensa ad esso come un buon codice, crea sezioni di alto livello veramente ampie che possono essere approfondite per ottenere sempre più informazioni

Spero che questo aiuti!

score 0 · Answer 3

Al minimo, prenderei in considerazione la documentazione di tutte le principali funzioni e classi e i parametri che adottano e i metodi / proprietà che usano per essere un requisito per un progetto completato. Questo può essere fatto più facilmente come commenti all'interno della base di codice o usando una wiki, o con qualcosa di simile a PHPdoc in cui si aggiungono notazioni speciali al blocco di commenti sopra la funzione o la classe. Bastano pochi minuti per aggiungere commenti rilevanti al codice, quindi farlo in questo modo è relativamente indolore, soprattutto se si rende necessario che gli sviluppatori che lavorano su quel codice in seguito aggiornino anche la documentazione. Perfino l'originale programmatore stesso non ricorderà tutto sei mesi dopo aver finito quel progetto. La parte difficile qui è far sì che tutti siano disciplinati a farlo, perché onestamente, a pochi sviluppatori piace scrivere documentazione.

Le specifiche, i wireframe e le note di sviluppo dovrebbero essere sempre mantenute, anche se rese ridondanti in seguito (per scopi storici.) Se possono essere conservate in un formato ricercabile digitale (wiki, sito Web con funzionalità di ricerca, database) il tempo necessario per trovare qualcosa.

A proposito, sono d'accordo sul fatto che impiegare sei analisti aziendali solo per tenere aggiornata la documentazione sembra uno spreco di risorse, ma alcuni progetti (specialmente quelli pagati con sovvenzioni governative) potrebbero richiedere una condizione di finanziamento.