Perché preoccuparsi delle specifiche dettagliate?

Come fai a sapere che hai finito, se non sai come dovrebbe essere quando è fatto?

Lo slancio della caratteristica ti catturerà. Cercherai di consegnare per un cliente e, mentre il tempo di completamento si avvicina, scopriranno 10.000 piccole cose che devono assolutamente avere .

Per essere pagato, per far sì che il tuo capo si sdrai quando la scadenza passa, devi essere in grado di estrarre le specifiche e dire: "Tutte le mie stime di tempo e costi erano per questa cosa, non questa nuova cosa che tutti hanno deciso di volere. "

Le specifiche ti consentono di riflettere sulle cose senza aver scritto molto codice in anticipo che dovrebbe essere modificato, se le specifiche cambiano. Consideralo tra la lavagna e la codifica attuale

È anche una buona idea molto da fare quando ci sono più parti indipendenti che scrivono componenti che devono andare insieme.

Oltre ad alcuni degli altri ottimi motivi già menzionati, avere una specifica formale ti consente di fare CYA - Cover Your Ass! Se i gestori / analisti / tester dicono che non hai creato qualcosa correttamente, puoi puntare alle specifiche e dire "L'ho costruito proprio come lo volevi!". Questo include elementi di basso livello come "Tutti i dati persistenti nella tabella AXX_RGV devono essere in MAIUSCOLO", "I moduli Web con meno di 3 campi di input dovrebbero avere il pulsante Invia in basso a sinistra", ecc ...

Anche quando le persone dimenticano le cose su un progetto molto lungo e ampio, avere una specifica dettagliata a cui fare riferimento può essere molto utile. Basta ricordare che le specifiche dovrebbero essere un documento vivente, e se i requisiti cambiano (attraverso ciò che si spera sia un processo documentato e formale), lo stesso devono fare le specifiche. Sì, questo può richiedere più tempo. Nella mia esperienza ne vale la pena (se è fatta bene).

Una specifica formale dei requisiti di un programma è necessaria in quanto l'ingegnere del software deve sapere cosa implementare; l'ingegnere addetto al controllo qualità deve sapere cosa testare e il cliente deve sapere cosa aspettarsi.

Avere una specifica ti consente di sapere quando hai finito di programmare.

Uno dei principali vantaggi potrebbe essere la sicurezza. Non vorrei volare su un aereo di linea in cui la specifica dei sistemi di controllo era un'implementazione di riferimento. Voglio davvero che qualcuno specifichi ciò che i sistemi devono fare in una forma che qualcuno possa non capire con una conoscenza approfondita del software. Mi aspetto che ogni requisito sia stato completamente verificato testando.

Per i sistemi meno critici per la sicurezza, le specifiche sono strumenti di comunicazione. Dovrebbero descrivere in dettaglio ciò che il sistema deve fare in modo sufficientemente dettagliato per costruire e testare il sistema. Come fa il sistema, questa è la responsabilità del codice. I dettagli richiesti variano a seconda delle competenze del dominio del team di sviluppo e dell'accesso agli esperti del dominio.

Le specifiche dovrebbero sempre corrispondere ai sistemi implementati. Se si trovano errori nelle specifiche, le specifiche dovrebbero essere aggiornate.

Errore causa le stime che ho visto indicano che i fallimenti del test sono suddivisi in modo relativamente uniforme tra errori nelle specifiche, nel codice e nei test.

Penso che questa domanda sia il punto cruciale della domanda sul ciclo di vita agile vs. cascata.

Se stai agendo, una premessa di base è che il codice, associato a una stretta interazione con gli sviluppatori, è migliore e più veloce delle specifiche dettagliate. Il team dà la priorità a rilasciare nuove funzionalità e alta qualità rispetto ad altre cose, come meccanismi di comunicazione formale come specifiche di progettazione dettagliate. Ma c'è uno scambio qui - devi avere canali di comunicazione tra i membri del team che permettono loro di chiedere sfumature e intenzioni di progettazione dettagliate quando ne hanno bisogno.

Se stai facendo cascata, stai lavorando partendo dal presupposto che il lavoro di compilazione del codice sotto la progettazione dettagliata e poi di testarlo sia significativo. E vuoi dare agli stakeholder una visione iniziale su come questo lavoro procederà e come sarà quando verrà fatto. Potrebbe essere il controllo del design con il cliente per assicurarsi di aver individuato le funzionalità che hanno senso. Potrebbe anche essere esaminarlo con esperti in altri ambiti, ad esempio recensioni sulla sicurezza, recensioni sulla sicurezza e recensioni dei membri del team che devono integrarsi con il tuo codice. Il presupposto è che queste revisioni consentiranno di risparmiare tempo a lungo termine perché ti eviteranno di indagare su una grande quantità di tempo nello sviluppo della cosa sbagliata.

Ultimamente, ho visto una fusione davvero grande tra i progetti dettagliati e gli strumenti di commento del codice, ad esempio JavaDoc. Poiché la maggior parte dei disegni dettagliati sono impronte del codice e brevi spiegazioni su ciò che farà, questa è più o meno la stessa cosa che ci si aspetterebbe da commenti al codice. Quindi avere uno strumento che trasformerà i commenti del codice in una specifica di progettazione dettagliata è fantastico - un modo molto migliore per tenerlo aggiornato rispetto a farlo manualmente.

