Come funziona l'agile quando si sostituisce un sistema funzionante?

In un mondo Agile ideale, costruisci rapidamente un sottoinsieme piccolo ma utile del sistema finale desiderato e lo dai agli utenti. Sono entusiasti, perché è utile, iniziano a usarlo e forniscono feedback. Quindi scopri cosa aggiungere, costruisci e ripeti fino allo scadere del tempo.

Di recente ho avuto un paio di progetti che prevedevano la sostituzione di un qualche tipo di sistema funzionante. Il modello sopra non funzionava affatto: fino a quando non avresti creato un sistema che includeva praticamente tutte le funzionalità del sistema esistente, gli utenti non avevano alcun interesse. Non lo userebbero.

Come si applica Agile quando "il sottoinsieme utile più piccolo" è "tutto"?

La soluzione agile potrebbe non essere quella di sostituire tutto in una volta, ma di procedere gradualmente alla sostituzione.

Introdurre gradualmente il nuovo sistema, a poco a poco, mantenendo in funzione parti del vecchio sistema. Il vecchio sistema non è spento tutto in una volta, svanisce e basta. Le nuove parti offrono nuove funzionalità o altri vantaggi, quindi gli utenti sono lieti di usarle. Anche questo è meno rischioso, poiché hai sempre un sistema funzionante al 100%.

• Leggi di più da Martin Fowler .
• Le strategie di Michael Feather's Lavorare efficacemente con il codice legacy possono essere utili

Piuttosto che riscrivere il sistema esistente (che, come hai accennato, richiederà un certo sforzo prima che il nuovo sistema corrisponda alla funzionalità esistente), considera l' approccio strangolante alla vite . Fondamentalmente, implementate nuove funzionalità usando il vostro nuovo approccio in cima all'applicazione esistente. Alla fine, man mano che risolvi le carenze del vecchio sistema per affrontare le nuove funzionalità, il nuovo codice sostituirà completamente il vecchio.

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

Rilasciare piccoli incrementi nel mondo potrebbe funzionare per progetti greenfield ma anche in questo caso il piccolo numero 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 spedibile.

Se si desidera fornire agli utenti una versione incrementale dell'app, è possibile classificarla come Alpha e Beta, quindi rilasciare le versioni candidate pur avendo ancora in uso l'app di produzione reale.

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

Ho lavorato su una vasta gamma di applicazioni sostitutive per un'importante rete nazionale di tv via cavo. Lo sviluppo del nuovo sistema è stato fatto con SCRUM, si trattava di un progetto di sviluppo di 18-24 mesi per reimplementare quasi tutti i principali sottosistemi; che si stavano avvicinando a 10 anni.

C'è stata una fase di pianificazione di circa 6 mesi prima che iniziasse lo sviluppo, ma è stato affrontato anche come SCRUM. È qui che il proprietario del prodotto ha scritto negozi ed epopee di alto livello dopo un'analisi del sistema esistente e intervistando i clienti.

Il sistema esistente era estremamente stabile e passava in modalità di manutenzione critica; sono stati risolti solo i problemi relativi allo stopper, tutto è stato appena registrato per scopi storici e per assicurarsi che gli stessi problemi non fossero presenti nel nuovo sistema.

Il nuovo sistema si è evoluto come descritto in un processo Agile, per lo più estremamente fluido. Quando il sistema di sostituzione ha raggiunto la funzionalità parziale, non è entrato in produzione, ma in prove di produzione parallele. Un sottoinsieme di lavoratori non critici ha iniziato a utilizzare entrambi sistemi, per confermare che il nuovo sistema si è comportato come quello precedente; con i vecchi bug risolti ovviamente.

Quando il nuovo sistema ha raggiunto quasi il 100% di nuove funzionalità complete, è stato implementato per cicli di produzione paralleli generali, che sono durati un paio di mesi.

Una volta che il cliente ha ritenuto di soddisfare le proprie esigenze, è stato eseguito il backup, lo spegnimento e la seduta del vecchio sistema. Presumo che abbiano riproposto il vecchio hardware di sistema perché non hanno mai avuto bisogno di tornare al vecchio sistema dopo averlo tagliato.

Penso ancora che l'agile aggiunga molto valore in questo scenario.

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

Le tecniche e i processi agili possono comunque farti arrivare in modo più efficace.

Per esempio:

È ancora possibile fornire sul sistema in modo iterativo e in piccoli sprint.

È ancora possibile utilizzare tecniche agili per stabilire le priorità del lavoro dopo aver comunicato con le persone chiave.

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

Puoi ancora usare tecniche e filosofie agili come diffondere conoscenza, TDD, codifica pulita per migliorare la qualità e il design interno del progetto.

Se hai persone che sono veramente "non interessate" al progetto e che non interagiscono con il progetto fino a quando non avranno un sostituto perfetto, avrai un problema più grande indipendentemente dal fatto che tu stia usando la cascata, l'agile o qualsiasi altro processo.

Funziona allo stesso modo, ma questo approccio sarà più difficile da vendere agli utenti esistenti. Potrebbero non voler il nuovo sistema e non vogliono essere interrotti da test periodici. Vogliono aspettare il più a lungo possibile e poi testarlo alla fine. La maggior parte degli utenti si sente così fino a un certo punto, ma spetta a chi è incaricato di educarli. Nella loro mente, stai lavorando con un'applicazione esistente, quindi dovresti sapere cosa dovrebbe fare, perché disturbarli?

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

Un punto di forza chiave potrebbe essere quello di implementare quel cambiamento durante la costruzione della nuova app che hanno sempre desiderato, ma che non potrebbero mai entrare nel vecchio sistema.

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

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

Concesso c'è un lontano differenza diversa tra la costruzione di un'auto e la creazione di software personalizzato, ma ignoriamolo per motivi di discussione. Il punto della storia non deve essere perplesso dal fatto che il client non trova alcuna utilità per i cambiamenti incrementali quando hanno già un software abbastanza buono da portare a termine il lavoro ora. Soddisfa già il loro bisogno per il momento.

Ciò non significa 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 compiuti progressi prima delle principali pietre miliari 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 di ottenere davvero quello che hai previsto. Oops, in realtà volevo un motore a 6 cilindri invece del motore a 4 cilindri! Non te l'ho detto prima? Nessun problema, consente di apportare una modifica all'ordine di fabbrica.

Vendi l'idea ai clienti che è nel loro interesse utilizzare le nuove versioni del software non come un sostituto, ma per valutarlo e assicurarsi che siano soddisfatti di ogni passo lungo la strada.