Software di riscrittura che utilizza metodologie Agile

Scomposizione in epiche di alto livello. Prendi ciascuna area funzionale dell'applicazione, un passo alla volta.

Rompere un'epica in un gruppo di storie (blocchi utilizzabili - qualsiasi cosa che migliori l'applicazione) e gestirli come faresti se non avessi un'applicazione esistente, con un'eccezione: se possibile, fallo in modo che tu possa implementare quell'unica parte di funzionalità come parte o insieme dell'applicazione originale.

Quando gli Agilisti dicono "rilascio anticipato e spesso", ciò non significa necessariamente produzione. Se stai per sostituire un'applicazione esistente, dovresti utilizzare un'area di gestione temporanea da rilasciare spesso e assicurarti che gli utenti stiano testando il sistema. Ciò consentirà comunque loro di dare la priorità al prossimo lavoro e di assicurarsi che nulla di ciò che si rilascia alla produzione diventi obsoleto.

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

abbiamo appena vissuto un'esperienza del genere (io come proprietario del prodotto scrum). Ci sono voluti due anni per arrivare a qualcosa di sbloccabile. Ma ancora, agile ci ha portato molti benefici.

Primo: una riscrittura totale è per sua natura non agile. Dovresti invece prendere in considerazione la possibilità di 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 backlog che copre tutti i casi d'uso rilevanti del prodotto esistente. Ma per favore non avvicinarti come speci di scrittura. Sarebbe troppo dettagliato Dovrebbe essere completo (altrimenti non è possibile pianificare la liberazione). E non dovrebbe essere troppo elaborato (altrimenti stai scrivendo le specifiche in anticipo). Ecco come ci siamo avvicinati:

• categorizza gli utenti del vecchio prodotto. Identifica gli utenti che hanno bisogno solo di una piccola parte del vecchio prodotto e comunque ottengono qualcosa di utile da esso. Definiscono la tua prima epopea.

• Quindi aggiungi un'epica che consentirebbe ad un'altra categoria di utenti di spostarsi sul nuovo prodotto. Ecc. Fino a quando non si dispone di un registro posteriore che copre tutti gli utenti.

• molto probabilmente, queste epiche avranno bisogno di ulteriori suddivisioni. Se possibile, prova a dividere in modo che ogni parte abbia ancora un valore. Se ciò non è possibile, assicurati almeno che ciascuna parte possa essere dimostrata.

• quando hai 20-50 poemi epici, chiedi al team di stimarli.

• divide la maggior parte delle epop in User Story che il team ritiene fattibile in uno sprint. Non farlo ancora per tutti i film epici, solo quelli in cima. Avrai tutto il tempo per dividere il resto.

Quando rilasciare esternamente! Questa è una decisione aziendale. Almeno questo approccio ti dà l'opportunità di rilasciare in precedenza alcune categorie di utenti. Questo può essere utile se la direzione diventa nervosa per questo progetto apparentemente senza fine.

Rilascia ora Se puoi

La tua domanda su quando inizi a rilasciare il codice è ottima. Penso che si applichino due condizioni. In primo luogo, di avere "una qualità sufficientemente buona" e in secondo luogo di soddisfare i requisiti per un MVP (prodotto minimo vitale).

Roma (e Agile) non sono stati costruiti in un giorno

Forse sei pronto con un team agile chiavi in mano a subentrare il primo giorno. Per la maggior parte delle organizzazioni, vi è il lavoro e le spese dell'addestramento, del riattrezzamento e del consueto ciclo di formazione, assalto, normazione ed esecuzione della costruzione di una squadra. Siate al corrente dei rischi e dei costi, state attenti a dare aspettative realistiche e state pronti a sostenere il vostro approccio.

Utilizza nuovamente Bootstrapper

Come per la fusione, il riutilizzo del codice è e sarà sempre la soluzione futura ai nostri problemi economici. La mia sensazione è che gli sviluppatori dicano spesso di credere nel riuso, 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 costruire sulle fondamenta di qualcun altro? Nel migliore dei casi, significa una riscrittura ogni pochi anni quando la leadership della squadra cambia.

Perché rilasciare presto e spesso?

Rilascia presto e spesso è un mantra per molte ragioni. Dà vita alle nostre discussioni su ciò che il prodotto dovrebbe diventare, rende reali dove siamo e ci fornisce una base per cambiamenti iterativi / incrementali. Il ritmo delle versioni è praticamente invariabile per l'agile, con la differenza di chi riceve le versioni (surrogati del cliente o utenti finali). Prima dell'agile, è stato stimato che la manutenzione rappresentasse il 60% del costo dei sistemi software. Questa è una fonte di grande costernazione per i manager e altri, alcuni che ritengono che la release del prodotto sia dove il software va a morire. Per loro, tutto dopo il rilascio viene rielaborato e pagato per correggere 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 inopportuno perché è un momento in cui non si hanno clienti e si paga per il prodotto anziché il prodotto che paga per te.

