Come impedire che le specifiche di sviluppo cambino a metà sviluppo?

Problema : sembra che con quasi tutti gli sforzi di sviluppo in cui sono coinvolto, indipendentemente dal tempo impiegato nella pianificazione prima di iniziare lo sviluppo, ci sono sempre molte modifiche necessarie a metà strada o verso la fine del progetto. Questi sono a volte grandi cambiamenti che richiedono un sacco di ri-sviluppo.

Non lavoro per clienti che pagano soldi, questo è un team di sviluppo interno su siti Web di sviluppo interni. Quindi, non è che posso farcela o altro. E alla fine, dobbiamo cercare di rispettare le scadenze.

Domande : quali sono alcuni dei modi migliori in cui voi ragazzi avete trovato per ridurre al minimo e impedire che le modifiche alle specifiche vengano interrotte a metà strada o dopo lo 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 cambiata - a meno che tu non possa predire il futuro e leggere le menti degli stakeholder (anche se potrebbero non aver ancora preso la loro decisione, anche se affermano di averlo fatto). Suggerirei invece di affrontarlo in diversi modi:

1. Fai una chiara distinzione su cosa può essere cambiato e cosa no. Comunicalo chiaramente agli stakeholder, fai in modo che firmino esplicitamente cose immutabili il prima possibile.
2. Preparare la modifica in anticipo. Utilizzare metodologie di codice che consentano di modificare più facilmente le parti sostituibili, investire in configurabilità, incapsulamento e protocolli chiari che consentano di modificare e sostituire le parti in modo indipendente.
3. Parla spesso con le parti interessate, sollecita feedback e approvazione. Ciò ti terrebbe entrambi sincronizzato ed eviterebbe che affermino "oh, non è quello che volevamo" quando è troppo tardi. Come notato in altre risposte, metodologie agili e frequenti mini-release ti aiuterebbero in questo.
4. Inserisci nel programma il tempo per accogliere le inevitabili modifiche. Non abbiate paura di dire "avremo bisogno di più tempo" in anticipo se pensate di farlo - se il programma che vi viene dato è irrealistico, è meglio conoscerlo (e farlo registrare sul disco) all'inizio che a fine.
5. Se i cambiamenti sono troppo estesi e minacciano la scadenza - respingi e dì qualcosa come "questo cambiamento è possibile, ma spingerà la scadenza di X tempo, fai la tua scelta".
6. Effettuare un processo formale di richiesta delle modifiche, assegnazione delle priorità alle modifiche e assegnazione delle modifiche alle versioni o alle versioni. Se potessi dire alla gente "Non posso farlo in questa versione, ma saremo felici di metterlo nei tempi previsti per il prossimo", è molto meglio che dire loro "sei troppo tardi, il tuo cambiamento non può entrare , arrivederci "e li renderebbe tuoi amici - sarebbero felici che tu rilasci in tempo, così potresti essere libero prima di arrivare alla prossima versione che avrà il loro cambiamento - e non il tuo nemico.

Consegnare qualcosa (esito a usare qualsiasi parola) in anticipo e consegnare spesso. Cioè - usa una sorta di metodologia di sviluppo iterativo.

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

Scomponendo il progetto in una serie di mini progetti ottieni un maggiore controllo in quanto puoi mettere qualcosa di fronte al cliente in anticipo, non sei bloccato in un lungo programma di sviluppo che diventa obsoleto quando il cliente cambia idea (come lo faranno).

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

La teoria secondo cui è possibile specificare completamente un progetto software di qualsiasi dimensione significativa è una fantasia completa. Si è scoperto che questa teoria non funziona in organizzazioni di grandi e piccole dimensioni praticamente per l'intera storia dello sviluppo del software.

DEVI trovare un modo per accogliere le modifiche mentre procedi! Succederanno, perché la maggior parte delle parti interessate, anche se dicono "sì, è quello che voglio" in realtà non hanno idea di ciò che vogliono fino a quando non è davanti a loro. Ecco perché abbiamo così tante persone che adottano metodi iterativi.

