Come impedire alle specifiche di sviluppo di cambiare a metà sviluppo?

C'è un famoso detto militare, attribuito a Helmut von Moltke: "Nessun piano di battaglia sopravvive al contatto con il nemico". Allo stesso modo, non penso che sia possibile fare una specifica che non dovrà essere modificata, a meno che non si possa predire il futuro e leggere le menti degli stakeholder (anche allora potrebbero non aver ancora fatto la loro idea, anche se affermano di averlo fatto). Suggerirei invece di affrontarlo in vari modi:

1. Fai una chiara distinzione su cosa può essere cambiato e cosa no. Comunicalo in modo chiaro agli stakeholder, falli accettare esplicitamente su cose immutabili il prima possibile.
2. Preparati per il cambio in anticipo. Utilizzare metodologie di codice che consentono di modificare più facilmente le parti modificabili, investire in configurabilità, incapsulamento e protocolli chiari che consentano la sostituzione e la sostituzione indipendente delle parti.
3. Parla spesso con gli stakeholder, sollecita feedback e approvazione. Questo ti terrebbe in sincronia ed eviterebbe di dire "oh, non è quello che volevamo" quando è troppo tardi. Come notato in altre risposte, metodologie agili e mini-rilasci frequenti ti aiuteranno in questo.
4. Inserisci nel programma il tempo per adeguarsi agli inevitabili cambiamenti. Non aver paura di dire "avremo bisogno di più tempo" presto se pensi che lo faresti - se il programma che ti viene dato è irrealistico, è meglio saperlo (e hai già annotato il record) all'inizio la fine.
5. Se i cambiamenti sono troppo estesi e minacciano la scadenza - respingi indietro e dì qualcosa come "questo cambiamento è possibile, ma spingerai la scadenza entro il tempo X, fai la tua scelta".
6. Esegui un processo formale per richiedere modifiche, assegnare priorità alle modifiche e assegnare modifiche a versioni o versioni. Se potessi dire alla gente "Non posso farlo in questa versione, ma sarò felice di metterlo in programma per il prossimo", è molto meglio che dirgli "sei troppo tardi, il tuo cambiamento non può andare in , addio "e li renderebbe tuoi amici - sarebbero felici che tu ti liberassi in tempo così che tu possa essere libero prima di arrivare alla prossima versione che avrà il loro cambiamento - e non il tuo nemico.

Consegna qualcosa (esita a usare la parola qualsiasi) presto e consegna spesso. Cioè: usa una sorta di metodologia di sviluppo iterativa.

Questa è la base dello sviluppo Agile, ma può essere utilizzata con (quasi) qualsiasi metodologia.

Rompendo il progetto in una serie di mini progetti si ottiene un maggiore controllo in quanto è possibile mettere qualcosa di fronte al cliente in anticipo, non si è bloccati in un lungo programma di sviluppo che diventa obsoleto quando il client cambia la propria mente (come faranno).

Quando vedono il sistema evolvere, alcuni requisiti cambieranno, alcuni diventeranno ridondanti e altri aumenteranno in priorità. Tuttavia, avendo un breve ciclo di vita del progetto sarete in grado di far fronte a questi cambiamenti.

La teoria che sia possibile specificare completamente un progetto software di qualsiasi dimensione significativa è una fantasia completa. Questa teoria è stata trovata non funzionare in organizzazioni da grandi a piccole per quasi tutta la storia dello sviluppo del software.

DEVI trovare un modo per sistemare le modifiche mentre vai! Stanno per accadere, perché la maggior parte degli stakeholder, anche se dicono 'sì, è quello che voglio', in realtà non hanno idea di cosa vogliono fino a quando non è davanti a loro. Ecco perché abbiamo così tante persone che adottano metodi iterativi.

Sia che tu stia iterando il prodotto o qualsiasi altra cosa, devi trovare un modo per tener conto di questi cambiamenti, perché cercare di trovare modi per non avere cambiamenti è solo chiedere alla gravità di spegnersi per qualche minuto in modo da poter volare.

Non cercare di impedire il cambiamento, abbracciarlo . Più pianifichi in anticipo, più è probabile che il tuo piano cambi. Quindi, pianifica meno , non di più. Adotta una metodologia di sviluppo agile in cui consegna frequentemente piccoli pezzi di codice di lavoro, dando al cliente la possibilità di modificare le specifiche ogni due settimane.

Stai facendo la domanda sbagliata. Le modifiche alle specifiche verranno sempre in progetti di sviluppo software di qualsiasi dimensione.

Spesso è perché i requisiti aziendali cambiano, ma ho anche visto accadere perché i clienti (interni o esterni) possono trovare difficoltà a visualizzare ciò che è possibile senza vedere qualcosa da cui iterare, quindi hanno una visione che cambia lentamente mentre impegnarsi con la soluzione in via di sviluppo.