Non criticare il team precedente

Anche se potrebbe configurare gli sviluppatori che si assumono la riscrittura come eroe e la salvezza del progetto, penso che ci sia un costo per criticare le realizzazioni della squadra precedente.

• In primo luogo, se lasci che le persone decidano per conto della squadra precedente, hai più tempo ed energia per la tua vera missione.
• Sarebbe imbarazzante se dovessi lavorare con membri del team precedente, sia con sviluppatori che con parti interessate come product manager, project manager o clienti.
• Se riesci a farlo funzionare, potresti scoprire di ricevere (o peggio ancora) credito per ciò che ha fatto la squadra precedente.
• In media, la squadra precedente era probabilmente nella media. In media, potresti essere nella media. Hai più lavoro della squadra precedente perché hai una nuova metodologia da mettere in atto in aggiunta a un progetto.
• Se la vecchia squadra era orribile, a meno che tu non sia orribile, alla fine ti verrà riconosciuto il merito di essere meglio di quanto sia orribile. Se fossero meglio di orribili, e tu non sei notevolmente migliore, dire che erano orribili potrebbe invitare spiacevoli paragoni.
• Se la vecchia squadra era migliore di quanto pensavi, 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 aumenti in modo significativo le aspettative.
• Se si aspettano quello che stanno ottenendo, ma tu fai meglio, è una vittoria per te.
• Astenersi dalle critiche è sia buone maniere, sia mostrare di avere lezione.

Sollecitato dai commenti di @Chuck e dai riferimenti a Netscape che in sostanza dice di non riscrivere, e risposte valide che rispondono che OP non sta chiedendo se dovrebbe. - Un ciclo di sviluppo del software veramente agile preclude la riscrittura. Riscrivere quasi sempre infrange molti dei principi dietro Agile. Utilizzando il software corrente come base di base, questi principi Agile (dal Agile Manifesto ) non possono essere soddisfatti con una riscrittura.

• Consegna anticipata e continua di software prezioso . - il cliente non otterrà il valore iniziale quando viene misurato rispetto a ciò che già possiede
• Fornisci frequentemente software di lavoro - settimane o mesi - quanto è grande il progetto, puoi dire onestamente che il cliente otterrà qualcosa di più utile in qualsiasi momento.
• Il software di lavoro è la principale misura di progresso - il funzionamento rispetto alla previsione non avverrà in fretta
• I processi Agile promuovono lo sviluppo sostenibile. - Dato che il cliente ha una base operativa, la pressione sarà destinata a fornire funzionalità migliorate. È improbabile che ciò avvenga a un ritmo così sostenibile
• La semplicità - l'arte di massimizzare la quantità di lavoro non eseguita - è essenziale. questo dice tutto davvero ...

"Suppose you have to rewrite an entire application using Agile methodologies, how would you do it?"

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

Considerare se è possibile rilasciare l'applicazione riscritta un pezzo alla volta e averla in produzione parallelamente a quella precedente.

In particolare, per le applicazioni Web, potrebbe essere abbastanza semplice spostare una singola parte dell'applicazione su una nuova piattaforma e fare in modo che le richieste di instradamento del bilanciamento del carico vengano inviate al 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 sarà spesso possibile.

Stai cercando le giunzioni - luoghi in cui è possibile che il vecchio sistema abbia le proprie responsabilità assunte dal nuovo, senza bisogno di una riscrittura completa.

Forse esiste una logica aziendale autonoma che può essere spostata in un nuovo servizio web o framework, e la vecchia app può essere modificata al posto del suo vecchio codice. Continua a tagliare i pezzi fino a che ciò che è rimasto è gestibile tutto in un solo boccone.

Se non riesci a trovare alcuna giuntura, allora potresti davvero dover cercare il tipo di approccio del big bang suggerito in alcune delle altre risposte. Ma preparati a una lunga marcia prima di raggiungere la tua destinazione, soprattutto se ci si aspetta che continui a sviluppare il vecchio sistema in parallelo ...

Agile says we should release early and often, but it doesn't make much sense to release before the complete rewrite has been completed.

In realtà, IMHO questo è il punto chiave: prima si ottengono parti della domanda riscritta in produzione (e si sostituisce idealmente la funzionalità del vecchio sistema), maggiori sono le probabilità che il tuo progetto abbia successo. Se pensi che questo non abbia molto senso, pensaci bene - ci sono quasi sempre possibilità di rilasciare parti.

Probabilmente vorrà dire che qualcuno deve modificare 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 sono in produzione, l'approccio agile e iterativo diventerà ovvio. I requisiti cambieranno, le storie degli utenti cambieranno o avranno nuove priorità, e speriamo che sostituirai sempre più funzionalità del vecchio sistema in piccoli passi.