Sia che tu esegua l'iterazione del prodotto o qualsiasi altra cosa, DEVI trovare un modo per far fronte a questi cambiamenti, perché cercare di trovare modi per non apportare modifiche non è sufficiente chiedere alla gravità di spegnersi per qualche minuto in modo da poter volare.

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

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

Spesso è perché i requisiti aziendali cambiano, ma l'ho anche visto accadere perché i clienti (interni o esterni) possono avere difficoltà a visualizzare ciò che è possibile senza vedere qualcosa da cui iterare, quindi hanno una visione che cambia lentamente mentre interagiscono con 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 poi nell'arena del bingo di parole d'ordine: metodologie agili, sviluppo iterativo e soluzioni tecniche come la codifica basata su componenti / modulari, l'integrazione continua ... l'elenco continua.

Non sto dicendo che si tratta di una pallottola d'argento per tutti i tuoi problemi, ma sono nati tutti per il desiderio di gestire la situazione che stai descrivendo, per cui vale la pena investigare.

Scusate se non offre soluzioni concrete, ma tendo a pensare che un cambiamento di mentalità nell'accettare e gestire il cambiamento pagherà dividendi maggiori rispetto al tentativo di evitarlo.

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

Suggerirei di pensare a:

• da dove vengono questi cambiamenti comunque?
• perché non ne sei a conoscenza prima?
• perché non stai contribuendo a questi cambiamenti (e potenzialmente rendendone ancora di più)?

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

Ma se vuoi evitare di essere perennemente lo sviluppatore frustrato "sorpreso" dai cambiamenti, penso che devi trovarti molto più vicino all'azione di dove vengono prese le decisioni. Dopotutto, sono sicuro che hai un sacco di idee su come migliorare il prodotto. Accomodati al tavolo o accetta per sempre che dovrai solo affrontare questi "cambiamenti a sorpresa".

Bene, questa è una telefonata, i clienti vogliono sempre di più, ma qui ci sono alcuni punti che dovresti considerare:

Mock-up HTML: crea sempre modelli Mock-up HTML per definire la parte dell'interfaccia utente di un'applicazione, mostrare loro come sarà e chiedere loro le loro opinioni. Se trovi qualcosa di ragionevole da modificare, fallo accadere nel prototipo HTML. Usando questo risolverai molte cose come problemi di interfaccia utente, flusso di base e alcuni componenti aggiuntivi (come ordinamento, paginazione, numero di record da visualizzare ecc.)

Partecipazione attiva dall'altra parte: questo è molto importante se si sta sviluppando per un'organizzazione aziendale, entrare nella propria attività, chiedere loro di chiarire i propri dubbi e chiedere loro quali cambiamenti vogliono nel loro flusso (se necessario).

Rilascio modulare: rilasciare il codice in modo modulare, rilasciare, testare, ricevere feedback e rilasciare di nuovo.

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 che ti spezzino il cuore.

All'interno della tua azienda c'è un costo per l'utilizzo delle risorse IT indipendentemente dal fatto che qualcuno lo ammetta, lo segua o debba preventivare un budget. La realtà è che il tuo team può creare così tanto codice in un certo periodo di tempo. Tutti i dipartimenti e i progetti condividono questo budget.

Non puoi impedire a nessuno di voler cambiare i requisiti, ma non possono sfuggire alle conseguenze. Le modifiche possono aumentare significativamente i tempi di sviluppo. È un dato di fatto che devono affrontare o decidere di non apportare il cambiamento. Una richiesta di un dipartimento influisce su un altro? Potrebbe essere necessario spostare completamente il progetto dietro altri reparti perché la richiesta di modifica si sovrapporrà alla pianificazione temporale di un altro gruppo.

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

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