Credo che una valutazione imprecisa su come dovrebbe essere il progetto dettagliato per il progetto, è un fattore importante nella crescita dei costi. La parte peggiore è che sei dannato se lo fai e dannato se non lo fai:

• Se il tuo progetto è troppo dettagliato per le dimensioni del team, la complessità del lavoro e i requisiti delle porte da superare (recensioni di sicurezza, recensioni sulla sicurezza, ecc.), hai perso tempo prezioso e denaro su un artefatto che non userai mai.
• Se il tuo progetto non è sufficientemente dettagliato, perderai denaro quando i membri del team formulano ipotesi errate che portano a problemi di integrazione e rischierai pesanti rilavorazioni quando un controllo finale di sicurezza o sicurezza rivela problemi che potrebbero essere stati risolti in modo rapido ed economico erano stati chiari aspetti del progetto prima dell'implementazione.

Non credo sia un caso in bianco e nero - ci possono essere molte volte in cui alcuni componenti sono "abbastanza buoni" se progettati ad alto livello, mentre altri richiedono un lavoro dettagliato e rigoroso. E cambiare il team o gli ambienti di progetto può dettare nuove esigenze di progettazione man mano che il progetto si evolve.

Lavorare su un grande progetto in questo momento. Finora le specifiche hanno aiutato QA a identificare cosa testare, ci ha permesso di addebitare al cliente di più (significativamente come in milioni) durante i test degli utenti, hanno deciso che ciò che avevano accettato non era quello che volevano veramente, abilitato alle persone fare una revisione del codice per vedere se il codice ha soddisfatto il requisito, ha permesso agli sviluppatori di avere una base per verificare se erano stati completati e di puntare alle specifiche per risolvere le controversie su cosa il modulo dovrebbe contenere. Ci ha anche permesso di identificare gli sviluppatori che non producevano ciò che il cliente richiedeva prima che il cliente vedesse il prodotto e che si è rivelato una base per sbarazzarsi di alcune persone che non potevano seguire costantemente le specifiche. La complessità delle nostre specifiche ha aiutato il cliente a rendersi conto che non eravamo oltraggiosi nelle nostre stime di costi e tempi. Una buona speculazione vale il suo peso in oro (quindi contento di avere il miglior analista di business al mondo).

Volevo aggiungere, ho lavorato su progetti con buone specifiche, con cattive specifiche e senza specifiche. Quelli che hanno finito per essere i peggiori erano quelli senza specifiche perché il team di sviluppo e il cliente avevano sempre una visione interna diversa del risultato finale. Questi sono i progetti in cui vai in giro borbottando "dove posso ottenere un modulo di lettura mentale?" Indovinare cosa potrebbe desiderare il cliente è un'esperienza orribile. Le cattive specifiche non sono molto migliori, ma almeno puoi perfezionarti mentre vai e dire "Non sono sicuro di cosa intendessi qui". per ottenere maggiori informazioni prima di perdere tempo a costruire la cosa sbagliata. Il grande progetto su cui sto lavorando adesso ha caratteristiche sorprendentemente buone, ha reso la vita più facile e molto meno stressante.

Personalmente, ritengo che le specifiche dettagliate siano sopravvalutate.

Nella mia esperienza, ciò di cui i clienti hanno bisogno e ciò che i clienti pensano di cui hanno bisogno sono spesso due cose diverse. Se blocchi i requisiti all'inizio, stai costruendo ciò di cui pensano di aver bisogno, non quello di cui hanno effettivamente bisogno. Legalmente, sei al sicuro e sarai pagato, ma non avrai un cliente felice.

D'altro canto, se accetti che lo sviluppo del software sia in una certa misura un'attività esplorativa, cercherai di mantenere i requisiti aperti il più a lungo possibile. Discutere con gli utenti cosa è necessario sapere per l'iterazione corrente , né più né meno. E sappi che a volte, dovrai rivedere queste decisioni in una successiva iterazione. Soprattutto: tieni presente che se ciò accade, non è colpa del cliente. A meno che i tuoi utenti non siano sviluppatori di software, la raccolta dei requisiti è non parte della descrizione del lavoro. Fa parte della descrizione del tuo lavoro.

Quindi, come si impedisce la funzionalità di scorrimento? Idealmente, avere un responsabile di prodotto sano che è incaricato di accettare o rifiutare richieste di funzionalità e che non può essere annullato da nessun altro.

Agile ha più di 10 anni, quindi questo non è un fenomeno nuovo.

Spero che le specifiche siano molto più corte del codice, quindi non so quanti dettagli hai bisogno. Ci dovrebbe essere abbastanza per mantenere i membri del team nel ciclo. La lettura di tutti i codici degli altri è pratica / necessaria?

D'accordo, non c'è bisogno di documenti morti. Preferirei avvicinarmi a una base di codice non familiare senza documentazione che non documentazione errata.

E se il computer è così bravo a eseguire il codice, perché non lasci che apporti le proprie modifiche? Seguire la ricetta sul retro della scatola non ti rende uno chef.