Quanto è importante scrivere specifiche funzionali?

Question

Non ho mai scritto specifiche funzionali, preferisco saltare nel codice e progettare cose mentre vado. Finora ha funzionato bene, ma per un recente progetto personale sto scrivendo alcune specifiche che descrivono tutte le caratteristiche del prodotto e come dovrebbe "funzionare" senza entrare nei dettagli di come verrà implementato, e sono trovandolo molto prezioso.

Quali sono i tuoi pensieri, scrivi le specifiche o inizi a programmare e pianificare mentre procedi, e quale pratica è migliore?

Answer 1

Se stai guidando da casa al negozio di alimentari più vicino, probabilmente non hai bisogno di una mappa. Ma ...

Se stai guidando verso un posto in cui non sei mai stato prima in un altro stato, probabilmente lo fai.

Se stai guidando a casaccio per divertimento di guida, probabilmente non hai bisogno di una mappa. Ma ...

Se stai cercando di arrivare da qualche parte nel modo più efficace (minimizza la distanza, minimizza il tempo, fai tre fermate specifiche lungo la strada, ecc.) Probabilmente lo fai.

Se stai guidando da solo e puoi impiegare tutto il tempo che desideri, fermandoti ogni volta che vedi qualcosa di interessante o riconsiderando la tua destinazione o il tuo percorso, potresti non aver bisogno di una mappa. Ma ...

Se stai guidando come parte di un convoglio, e tutti hanno bisogno di fermare cibo e pernottamento insieme e devi arrivare insieme, probabilmente lo fai.

Se pensi che non stia parlando di programmazione, probabilmente non hai bisogno di specifiche funzionali, schede trama, narrativa, CRC, ecc. Ma ...

Se pensi che lo sia, potresti prendere in considerazione almeno una delle precedenti.

; -)

Answer 2

Per qualcuno che salta nel codice " e " design [s] come vanno " ;, direi che scrivere qualsiasi cosa inclusa una specifica funzionale è meglio dei tuoi metodi attuali. È possibile risparmiare un sacco di tempo e fatica se si prende il tempo per pensarci e progettarlo prima ancora di iniziare.

• I requisiti aiutano a definire ciò che devi fare.
• Il design aiuta a definire ciò che stai pianificando di realizzare.
• La documentazione dell'utente definisce ciò che hai realizzato.

Scoprirai che la maggior parte dei luoghi avrà alcune variazioni di questi tre documenti. Le specifiche funzionali possono essere raggruppate nel documento di progettazione.

Ti consiglio di leggere Sviluppo rapido se non sei convinto. Puoi davvero lavorare più velocemente se impieghi più tempo per pianificare e progettare.

Answer 3

Salto "direttamente al codice" per i grandi progetti software quasi sicuramente porterebbe al fallimento (come farebbe immediatamente iniziare a posare mattoni per costruire un ponte).

I ragazzi di 37 Signals direbbero che è meglio scrivere un breve documento su carta piuttosto che scrivere un specifiche complesse Direi che questo potrebbe essere vero per deridere rapidamente nuovi siti Web (dove il design e l'idea potrebbero condurre meglio di uno schema rigido), ma non sempre accettabili in altre situazioni di vita reale.

Basti pensare all'importanza (legale, uniforme) che può avere un documento di specifica firmato dal cliente.

Il morale probabilmente è: sii flessibile e pianifica con le specifiche funzionali o tecniche di cui hai bisogno , secondo lo scenario del tuo progetto.

Answer 4

Per gli hack unici e le piccole utility, non preoccuparti.

Ma se stai scrivendo un'applicazione seria, di grandi dimensioni, hai clienti esigenti e deve funzionare a lungo, è DEVE. Leggi i fantastici articoli sull'argomento - sono un buon inizio.

Answer 5

Lo faccio in entrambi i modi, ma ho imparato qualcosa da Test Driven Development ...

Se vai a scrivere un codice con una roadmap, arriverai alla fine del viaggio molto più velocemente di te se inizi a camminare lungo la strada senza avere idea di come andrà a sbattere nel mezzo.

Non devi annotare ogni dettaglio di ciò che ogni funzione sta per fare, ma definisci le tue basi in modo che tu sappia cosa dovresti fare per far funzionare bene tutto insieme.

Detto ciò, ieri ho dovuto scrivere una serie di gestori di eccezioni e mi sono appena immerso senza cercare di progettarlo. Forse dovrei rileggere il mio consiglio;)

Answer 6

Ciò che molte persone non vogliono ammettere o realizzare è che lo sviluppo del software è una disciplina ingegneristica. Si può imparare molto su come si avvicinano alle cose. Mappare cosa farai in un'applicazione non è necessariamente vitale per i piccoli progetti in quanto è normalmente più facile tornare indietro e correggere i tuoi errori. Non vedi quanto tempo è sprecato rispetto a scrivere prima cosa farà il sistema.