Per me è abbastanza facile.
Dì a quello, il "Product owner" , che ha ordinato le funzionalità che questo è OK, ma deve scegliere un paio di funzionalità pianificate che potrebbe essere senza questa scadenza.
Pensalo come un incontro di mezzo sprint con l'OP in cui gli dici che lo sprint non brucerà fino a 0.

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

Quali sono alcuni dei modi migliori in cui voi ragazzi avete trovato per ridurre al minimo e impedire che le modifiche alle specifiche vengano interrotte a metà strada o dopo lo sviluppo?

Non ci sono modi migliori. Spetta al management limitare le modifiche alle specifiche nella determinata fase dello sviluppo.

Tuttavia, è necessario progettare il software in modo tale da prevedere 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 bug più critici, BTW). Quindi la soluzione ovvia è eliminare i clienti. (A che servono comunque?)

Dal momento che non puoi impedire il cambiamento, devi abbracciarlo. Penso che la cosa più importante che puoi fare sia: devi cercare di ottenere le richieste di modifica dal cliente il prima possibile , perché è meno costoso cambiare le cose quando c'è solo poco codice. Quindi è necessario presentare il proprio progetto il prima possibile al cliente utilizzando prototipi (forse anche un prototipo cartaceo), 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 o giorni di lavoro necessari per implementare quella storia).

Se è richiesta una modifica tardiva (per una storia che è già stata implementata) è necessario creare una nuova storia e stimare lo sforzo di implementazione per essa. Quindi puoi andare dal tuo manager (il proprietario del prodotto ) e semplicemente spiegare che la nuova funzionalità costerà quel tempo extra. Il project manager ha quindi la responsabilità di accettare lo sforzo extra e di adeguare il programma (eventualmente cancellando altre storie non ancora implementate).

Anche se il tuo team non implementerà completamente SCRUM o un altro processo di sviluppo, potresti almeno introdurre la pianificazione basata su storie , stimare lo sforzo di sviluppo per ogni storia e adattare il programma quando vengono richieste nuove storie.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Ho trascorso troppe serate dopo il lavoro stressate e infelici perché un altro tipo non capisce o si preoccupa di come funziona il business del software. Non ho problemi a confrontarmi con qualcuno più in alto, ma non ho il sostegno dei miei compagni 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 soldi, questo è un team di sviluppo interno sui siti Web di sviluppo interni. Quindi, non è come se potessi pagare per questo o altro. E alla fine, dobbiamo cercare di rispettare le scadenze. "" "

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

Nel frattempo, tentare di rispettare le scadenze provoca a te e ai tuoi colleghi UNNECESSARIO stress; non puoi trascorrere un fine settimana di qualità con amici / famiglia. In realtà non è necessario, perché chiunque ti sta lanciando il lavoro probabilmente non lo sa nemmeno, il che è triste.

La mia soluzione proposta: collettivamente avere le palle per affrontarle e spiegare che non c'è pranzo libero e tutto ha un costo, che un meccanico dovrebbe impiegare più tempo e caricare di più se le specifiche fossero cambiate a metà lavoro, che un'agenzia contraente impiegherebbe più tempo e caricare di più se le specifiche fossero cambiate durante il lavoro e c'è una buona ragione per farlo. Se non sono disposti a lavorare con voi in modo ragionevole, allora come gruppo vi alzerete e andrete via, e dovranno assumere sviluppatori che possano riprendere il progetto da dove era stato interrotto e consegnare in tempo.

Quindi c'è anche una promessa di sviluppo agile, che non implica scadenze rigide.

Devo ancora vedere i programmatori scioperare, ma questo sarebbe stato qualcosa. I gestori incompetenti sono troppo numerosi nelle società di software. Troppe persone vogliono ottenere qualcosa per niente, su Craigslist o all'interno di un'azienda reale. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

I programmatori devono avere più palle.

Un approccio che ho scoperto che funziona in un certo senso OK (non con tutti i manager ovviamente) è "Penso di poterlo fare, sì. Dipende da quanto tempo extra stai assegnando a questo progetto? È un cambiamento abbastanza importante richiedente."