In questo periodo mi sto interessando alle metologie agili, Scrum e XP in particolare. Leggendo il blog di Ron Jeffries, uno dei fondatori di XP, ho letto un articolo interessante sul refactoring. Ho tradotto le parti salienti qui di seguito.
Traduzione in italiano da: Why is refactoring a must? di Ron Jeffries.
“Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.”
- Scrum richiede che alla fine di ogni Sprint sia consegnato software “completato”. Sta al team decidere cosa vuole dire “completato”, ma generalmente significa eseguito, testato, integrato e pronto a funzionare.
- Gli Sprint durano un mese nella definizione Scrum classica, di meno nelle moderne implementazioni. Il team, quindi deve consegnare software “completato” nelle prime due settimane o nel primo mese dalla partenza del progetto.
- Il software in questione deve essere sviluppato a partire dal backlog del Product Owner. Il backlog deve contenere funzionalità. Per seguire Scrum correttamente, non si può consegnare elementi infrastrutturali, bisogna consegnare funzionalità.
- Nelle prime iterazioni non ci sarà tempo per costruire la robusta infrastruttura di cui il prodotto finale avrà necessità. Si svilupperà solo una parte di infrastruttura.
- Il prodotto finale, ad ogni modo, avrà bisogno di una infrastruttura completa, potente e robusta.
- L’infrastruttura del software, quindi, deve cambiare perché all’inizio non è possibile averla, ma alla conclusione del progetto è indispensabile.
- Ci sono pochi modi per cambiare l’infrastruttura. È possibile riscriverla ad ogni Sprint, oppure si può farla evolvere. Riscriverla di continuo è inefficiente, quindi farla evolvere gradualmente diventa necessario. L’evoluzione del software è refactoring. Il refactoring non è che questo.
Si deve far evolvere l’infrastruttura. Non è una regola, è una legge naturale. Fin quando non si impara a far evolvere il design, Scrum potrà portare vantaggi, ma sicuramente non funzionerà al meglio delle possibilità, portando rallentamenti man mano che il tempo passa.
Complimenti, sei stato citato tra i blog da seguire:
http://mysocialweb.wordpress.com/2009/04/21/post-intervista-per-blogger-parte-i/
Sottoscrivo quasi pienamente, salvo per il fatto che non penso che sia Scrum a causare i rallentamenti; direi piuttosto che li evidenzia, mentre con altri metodi probabilmente rimarrebbero più nascosti.