In realtà in grandi progetti è quasi necessario disporre di una road map su come funziona il sistema e cosa fa. Chiamalo una Specifica Funzionale se vuoi, ma normalmente devi avere qualcosa che ti mostri perché il passaggio b segue il passaggio a. Tutti pensiamo di poterlo pensare al volo (anche io sono sicuramente colpevole di questo), ma in realtà ci causa problemi. Ripensaci e chiediti quante volte hai incontrato qualcosa e ti sei detto "Amico, vorrei averci pensato prima?" Oppure qualcun altro vede quello che hai fatto e ti ha mostrato che avresti potuto fare 3 passi per compiere un compito in cui hai preso 10.

Metterlo sulla carta ti costringe davvero a pensare a cosa farai. Una volta che è sulla carta non è più un pensiero nebuloso e quindi puoi guardarlo e valutare se ciò che stavi pensando ha davvero senso. La modifica di un documento di una pagina è più semplice della modifica di 5000 righe di codice.

Answer 7

Se lavori in un ambiente XP (o simile), utilizzerai storie per guidare lo sviluppo insieme a molti test di usabilità di unità e corridoi (ho bevuto Kool-Aid , immagino).

Tuttavia, esiste un'area in cui è assolutamente necessaria una specifica: quando si coordina con un team esterno. Ho avuto un progetto con una grande compagnia assicurativa in cui dovevamo avere un accordo su alcuni comportamenti del programma, alcuni aspetti della progettazione del database e una serie di layout di file. Senza le specifiche, ero ampio aperto a un'interpretazione creativa di ciò che avevamo promesso. Erano brave persone - mi fidavo di loro e mi piaceva lavorare con loro. Ma comunque, senza quella specifica sarebbe stata una marcia della morte. Con le specifiche, ho sempre potuto indicare dove si erano discostati dal layout concordato o dove chiedevano un ulteriore lavoro personalizzato ($$!). Se lavori con una relazione semi-antagonista, le specifiche possono salvarti dal peggio: una causa.

Oh sì, e sono d'accordo con Kieveli: "saltando a destra nel codice" non è quasi mai una buona idea.

Answer 8

Direi totalmente " dipende " sul tipo di problema. Tendo a chiedermi se lo sto scrivendo per il gusto di farlo o per gli strati sopra di te. Ho anche discusso di questo e la mia esperienza personale dice che dovresti mantenere il progetto in linea con le aspettative (piuttosto che andare fuori rotta).

Answer 9

Mi piace scomporre prima qualsiasi problema non banale sulla carta, piuttosto che saltare al codice, per una serie di motivi;

• Le cose che scrivo su carta non devono compilare o avere senso su un computer
• Posso lavorare a livelli arbitrari di astrazione su carta
• Posso aggiungere facilmente immagini e diagrammi
• Riesco a riflettere e ad eseguire il debug di un concetto molto rapidamente

Se è probabile che il problema che sto affrontando implichi una notevole quantità di tempo o un numero di altre persone, lo scriverò come una specifica funzionale di contorno. Se venissi pagato da qualcun altro per sviluppare il software e ci fosse qualche potenziale ambiguità, aggiungerò abbastanza dettagli extra per rimuovere questa ambiguità. Mi piace anche usare questa documentazione come punto di partenza per lo sviluppo di casi di test automatizzati, una volta che il software è stato scritto.

In altre parole, scrivo abbastanza di una specifica funzionale per comprendere correttamente il software che sto scrivendo da solo e per risolvere eventuali ambiguità per chiunque sia coinvolto.

Answer 10

Raramente sento la necessità di una specifica funzionale. OTOH Ho sempre l'utente responsabile della funzione di una telefonata, quindi posso sempre interrogarli per i requisiti funzionali mentre vado.

Per me una specifica funzionale è più uno strumento politico che tecnico. Immagino che una volta che hai una specifica puoi sempre incolpare la specifica se in seguito scopri problemi con l'implementazione. Ma a chi dare la colpa non interessa davvero, il problema sarà ancora presente anche se trovi un capro espiatorio, meglio quindi rivisitare l'implementazione e provare a farlo nel modo giusto.

È praticamente impossibile scrivere una buona specifica, perché in realtà non si conosce abbastanza il problema o gli strumenti o i cambiamenti futuri nell'ambiente per farlo bene.

Quindi penso che sia molto più importante adattare un approccio agile allo sviluppo e dedicare risorse e tempo sufficienti per rivisitare e riformattare mentre procedi.

Answer 11

È importante non scriverli: Non c'è niente di funzionale in una specifica funzionale