Come funziona agile quando si sostituisce un sistema funzionante?

La soluzione agile potrebbe essere not per sostituire tutto in un colpo solo, ma per eliminare gradualmente la sostituzione.

Introduci gradualmente il nuovo sistema, bit a bit, mantenendo attive le parti del vecchio sistema. Il vecchio sistema non viene spento tutto in una volta, ma svanisce. Le nuove parti offrono nuove funzionalità o altri vantaggi, quindi gli utenti sono felici di utilizzarli. Anche questo è meno rischioso, dato che hai sempre un sistema operativo al 100%.

• Ulteriori informazioni su Martin Fowler .
• Le strategie di di Michael Feather in vigore con il codice legacy possono essere utili

Piuttosto che riscrivere il sistema esistente (che come hai detto richiederà un po 'di sforzo prima che il nuovo sistema corrisponda alle funzionalità esistenti), considera strangolare vite approccio. Fondamentalmente, implementa nuove funzionalità utilizzando il tuo nuovo approccio in cima a l'applicazione esistente. Alla fine, mentre affronti le carenze del vecchio sistema per affrontare nuove funzionalità, il nuovo codice sostituirà completamente il vecchio.

Ciò richiede più precisione e impegno rispetto a un "riavvio" della vecchia app. Ma hai un tempo più breve per il ROI. Inoltre, durante il processo, puoi mettere i ganci in posizione per consentire al nuovo sistema di essere più facilmente strangolato dal prossimo "nuovo" sistema.

Il rilascio di piccoli incrementi nel mondo potrebbe funzionare per progetti greenfield, ma anche in questo caso il numero limitato di funzionalità potrebbe non essere troppo utile.

Scrum sostiene che dopo ogni sprint il prodotto è "Potenzialmente spedibile". Non deve essere spedito ma deve avere la qualità di un prodotto che può essere spedito.

Se vuoi offrire agli utenti una versione incrementale dell'app, puoi classificarla come Alfa, poi Beta e poi Release Candidate mentre ancora stai utilizzando la vera app di produzione.

Potresti scoprire che le nuove funzionalità vengono aggiunte e quelle precedenti vengono eliminate se stai incorporando il feedback degli utenti.

Continuo a pensare che l'agilità aggiunga molto valore in questo scenario.

È solo che hai un obiettivo finale ben definito di "sostituire il sistema attuale"

Tecniche e processi agili possono ancora farti arrivare in modo più efficace.

Ad esempio:

Puoi ancora consegnare sul sistema in modo iterativo e in piccoli sprint.

Puoi comunque utilizzare tecniche agili per dare priorità al lavoro dopo aver comunicato con le persone chiave.

Puoi ancora usare agile per pianificare in base alla velocità osservata.

Puoi comunque usare tecniche e filosofie agili come la diffusione di conoscenza, TDD, codice pulito per migliorare la qualità e la progettazione interna del progetto.

Se hai persone che sono sinceramente "non interessate" al progetto e non impegnate nel progetto fino a quando non hanno una sostituzione perfetta, hai un problema più grande a prescindere dal fatto che tu stia utilizzando cascata, agile o addirittura qualsiasi processo.

Ho lavorato a una massiccia linea di sostituzione di applicazioni aziendali per una grande rete nazionale di tv via cavo. Il nuovo sviluppo del sistema è stato fatto con SCRUM, si trattava di un progetto di sviluppo di 18-24 mesi per implementare quasi tutti i principali sottosistemi; che si stavano avvicinando a 10 anni.

C'è stata una fase di pianificazione di circa 6 mesi prima dell'inizio dello sviluppo, ma è stata affrontata anche come SCRUM. È qui che il proprietario del prodotto ha scritto negozi ed epop di alto livello dopo l'analisi del sistema esistente e intervistando i clienti.

Il sistema esistente era estremamente stabile in modalità di manutenzione critica; mostra solo che i problemi relativi ai fermi sono stati corretti, tutto è stato appena registrato per scopi storici e per assicurarsi che gli stessi problemi non siano stati visualizzati nel nuovo sistema.

Il nuovo sistema si è evoluto come descritto in un processo Agile, è stato estremamente fluido per la maggior parte. Quando il sistema di sostituzione ha raggiunto la funzionalità, non è entrato in produzione, ma in prove di produzione parallele. Un sottoinsieme di lavoratori non critici ha iniziato a utilizzare entrambi i sistemi per verificare che il nuovo sistema si sia comportato come quello vecchio; con i vecchi bug corretti, naturalmente.

Quando il nuovo sistema ha raggiunto quasi il 100% di nuove funzionalità complete, è stato implementato per le sessioni di produzione parallela generale, che sono durate un paio di mesi.

Una volta che il cliente ha ritenuto che soddisfano le loro esigenze, il vecchio sistema è stato sottoposto a backup, spento e sat. Presumo che abbiano riutilizzato il vecchio hardware di sistema perché non hanno mai avuto bisogno di tornare al vecchio sistema dopo il taglio.

Se ho una vecchia macchina arrugginita che ho bisogno di guidare per andare al lavoro, e vado al concessionario per acquistare una nuova auto. Il modello che voglio è esaurito, quindi devono ordinarlo dalla fabbrica e ci vorrà un po 'prima che arrivi.

Il rivenditore, quindi, in buona fede, decide di consegnarti il blocco motore delle auto fino a quando l'auto che hai ordinato è entrata. Che cosa dovresti fare con un motore di un'auto? Certo, posso collegare alcuni componenti per testarlo e farlo funzionare, ma in realtà non aiuta a farmi lavorare domani dove fa la vecchia macchina arrugginita.

Certo, c'è un grido lontano diverso tra la costruzione di un'auto e la creazione di software personalizzato, ma ignoriamolo per ragioni di discussione. Il punto della trama non è perplesso sul fatto che il client non trovi alcuna utilità per le modifiche incrementali quando hanno già un software che è abbastanza buono per portare a termine il lavoro. Riempie già il loro bisogno per il momento.

Questo non vuol dire che Agile non sia una parte importante del processo qui perché consente un feedback continuo al cliente sullo stato del progetto. Possono garantire che vengano fatti progressi prima di importanti traguardi e risultati. Possono identificare potenziali problemi e problemi prima che diventi un errore troppo costoso da risolvere.

Forse come cliente dell'auto, vuoi solo guardare e valutare il motore per assicurarti che otterrai effettivamente ciò che ti aspettavi. Oops, in realtà volevo un motore a 6 cilindri invece del motore a 4 cilindri! Non te l'ho detto prima? Nessun problema, lascia un cambio nell'ordine di fabbrica.

Vendete l'idea ai clienti che è nel loro interesse utilizzare le nuove versioni del software non come sostituzione, ma valutarlo e assicurarsi che siano soddisfatti di ogni passo lungo il percorso.

Funziona allo stesso modo, ma questo approccio sarà più difficile da vendere agli utenti esistenti. Potrebbero non volere il nuovo sistema e non vogliono essere interrotti con test periodici. Vogliono aspettare il più a lungo possibile e poi basta testarlo alla fine. La maggior parte degli utenti si sente in questo modo in una certa misura, ma spetta ai responsabili educarli. Nella loro mente, stai lavorando con un'applicazione esistente, quindi dovresti sapere cosa si suppone di fare, perché infastidirli?

Fai capire che non vuoi farlo in questo modo perché pensi che sarà divertente e ti sentirai solo usando un processo a cascata. A lungo andare farà un'app migliore.

Un punto chiave di vendita potrebbe essere quello di implementare quell'unica modifica durante la creazione della nuova app che hanno sempre desiderato, ma che non potrebbero mai entrare nel vecchio sistema.