Come documentare correttamente la funzionalità in un progetto agile?

4

Di recente, abbiamo appena terminato la prima fase del nostro progetto.

Abbiamo usato agile con sprint quindicinali. E mentre l'applicazione è andata a buon fine, ora stiamo girando gli occhi su alcune delle attività di manutenzione.

Un compito di manutenzione è che tutta la nostra documentazione appare sotto forma di specifiche. Queste specifiche descrivono 1 o più storie e generalmente sono un insieme di lavoro che alcuni sviluppatori potrebbero rovesciare in una settimana.

Per lo sviluppo, funziona davvero bene - ogni due settimane gli sviluppatori ricevono una specifica ed è un bel pezzo di lavoro che possono semplicemente fare.

Da un punto di vista della documentazione, questo è diventato un casino. Il problema con le specifiche di scrittura che sono focalizzate sulla fornitura di requisiti just-in-time agli sviluppatori è che non abbiamo posto molta enfasi sul quadro generale.

Le specifiche provengono da tutte le angolazioni diverse: potrebbe descrivere una funzione standard, potrebbe descrivere parti di un flusso di lavoro, potrebbe descrivere un particolare schermo ...

E ora disponiamo di regole aziendali relative alla nostra applicazione distribuite su 120 documenti. Cercare qualsiasi documento per una particolare regola o funzione aziendale in particolare è piuttosto difficile perché non si sa quale documento abbia questa informazione, e fare una richiesta di modifica è altrettanto difficile, perché ancora una volta, non siamo sicuri su quale specifica fare la modifica .

Quindi abbiamo forse un paio di settimane di pausa prima che si ritorni a individuare le funzionalità per la fase successiva, ma in questo momento, mi piacerebbe rivedere i nostri processi. Penso che il modo in cui abbiamo lavorato finora in termini di fornitura di specifiche quindicinali funzioni bene.

Ma abbiamo anche bisogno di un modo per gestire la nostra documentazione in modo che le nostre regole aziendali per una data funzione / flusso di lavoro siano facili da individuare / modificare.

Ho due idee.

Uno è quello di compilare tutte le nostre specifiche in una serie di specifiche principali suddivise in alcune vaste aree funzionali. Le specifiche descrivono lo sprint, le specifiche principali descrivono il sistema. L'unico problema che riesco a vedere è 1) Le nostre 120 specifiche non sono tutte ben definite in ampie aree funzionali. Alcuni richiederanno la disgregazione, la fusione ecc. Che richiederà molto tempo. 2) Scriverò specifiche e aggiorneremo le specifiche principali in ogni nuovo sprint. Sembra il doppio del lavoro, e poi gli sviluppatori guardano le specifiche o le specifiche principali?

Il mio altro suggerimento è di ammettere che la nostra documentazione è troppo confusa e gestire quel casino in futuro. Quindi analizziamo ogni specifica, assegniamo come parole chiave ad essa, e poi quando vogliamo cercare una funzione, cerchiamo quella parola chiave. Problemi che riesco a vedere 1) Ancora il problema delle regole aziendali sparse ovunque, le parole chiave rendono più facile trovarlo.

in ogni caso, se qualcuno ha idee decenti o qualsiasi esperienza da condividere sul modo migliore di gestire la documentazione, lo apprezzerebbe molto.

    
posta RoboShop 20.06.2012 - 07:19
fonte

5 risposte

6

Questo è uno dei principali problemi con lo sviluppo " big-A-Agile ": si concentra principalmente sullo sviluppo . Se la documentazione di sistema è importante per gli utenti (e di solito lo fa), i tuoi scrittori tecnici e il loro prodotto di lavoro devono far parte dello sprint. Nella comunità "small-a-agile", siamo arrivati a capire che c'è di più sul prodotto che sul semplice codice. Abbiamo integrato testers e test in sprint, tra cui assicurandoci che i tester conoscano abbastanza bene ciò che viene codificato in modo da poter testare all'interno dello sprint. Dobbiamo fare lo stesso con gli scrittori tecnici, anche se non conosco nessuno che lo faccia ancora.

    
risposta data 20.06.2012 - 15:30
fonte
4