La domanda che dovresti porre non è "come posso bloccare le specifiche", è "come posso strutturare il mio codice e i miei processi per rispondere a un ambiente che cambia senza buttare via tutto ciò che ho già scritto?"

Questo ti porta quindi nell'arena del bingo delle buzzword: metodologie agili, sviluppo iterativo e soluzioni tecniche come la codifica modulare / basata su componenti, l'integrazione continua ... la lista continua.

Non sto dicendo che questi sono una pallottola d'argento per tutti i tuoi problemi, ma sono venuti tutti a causa del desiderio di gestire la situazione che stai descrivendo, per cui valgono almeno qualche indagine.

Scusa se questo non offre soluzioni concrete, ma tendo a pensare che un cambiamento di mentalità nell'accettare e gestire il cambiamento pagherà dividendi più consistenti che cercare di evitarlo.

Un cambiamento è solo una sorpresa ... se è una sorpresa!

Suggerirei di pensare a:

• dove diavolo vengono fatti questi cambiamenti?
• perché non ne sei a conoscenza prima?
• perché non contribuisci a queste modifiche (e potenzialmente ne fai ancora di più)?

Il cambiamento è la natura di ciò che facciamo. Da quando hai codificato un algoritmo esattamente come previsto il giorno 1?

Ma se si vuole evitare di essere perennemente lo sviluppatore frustrato "sorpreso" dai cambiamenti, penso che sia necessario avvicinarsi all'azione di dove vengono prese le decisioni. Dopo tutto, sono sicuro che hai un sacco di idee su come potresti migliorare il prodotto. Prendi posto a un tavolo, o accetti per sempre che dovrai solo affrontare quei "cambiamenti a sorpresa".

Questa è una chiamata, i clienti vogliono sempre di più, ma qui ci sono alcuni aspetti da considerare:

Mock-up HTML: crea sempre mock up HTML per definire la parte dell'interfaccia utente di un'applicazione, mostrale come sarà e chiedi loro le loro opinioni. Se trovi qualcosa di ragionevole da cambiare, fallo nel prototipo HTML. Usando questo si risolvono un sacco di cose come problemi di interfaccia utente, flusso di base e alcune aggiunte (come l'ordinamento, l'impaginazione, il numero di record da visualizzare ecc.)

Partecipazione attiva dall'altra parte: Questo è molto importante se si sta sviluppando per un'organizzazione aziendale, si entra nel proprio business chiedendo loro di chiarire i propri dubbi e senza esitazioni chiedere loro quali cambiamenti vogliono nel loro flusso (se necessario).

Versione modulare: pubblica il tuo codice in modo modulare, rilascia, verifica, accetta feedback e rilascia nuovamente.

Ecco perché è quasi impossibile pianificare troppo in anticipo, ma non una scusa per non pianificare affatto. Non innamorarti troppo dei tuoi piani e non dovrai preoccuparti di ciò che ti spezza il cuore.

All'interno della vostra azienda vi è un costo per l'utilizzo delle risorse IT, indipendentemente dal fatto che qualcuno lo ammetta, lo tenga traccia o sia costretto a farlo o meno. La realtà è che la tua squadra può creare così tanto codice in una certa quantità di tempo. Tutti i dipartimenti e i progetti condividono questo budget.

Non puoi impedire a nessuno di voler modificare i requisiti, ma non possono sfuggire alle conseguenze. Le modifiche possono aumentare significativamente i tempi di sviluppo. Questo è un fatto che devono affrontare o decidere di non apportare il cambiamento. Una richiesta da un dipartimento ne influenza un'altra? Potrebbe essere necessario spostare completamente il progetto dietro altri reparti perché la richiesta di modifica invaderà la pianificazione temporale di un altro gruppo.

Il coinvolgimento attivo degli utenti durante tutto il ciclo di sviluppo e l'utilizzo della massima metodologia Agile ci aiuta davvero con i nostri prodotti.

Le modifiche alle specifiche sono inevitabili, ma essendo trasparenti con gli utenti e soprattutto consultandoli frequentemente significa che la maggior parte delle modifiche vengono acquisite il prima possibile.

Per me è abbastanza facile.
Dillo a quello, il "proprietario del prodotto" , che ha ordinato le funzionalità che questo è OK, ma deve scegliere un paio di funzionalità pianificate che potrebbe essere senza per questa scadenza.
Pensa ad un incontro di mezza sprint con il PO dove gli dici che lo sprint non brucerà a 0.

Ps. Se è non il "PO" direi di non parlarmi passare attraverso "PO"

What are some of the best ways you guys have found to minimize and prevent spec changes from cropping up midway or after development?

