Riscrittura del software utilizzando metodologie Agile

Supponiamo che tu debba riscrivere un'intera applicazione usando le metodologie Agile, come lo faresti?

Immagino che potresti scrivere un sacco di storie utente basate sul comportamento del tuo sistema attuale. E quindi implementarli in piccole iterazioni. Ma questo non significa che abbiamo i requisiti UP FRONTE ??

Inoltre, quando inizieresti a rilasciare? Agile dice che dovremmo rilasciare presto e spesso, ma non ha molto senso rilasciare prima che la completa riscrittura sia stata completata.

Suddividilo in epopee di alto livello. Prendi ogni area funzionale dell'applicazione, un passo alla volta.

Suddividi un'epopea in un gruppo di storie (blocchi utilizzabili - tutto ciò che migliora l'applicazione) e gestiscili come faresti se non avessi un'applicazione esistente, con un'eccezione: se è possibile, rendilo così può implementare quella funzionalità come parte o accanto all'applicazione originale.

Quando gli Agilisti dicono "liberano presto e spesso", ciò non significa necessariamente produzione. Se hai intenzione di sostituire un'applicazione esistente, devi utilizzare un'area di gestione temporanea per rilasciarla spesso e assicurarti che i tuoi utenti stiano testando il sistema lì. Ciò consentirà comunque loro di dare la priorità al prossimo lavoro e di assicurarsi che nulla di ciò che viene rilasciato alla produzione deprezzi il prodotto.

Dopo aver rilasciato un componente in produzione, passa al successivo.

abbiamo appena vissuto un'esperienza del genere (io come proprietario della mischia). Ci sono voluti due anni per arrivare a qualcosa di rilasciabile. Tuttavia, l'agile ci ha portato molti vantaggi.

Primo: una riscrittura totale per natura non è affatto agile. Dovresti invece prendere in considerazione il refactoring del prodotto esistente pezzo per pezzo. Questo è stato discusso in un'altra domanda. Quindi supponiamo che debba essere una riscrittura.

Quindi, in effetti, si inizia con un registro posteriore che copre tutti i casi d'uso rilevanti del prodotto esistente. Ma per favore non affrontarlo come specifiche di scrittura. Sarebbe troppo dettaglio. Dovrebbe essere completo (altrimenti non è possibile eseguire la pianificazione del rilascio). E non dovrebbe essere troppo elaborato (altrimenti stai scrivendo le specifiche in anticipo). Ecco come ci siamo avvicinati a questo:

• categorizzare gli utenti del vecchio prodotto. Identifica gli utenti che necessitano solo di una piccola parte del vecchio prodotto e ne ricavano comunque qualcosa di utile. Definiscono le tue prime epopee.

• Quindi aggiungi epiche che consentirebbero a un'altra categoria di utenti di passare al nuovo prodotto. Ecc. Fino a quando non si dispone di un registro posteriore che copre tutti gli utenti.

• molto probabilmente, queste epopee dovranno essere ulteriormente suddivise. Se possibile, prova a dividere in modo che ogni parte abbia ancora un certo valore. Se ciò non è possibile, assicurati almeno che ogni parte possa essere dimostrata.

• quando hai 20-50 epiche, chiedi al team di stimarle.

• dividere la maggior parte delle epopee in User Story che il team ritiene fattibili in uno sprint. Non farlo ancora per tutte le epopee, solo quelle in cima. Avrai tutto il tempo per dividere il resto.

Quando rilasciare esternamente! Questa è una decisione commerciale. Almeno questo approccio ti dà la possibilità di rilasciare prima a determinate categorie di utenti. Ciò può essere utile se il management si innervosisce per questo progetto apparentemente senza fine.

Rilascia ora se puoi

La tua domanda su quando inizi a rilasciare il codice è fantastica. Penso che si applichino due clausole. Innanzitutto, hai una "qualità abbastanza buona", e in secondo luogo che soddisfi i requisiti per un MVP (prodotto minimo praticabile).

Roma (e Agile) non furono costruite in un giorno

Forse sei pronto con una squadra agile chiavi in ​​mano per assumere il primo giorno. Per la maggior parte delle organizzazioni, vi è il lavoro e le spese di formazione, riattrezzaggio e il normale ciclo di formazione, assalto, normazione ed esecuzione della costruzione di una squadra. Essere in anticipo sui rischi e sui costi, fare attenzione a fissare aspettative realistiche, essere pronti e pronti a sostenere il proprio approccio.

Diventa un riutilizzabile Bootstrapper

Come il potere di fusione, il riutilizzo del codice è e sarà sempre la soluzione futura ai nostri problemi economici. La mia sensazione è che gli sviluppatori spesso affermino di credere nel riutilizzo, ma solo il tipo di riutilizzo che inizia dopo aver costruito un nuovo framework, piuttosto che il tipo in cui si basano su ciò che qualcun altro ha già fatto. Come può funzionare finché qualcuno non è disposto a scegliere di basarsi sulle fondamenta di qualcun altro? Nella migliore delle ipotesi, significa una riscrittura ogni pochi anni quando cambia la leadership del team.

Perché rilasciare presto e spesso?

Rilasciare presto e spesso è un mantra per molte ragioni. Dà vita alle nostre discussioni su ciò che il prodotto dovrebbe diventare, rende reale dove siamo e ci fornisce una base per cambiamenti iterativi / incrementali. Il ritmo delle versioni è praticamente invariante per l'agile, con la differenza che riceve le versioni (surrogati dei clienti o utenti finali). Prima dell'agile, si stima che la manutenzione rappresentasse il 60% del costo dei sistemi software. Questa è una fonte di grande costernazione per i manager e gli altri, alcuni che ritengono che il rilascio del prodotto sia il punto di morte del software. Per loro, tutto dopo il rilascio è rielaborato e pagato per riparare un prodotto che hanno già pagato una volta.