Le specifiche dovrebbero essere i test unitari e la conoscenza degli sviluppatori. Non dovrebbe esserci alcun "documento", che descriva cosa dovrebbe fare il software. Probabilmente hai scambiato le story card degli utenti, che molti sviluppatori agili usano per una sorta di "specifica". Ma quelli sono di breve durata e utilizzati solo per la comunicazione prima che questa user story venga trasformata in codice. Successivamente viene buttato via.

Vorrei mettere in discussione le specifiche come storie utente. Preferirei un sistema, in cui gli esperti di business hanno il proprio documento, che descrive cosa fa il sistema, ma questo documento è solo il loro. Non lo passano ai programmatori come "cosa sviluppare", lo usano solo per tenere traccia di ciò che fa il sistema. Quindi, se vogliono cambiare qualcosa nel software, devono creare una vera user story, passarla agli sviluppatori e aggiornare il loro documento dopo che è finito.

E ti raccomando di dare un'occhiata a Sviluppo / design basato sul dominio . Credo che sarebbe adatto al tuo problema.

    
risposta data 20.06.2012 - 07:42
fonte
1

Le tue domande sembrano una sfuriata su qualcosa che hai pensato sarebbe stato un modo agile di documentazione.

La documentazione agile non significa creare un gran casino, dove sarebbe difficile trovare le informazioni necessarie, ma significa creare una documentazione strutturata (solo necessaria).

Non hai detto fino a che punto sei nel progetto, anche quanto è grande, ma pagare quella parte di ufficio tecnico sarebbe buono a lungo termine. Perciò, il mio suggerimento è di investire un po 'di tempo e fare ciò che devi fare per renderlo buono. Ciò significa anche adattare alcune regole su come scrivere le specifiche, dove memorizzarle, ecc. Quindi in futuro non incontrerai gli stessi problemi.

Per sistemare il casino:

  • forma una struttura di directory e inserisce i documenti giusti nelle directory appropriate. Puoi dividere l'architettura, la progettazione di alto livello, le storie degli utenti, i test e tutto ciò che è richiesto
  • dividere le storie degli utenti (è ciò che le specifiche sono per te?) dalla funzionalità in modo tale che sia facile trovare ogni informazione
  • crea uno schema di denominazione dei documenti piacevole. Non inserire nomi generici di tipo G562GDVKASDF235.doc, ma ad esempio maingui_panel1.doc, maingui_screenorganization.doc, ecc. In questo modo non è necessario un documento che converta il nome del documento in informazioni necessarie.
  • scrivi un documento di panoramica che spiega cosa trovare dove, schema di denominazione, ecc.
  • aggiungi modelli di documento
risposta data 20.06.2012 - 08:01
fonte
1

Non ti stai dimenticando dei requisiti non funzionali?

Avete un diagramma di architettura, un processo di distribuzione, uno schema di database, un piano di ripristino di emergenza e un manuale di amministrazione di sistema che sono aggiornati?

Forse alcuni dei documenti sopra citati non sono necessari nel tuo contesto, ma provengo da un background di manutenzione.

Nel mondo della manutenzione ci occupiamo di sistemi maturi e in molti casi non ci sono membri del personale tecnico in giro che capiscano i requisiti non funzionali.

In questi casi, la documentazione completa e aggiornata non funziona davvero.

    
risposta data 16.02.2013 - 07:26
fonte
-1

Fino a pochi mesi fa, ho lavorato per una società che aveva uno scrittore tecnico per ogni squadra (cioè, seduto sempre con il team) o uno che ha partecipato alla pianificazione del team, riunioni giornaliere, recensioni e retrospettive anche se non si sono seduti con le squadre. Ho lavorato lì per 4-1 / 2 anni e lo hanno fatto per 3 anni prima che iniziassi lì, che era dall'inizio della loro transizione Agile.

    
risposta data 04.07.2016 - 14:03
fonte

Leggi altre domande sui tag