Non ci sono modi migliori. È compito della direzione limitare le modifiche alle specifiche in determinate fasi dello sviluppo.

Tuttavia, dovresti progettare il tuo software in modo tale da aspettarti le modifiche. Quindi l'impatto dei cambiamenti sarebbe molto meno. Lo sviluppo iterativo e incrementale è un buon inizio.

Ho scoperto che, direttamente o indirettamente, i clienti sono la causa della maggior parte dei cambiamenti (e anche dei bachi più critici, BTW). Quindi la soluzione ovvia è eliminare i clienti. (A cosa servono comunque?)

Poiché non puoi impedire il cambiamento, devi accettarlo. Penso che la cosa più importante che puoi fare è: devi provare a ottenere le richieste di modifica dal cliente il prima possibile , perché è meno costoso cambiare le cose quando c'è solo un piccolo codice. Quindi è necessario presentare il progetto il prima possibile al cliente utilizzando prototipi (forse anche un prototipo di carta), utilizzare metodi agili e così via.

Potresti prendere in considerazione l'introduzione di una certa disciplina nel processo di sviluppo usando una metodologia come SCRUM. In SCRUM, un team fa un piano iniziale suddividendo l'implementazione delle funzionalità in storie e assegnando a ciascuna storia una stima dello sforzo (numero di ore di lavoro o giorni necessari per implementare quella storia).

Se è richiesto un cambiamento tardivo (per una storia che è già stata implementata) tu è necessario creare una nuova storia e stimare lo sforzo di implementazione per questo. Poi puoi andare dal tuo manager (il product owner ) e spiegare semplicemente che la nuova funzionalità avrà un costo aggiuntivo. Il project manager quindi ha la responsabilità di accettare lo sforzo supplementare e la regolazione il programma (eventualmente cancellando altre storie non ancora implementate).

Anche se il tuo team non implementerà completamente SCRUM o un altro sviluppo processo, potresti almeno presentare la pianificazione in base a storie , stimare lo sforzo di sviluppo per ogni storia e regolare il programma quando sono richieste nuove storie.

link

Ho trascorso troppe serate post-lavoro stressate e infelici perché l'ennesimo tizio non capisce o cura come funziona il business del software. Non ho problemi a confrontarmi con qualcuno più in alto, ma non ho il sostegno dei miei amici nerd. Avere figli è una cagna, eh? Probabilmente smetterò presto.

Francamente, vorrei che i programmatori in generale avessero più palle. Diamo un'occhiata a questo:

"" "Non lavoro per i clienti che pagano, questo è un team di sviluppo interno sui siti web di sviluppo interni, quindi non è come se potessi pagare per questo o altro. il giorno, dobbiamo cercare di rispettare le scadenze. "" "

Se tu avessi a che fare con un client $ -paying e se ti avessi coperto il culo con un contratto (http://vimeo.com/22053820?utm_source=swissmiss), le modifiche alle specifiche sarebbero costate a questo cliente più tempo E più denaro (o potenzialmente stesso o meno tempo, ma esponenzialmente più denaro). La tua azienda sta cercando di farla franca cambiando le specifiche senza incorrere nel costo di più tempo e più denaro.

Nel frattempo, provare a rispettare le scadenze fa sì che tu e i tuoi collaboratori non si sottolinei lo stress; non puoi passare un fine settimana di qualità con amici / famiglia. È davvero superfluo, perché chi ti sta lanciando il lavoro probabilmente non lo sa nemmeno, il che è triste.

La mia soluzione proposta: collettivamente abbiamo le palle per affrontarli e spiegare che non c'è il pranzo gratis e tutto è costato, che un meccanico potrebbe impiegare più tempo e pagare di più se le specifiche sono cambiate a metà del lavoro, che un'agenzia appaltatrice richiederebbe più tempo e addebitare più se le specifiche fossero cambiate a metà del lavoro, e c'è una buona ragione per questo. Se non sono disposti a collaborare con te in modo ragionevole, allora come gruppo ti alzerai e andrai via, e dovranno assumere gli sviluppatori che possono riprendere il progetto da dove erano stati interrotti e consegnare in tempo.

Poi c'è anche una promessa di sviluppo agile, che non implica scadenze difficili.

Devo ancora vedere i programmatori andare in sciopero, ma questo sarebbe stato qualcosa. I manager incompetenti sono troppo abbondanti nelle società di software. Troppe persone vogliono ottenere qualcosa per niente, su Craigslist o all'interno di una società reale. link

I programmatori devono avere più palle.

Un approccio che ho trovato che funziona in modo discreto (non con tutti i manager ovviamente) è "Penso di poterlo fare, sì. Dipende - quanto tempo extra stai assegnando a questo progetto? modifica che stai richiedendo. "