Quanto tempo dedichi ai documenti di progettazione per il tuo software?

6

Ovviamente la dimensione del progetto su cui stai lavorando sarà un fattore importante per quanto tempo dedichi a scrivere il documento / le specifiche di progettazione. Ma passi attraverso tutto, individuando ogni piccolo dettaglio? O hai un approccio più agile e inizi a scrivere il software abbastanza presto e risolvi i problemi mentre vengono da te?

Ho sempre trovato che c'è solo così tanto che puoi andare con la progettazione. Ci saranno inevitabilmente alcune cose che sono state ignorate e, a quel punto, quanto bene puoi adattarti alla situazione significa più della specifica stessa.

Sto prendendo il punto di vista giusto su questo? In realtà è un'opinione, o è un perfetto design spec sempre la strada migliore da percorrere?

    
posta Harry 30.09.2010 - 17:34
fonte

3 risposte

3

Dipende un po 'dal pubblico di destinazione, ma la mia esperienza (più nello sviluppo su piccola / media scala rispetto a lavori su larga scala) è che i documenti di progettazione dettagliata sono ardui e noiosi da scrivere, raramente letti e tendono a finire fuori data entro la data di consegna di un progetto.

Questo non significa che siano inutili - se stai offrendo qualcosa per qualcuno, ci deve essere una dichiarazione autorevole e concordata di ciò che verrà consegnato sufficientemente dettagliato che tutti possono indicarlo nel caso in cui qualcuno non sia soddisfatto dell'affare e dire "questo è ciò che abbiamo promesso" e valutarlo rispetto a ciò che è stato consegnato.

Se dovessi creare un'azienda per costruire un prodotto, tuttavia, non mi preoccuperei molto di una specifica dettagliata. Vorrei documentare cosa avremmo intenzione di fare, ma non vorrei entrare troppo in profondità per quanto riguarda come - questa è la parte che più probabilmente cambiare e lasciare i documenti obsoleti e inutili o addirittura inaccurati per essere effettivamente ostruzionistici. Preferirei documentare il "come" roba nel codice usando qualsiasi formato di documentazione che la lingua o l'IDE supporti meglio, così come il codice cambia è più facile aggiornare la documentazione allo stesso tempo. Non si fermerà perché non sarà aggiornato, ma lo ridurrà un po '.

Idealmente vorresti un documento di design che possa raddoppiare il tuo manuale quando il tuo codice è completo, ma non conosco nessuno che lo abbia gestito con successo.

    
risposta data 30.09.2010 - 18:25
fonte
1

Dipende sicuramente dalle dimensioni e dalla struttura del progetto.

Per i progetti dei clienti, sono necessarie specifiche dettagliate. Mi piace coinvolgere pesantemente il cliente durante le specifiche di progettazione. Ciò aiuta a scovare ulteriori considerazioni e offre al cliente una migliore comprensione di cosa aspettarsi. Di solito c'è un cambiamento positivo nell'atteggiamento (verso tempi e prezzi) dopo la scoperta e le specifiche sono complete. Questo ci consente anche di impostare le pietre miliari - e colpirle - che è favorevole per il cliente e per il nostro team di sviluppo.

Per progetti interni e progetti collaterali divertenti, generalmente creo un diagramma di flusso e un elenco di funzioni, quindi inizio a hackerarlo insieme. In questi casi, ciò che trovo più importante di una scheda tecnica, è l'interfaccia utente reale. Farò il wireframe del sito su carta e realizzerò una semplice compilazione dell'interfaccia utente (html / css). Questo mi aiuta a riflettere sull'esperienza utente, che apprezzo più delle caratteristiche specifiche dei miei progetti. Posso sempre tornare indietro e mettere insieme le caratteristiche più tardi.

    
risposta data 30.09.2010 - 18:17
fonte
1

Dipende da cosa intendi per documenti di progettazione.

Trascorro da 1/3 a 1/2 del mio tempo a scrivere disegni per il software che scrivo, in un taccuino, a delineare le cose, a capire algoritmi, relazioni, storie, ecc.

Non faccio tutto questo in anticipo.

Non ho un documento principale firmato e sigillato da cui lavoro. Ho avuto in passato, e non ho mai fatto alcun lavoro, perché stavo sempre aspettando che qualcuno firmasse qualcosa. Questo è stato più un problema con la burocrazia dell'azienda che con il concetto di design tutto in anticipo, ma preferisco ancora l'approccio più fluido / agile che ho ora.

    
risposta data 30.09.2010 - 18:42
fonte

Leggi altre domande sui tag