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

Voglio spiegare perché le specifiche non devono essere modificate durante il periodo di sviluppo al nuovo impiegato del dipartimento di pianificazione.

Una specifica cambia quasi sempre durante lo sviluppo per qualsiasi progetto tranne il più semplice.

Le ragioni sono:

• Lo sviluppo o più probabilmente i test di integrazione del progetto scoprono cose non notate quando sono state fatte le specifiche originali, dai casi limite alle sfaccettature principali. Ad esempio, lo sviluppatore nota che potrebbero arrivare conferme di messaggi fuori servizio.

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

• Le pressioni di scadenza comportano la potatura delle funzionalità.

• Vengono scoperte ulteriori parti interessate al progetto (ad es. A metà del progetto viene scoperto un progetto simile in un'area diversa e i sottosistemi comuni devono essere centralizzati / condivisi - questo è successo a me durante il progetto di 2 anni, con conseguenti importanti architeching).

• Ulteriori sponsor del progetto hanno nuovi requisiti di specifica (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 si può dire "non deve accadere" poiché, come puoi vedere, ci sono molte ragioni per cui lo fanno, quasi tutte al di fuori del tuo controllo e molte per una buona ragione) -

• Le modifiche alle specifiche comportano modifiche al codice, che ti distraggono dal completamento delle parti del progetto che non sono ancora state scritte (come tutti sappiamo ed evangelizzati da Joel Spolsky, i cambiamenti di messa a fuoco sono molto negativi per gli sviluppatori)

• Alcune modifiche alle specifiche (a volte apparentemente MOLTO minori) potrebbero comportare la necessità di riprogettare / riprogettare completamente il sistema poiché una scelta tra 2 architetture è stata fatta sulla base di un presupposto preso dalle specifiche .

• In caso di TDD, un grosso pezzo di lavoro messo alla prova potrebbe essere annullato.

• Se le modifiche alle specifiche provengono da ulteriori parti interessate, come indicato sopra, potrebbero essere contraddittorie rispetto alle 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 il commutatore / richiedente potrebbe non essere a conoscenza o curato (questo è davvero lo stesso dell'ultimo punto elenco).

Ciò che equivale a tutto ciò è ovviamente esteso (a volte in modo significativo) data di consegna del progetto e potenziale aumento della 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 è vero che la specifica NON DEVE cambiare (al contrario di "non dovrebbe cambiare senza una buona ragione"):

• Parte delle specifiche è (o dipende da) una specifica di un sistema esterno che deve essere interfacciato.

• Parte delle specifiche è (o dipende da) un hardware su cui è implementato il sistema.

• Requisiti del contratto con un cliente (sebbene la limitazione sia strettamente parlando di cambiare le specifiche senza lavorare prima con le modifiche con il cliente e cambiare il contratto, al contrario del semplice fatto della modifica)

• Potrebbe essere necessario che un sistema soddisfi specifici requisiti legali o normativi, indipendentemente dalle preferenze del cliente. Esempi: crittografia con carta di credito, protezione dei dati fiscali.

Proibire modifiche alle specifiche durante lo sviluppo è l'ideale per il programmatore, ma non è realistico in un ambiente reale. Le persone vorranno sempre apportare modifiche, anche quando la cosa viene spedita fuori dalla porta. Non si ferma mai. E alcune di quelle persone potrebbero firmare la busta paga. Più si preoccupano, più ci pensano e quindi più spesso vogliono rivedere il design. Devi essere in grado di tollerare la modifica del progetto prima del completamento, anche se ciò 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 adeguatamente discusse e il responsabile della cosa deve avere una chiara comprensione dell'impatto che le modifiche avranno sulla data di consegna. Per ottenerlo, deve parlare con lo sviluppatore. Tuttavia, poiché una discussione in corso sulle modifiche inonderà lo sviluppatore e impedirà che si verifichi qualsiasi lavoro reale, le modifiche devono essere messe in coda e discusse a intervalli pianificati e poco frequenti. Questo è quello che speri, ovviamente.

Idealmente, istruisci le persone a prendere nota delle modifiche che desiderano apportare e a farle conoscere nella riunione di coordinamento settimanale / bisettimanale / mensile / qualunque. Durante l'incontro viene discussa ogni richiesta di modifica, inclusa una discussione sulle modifiche sottostanti che dovranno essere apportate per implementare la funzione richiesta, e quindi l'effetto sulla data di completamento. Una volta stabilito il "costo" della modifica, è possibile determinare se includerla o meno.

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

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

Forse sarebbe meglio dire che la specifica non deve cambiare senza una richiesta di modifica valida ed elaborazione. La richiesta di una modifica delle specifiche ha effetti sulla pianificazione e sui costi, quindi questi devono essere presi in considerazione nell'approvazione.

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

La migliore analogia che ho è quella di confrontarla con la costruzione di una casa. L'architetto elabora i piani e poi presenta un preventivo, il cliente accetta quindi (o meno) il piano. Se il cliente desidera un bagno aggiuntivo, il lavoro si interrompe, i piani devono cambiare, viene fatto un nuovo preventivo e il cliente accetta (o no).

La scrittura di software non è diversa. una volta che l'accordo è stato stipulato (dopo la progettazione e la stima), quindi se è necessario apportare modifiche, il lavoro deve essere interrotto per poter elaborare un nuovo piano, una nuova stima quindi farli approvare (o meno) e quindi riprendere il lavoro.

ovunque abbia detto o meno significa che il progetto va avanti senza le nuove modifiche. Naturalmente c'è sempre il tempo e i materiali per elaborare nuovi piani e stime.