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.”

1. 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.
2. 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.
3. 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à.
4. 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.
5. Il prodotto finale, ad ogni modo, avrà bisogno di una infrastruttura completa, potente e robusta.
6. L’infrastruttura del software, quindi, deve cambiare perché all’inizio non è possibile averla, ma alla conclusione del progetto è indispensabile.
7. 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.