La pre-release è innaturale

Kent Beck scrive che la pre-release è uno stato innaturale per i prodotti software. È certamente un momento scomodo perché è un momento in cui non hai clienti e stai pagando per il prodotto piuttosto che per il prodotto che paga per te.

Non criticare la squadra precedente

Mentre potrebbe impostare gli sviluppatori che assumono la riscrittura come eroi e salvezza del progetto, penso che ci sia un costo per criticare i risultati del team precedente.

• Innanzitutto, se lasci che le persone decidano della squadra precedente, hai più tempo ed energie per la tua vera missione.
• Sarà imbarazzante se hai bisogno di lavorare con membri del team precedente, sia sviluppatori che stakeholder come product manager, project manager o clienti.
• Se riesci a farlo funzionare, potresti trovarti a ricevere (o peggio ancora prendere) credito per quello che ha fatto la squadra precedente.
• In media, la squadra precedente era probabilmente nella media. In media, potresti essere nella media. Hai più lavoro del team precedente perché hai una nuova metodologia da mettere in atto oltre a un progetto.
• Se la vecchia squadra era orribile, a meno che tu non lo sia anche tu, alla fine otterrai credito per essere migliore che orribile. Se fossero migliori che orribili, e tu non sei notevolmente migliore, dire che erano orribili potrebbe invitare confronti spiacevoli.
• Se il vecchio team era migliore di quanto pensassi e ti trovi nei guai perché l'organizzazione è rotta o il problema è mal definito o molto difficile, le cose andranno meglio per te se non hai significativamente aumentato le aspettative.
• Se si aspettano quello che stanno ottenendo, ma tu fai di meglio, è una vittoria per te.
• Astenersi dalle critiche è una buona educazione e dimostra che hai classe.

Spinto dai commenti di @Chuck e dai riferimenti a Netscape, in sostanza dice di non riscrivere, e risposte valide ribadiscono che l'OP non sta chiedendo se dovrebbe. - Un ciclo di sviluppo software veramente agile impedisce la riscrittura. La riscrittura rompe quasi sempre molti dei principi alla base di Agile. Usando l'attuale software come base di riferimento, questi principi Agile (dal Manifesto Agile ) non possono essere soddisfatti con una riscrittura.

• Consegna anticipata e continua di software prezioso . - il cliente non otterrà un valore iniziale se misurato rispetto a quello che già possiede
• Fornisci frequentemente software funzionante - settimane o mesi - quanto è grande il progetto, puoi onestamente dire che il cliente otterrà presto qualcosa di più utile per loro.
• Il software di lavoro è la misura principale del progresso - il lavoro rispetto alla linea di base non avverrà in fretta
• I processi agili promuovono lo sviluppo sostenibile. - Dato che il cliente ha una base di lavoro, la pressione sarà esercitata per offrire funzionalità migliorate. È improbabile che ciò avvenga ad un ritmo sostenibile
• La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale. questo dice tutto davvero ...

"Supponiamo che tu debba riscrivere un'intera applicazione usando metodologie Agile, come lo faresti?"

La domanda si basa su una premessa errata: la riscrittura può essere considerata agile.

Valuta se è possibile rilasciare un'applicazione riscritta un pezzo alla volta e averlo in produzione fianco a fianco con quello vecchio.

Per le applicazioni Web in particolare, può essere abbastanza semplice spostare una singola parte dell'applicazione su una nuova piattaforma e disporre delle richieste di instradamento del bilanciamento del carico nel sistema appropriato. Quindi scrivi le storie che ti permetteranno di mettere in produzione la tua prima pagina e consegnarle in modo agile.

Le applicazioni desktop possono essere più complicate, ma spesso saranno possibili.

Stai cercando cuciture - luoghi in cui è possibile che il vecchio sistema si assuma le sue responsabilità dal nuovo, senza bisogno di una riscrittura completa.

Forse esiste una logica aziendale autonoma che può essere spostata in un nuovo servizio o framework Web e la vecchia app può essere modificata utilizzando quella invece del suo vecchio codice. Continua a ritagliare pezzi di giunture fino a quando ciò che rimane è gestibile tutto in un morso.

Se non riesci a trovare alcuna giuntura, allora potresti davvero cercare il tipo di approccio big bang suggerito in alcune delle altre risposte. Preparati a una lunga marcia prima di raggiungere la tua destinazione, soprattutto se devi continuare a sviluppare il vecchio sistema in parallelo ...

Agile dice che dovremmo rilasciare presto e spesso, ma non ha molto senso rilasciare prima che la completa riscrittura sia stata completata.

In realtà, IMHO è questo il punto chiave: prima ottieni parti dell'applicazione riscritta in produzione (e idealmente sostituisce la funzionalità del vecchio sistema), maggiori sono le possibilità che il tuo progetto abbia successo. Se ritieni che ciò non abbia molto senso, pensa più intensamente: ci sono quasi sempre possibilità di rilasciare parti.

Probabilmente significherà che qualcuno deve cambiare qualcosa nella vecchia applicazione, ad esempio aggiungere alcune nuove interfacce per interagire con l'applicazione riscritta nel momento in cui la riscrittura non è completa. Ma per la mia esperienza, tale lavoro aggiuntivo si ripaga sempre da solo.

Una volta che le prime parti della nuova applicazione saranno in produzione, l'approccio agile e iterativo diventerà ovvio. I requisiti cambieranno, le storie degli utenti cambieranno o avranno nuove priorità e, si spera, sostituirete sempre più funzionalità del vecchio sistema in piccoli passi.