Voglio spiegare perché le specifiche non devono essere cambiate durante il periodo di sviluppo

Una specifica cambia quasi sempre durante lo sviluppo di progetti diversi da quelli più semplici.

I motivi sono:

• Lo sviluppo o più verosimilmente il test di integrazione del progetto rivela cose non notate quando le specifiche originali sono state fatte - dai casi limite alle faccette principali. Per esempio. lo sviluppatore nota che potrebbero arrivare conferme dei messaggi fuori ordine.

• Le condizioni del mondo reale che determinano le specifiche non sono congelate. Per esempio. viene creato un nuovo prodotto finanziario che deve essere aggiunto alle specifiche di elaborazione diretta.

• Le pressioni di scadenza determinano l'eliminazione delle funzioni.

• Vengono scoperte altre parti interessate al progetto (ad esempio a metà del progetto viene scoperto un progetto simile in un'area diversa, e i sottosistemi comuni devono essere centralizzati / condivisi - questo mi è successo a metà tra 2 anni progetto risultante in una grande re-architeching).

• Gli sponsor aggiuntivi del progetto hanno nuovi requisiti per le specifiche (uno degli esempi più famosi è la storia dello sviluppo di Bradley Fighting Vehicle).

Per quanto riguarda il motivo per cui le modifiche alle specifiche hanno effetti negativi (non puoi dire "non deve accadere" poiché, come puoi vedere, ci sono molte ragioni per cui fanno, quasi tutte al di fuori del tuo controllo e molte per una buona ragione) -

• Le modifiche alle specifiche provocano modifiche al codice, distraendoti dal completare le parti del progetto che non sono ancora state scritte (come tutti sappiamo, ed evangelizzate da Joel Spolsky, le modifiche al focus sono pessime per gli sviluppatori)

• Alcune modifiche alle specifiche (a volte apparentemente MOLTO minori) potrebbero comportare la necessità di riprogettare completamente / re-progettare il sistema poiché è stata scelta una scelta tra 2 architetture basata su un'ipotesi presa dalle specifiche .

• In caso di TDD, una grossa parte di lavoro messo in prova potrebbe essere annullata.

• Se i cambiamenti delle specifiche provengono da altre parti interessate, come indicato sopra, potrebbero essere in contraddizione con le specifiche esistenti, con conseguente riduzione significativa della qualità del prodotto (vedi Fighting Vehicle, Bradley).

• La modifica delle specifiche potrebbe violare alcuni requisiti aziendali esistenti che potrebbero essere stati ignorati dal modificatore o dal richiedente / gestore (questo è in realtà lo stesso dell'ultimo punto elenco).

Ciò che tutto ciò equivale a è ovviamente una data di consegna estesa (talvolta significativa) del progetto e potenzialmente una maggiore probabilità di difetti.

Per il miglior esempio di come un piccolo cambiamento nelle specifiche possa creare problemi estremi, ho 3 lettere per te:

Y2K.

Tutto ciò che hanno fatto è stato modificare le specifiche per dire " deve funzionare dopo l'anno 2000 ".

Inoltre, in alcune situazioni è effettivamente il caso che la specifica DEVE non cambi (al contrario di "non dovrebbe cambiare senza una buona ragione"):

• Una parte della specifica è (o dipende da) una specifica di un sistema esterno che deve essere interfacciato con.

• Una parte della specifica è (o dipende da) un hardware su cui il sistema è implementato.

• Requisiti del contratto con un client (anche se la limitazione è strettamente legata alla modifica delle specifiche senza utilizzare prima le modifiche con il client e la modifica del contratto, anziché il semplice fatto della modifica)

• Un sistema potrebbe dover soddisfare specifici requisiti legali o normativi indipendentemente dalle preferenze del cliente. Esempi: crittografia della carta di credito, protezione dei dati fiscali.

Proibire modifiche alle specifiche durante lo sviluppo è ideale per il programmatore, ma non è realistico in un contesto reale. Le persone vorranno sempre apportare modifiche, anche quando la cosa sta uscendo fuori dalla porta. Non si ferma mai. E alcune di quelle persone potrebbero firmare il tuo stipendio. Più a loro importa, più ci pensano, e quindi più spesso vogliono rivedere il design. Devi essere in grado di tollerare la modifica del design prima del completamento, anche se significa ricominciare da capo.

L'importante è comunicare chiaramente le conseguenze dei cambiamenti in modo che tutti abbiano aspettative realistiche sul processo di progettazione.

Le modifiche devono essere discusse in modo appropriato e la persona responsabile della cosa deve avere una chiara comprensione dell'impatto che i cambiamenti avranno sulla data di consegna. Per ottenere ciò, deve parlare con lo sviluppatore. Tuttavia, poiché una discussione in corso sui cambiamenti inonderà lo sviluppatore e impedirà il verificarsi di un vero lavoro, le modifiche dovranno essere accodate e discusse a intervalli pianificati e non frequenti. Questo è ciò che speri, naturalmente.

Idealmente, istruisci le persone a prendere nota delle modifiche che vogliono apportare e invitali a farlo durante la riunione di coordinamento settimanale / bisettimanale / mensile / qualsiasi. Durante la riunione viene discussa ogni richiesta di modifica, compresa una discussione sulle modifiche che dovranno essere apportate per implementare la funzionalità richiesta, e quindi l'effetto sulla data di completamento. Una volta stabilito il "costo" del cambiamento, possono decidere se includerlo o meno.

La cosa importante che questo processo introduce è la nozione che ogni cambiamento ha un costo associato, e il costo è generalmente più alto, più il progetto è progredito, dal momento che è necessario duplicare più lavoro. Le persone che non lavorano in sviluppo di solito non hanno idea di quanto costerà un cambiamento; l'unico modo per loro di dire è di proporlo e valutare la tua reazione. La creazione di un processo di revisione delle modifiche ben definito aiuterà sia loro che voi.

Nota che i programmatori tendono ad essere estremamente ottimisti riguardo alla facilità con cui un cambiamento deve fare, o estremamente pessimisti su quanto sarà impossibile farlo. Cerca di capire cosa sei confrontando le stime originali con i risultati e aggiustalo di conseguenza.

Forse sarebbe meglio dire che le specifiche non devono cambiare senza una richiesta e un processo di modifica validi. Richiedere una modifica delle specifiche ha effetti sulla pianificazione e sui costi, quindi questi devono essere presi in considerazione nell'approvazione.

Dato che esiste un adeguato processo di gestione delle modifiche, non c'è nulla di "sbagliato" nel cambiare le specifiche, ma è probabile che sia molto costoso, quindi i tuoi clienti potrebbero non essere troppo felici. Puoi proteggerli da soli cercando di ottenere alcuni buoni requisiti e specifiche in anticipo, in modo che siano necessarie meno modifiche.

La migliore analogia che ho è di confrontarla con la costruzione di una casa. L'architetto elabora i piani, quindi fornisce una stima, quindi il cliente accetta (o meno) il piano. Se il cliente desidera un ulteriore bagno inserito, il lavoro si interrompe, i piani devono essere modificati, viene eseguita una nuova stima e il cliente accetta (o meno).

Il software di scrittura non è diverso. una volta che l'accordo è stato fatto (dopo la progettazione e la stima), allora se c'è bisogno di cambiamenti, allora il lavoro deve smettere di essere in grado di fare un nuovo piano, una nuova stima quindi ottenerli approvati (o meno) e poi riprendere il lavoro.

ovunque dicessi o no significa che il progetto va avanti senza le nuove modifiche. Ovviamente c'è sempre tempo e materiale per elaborare nuovi piani e stimare.