In uno sviluppo agile come si gestisce il codice "meno ben architettato" che deriva da una mentalità focalizzata sullo sprint

Question

Io lavoro su un progetto agile usando Scrum.

Gli sprint sono arrivati ​​e passati e abbiamo raggiunto con successo le pietre miliari. Il sistema funziona abbastanza bene per soddisfare le attuali esigenze dei clienti.

Tuttavia, rimaniamo con un sistema che ha un serio bisogno di refactoring, in quanto gran parte dello sviluppo è stato eseguito con poco occhio sul futuro (invece l'attenzione era sullo sprint a portata di mano).

Come affrontare al meglio questo? Sprint (s) dedicato al refactoring?

Answer 1

Sì, quello occasionale di quelli a volte non è una cosa negativa. Ma se sei agile con Scrum, allora stai presumibilmente cercando di seguire il Test-Driven Development (TDD), ed è importante ricordare che la sequenza è red-green- refactor, non solo rosso-verde. Il codice di cattiva qualità non è l'output di uno sviluppo agile, ma dello sviluppo agile scarso.

Answer 2

Dove lavoro, ci saranno gli sprint dedicati ai bug e technical debt. Funziona bene per migliorare le cose e avere uno spirito di miglioramento continuo in una certa misura.

Qualcosa su cui riflettere anche se ci sono o meno miglioramenti che il cliente vuole ma non ha richiesto. Il cliente sembra sinceramente contento del sistema attuale o funziona abbastanza bene da non volersi lamentare?

Answer 3

Non è necessario necessariamente dedicare uno sprint intero al refactoring, ma può anche funzionare a livello di compito. Quando hai una storia che richiede di lavorare con qualche pezzo di codice peloso, includi un compito di refactoring in quella storia come una sorta di prerequisito per ottenere qualcosa di sensato fatto con quella parte. In questo modo, puoi progredire con le funzionalità, ma anche ottenere un po 'di refactoring in modo incrementale.

Answer 4

Per la mia squadra di solito inizio uno sprint di sprint approssimativamente una volta ogni tre o quattro mesi. Considerando che eseguiamo sprint di due settimane, questo è uno sprint di sprint approssimativamente ogni sette sprint.

Corro lo sprint di refactoring come qualsiasi altro sprint - rigorosamente a 2 settimane di tempo. A volte eseguiamo anche solo una settimana di sprint di refactoring (quando arriva qualcosa di urgente).

Una nota sulla sprint di refactoring: non essere troppo ambizioso:

1. Rendetevi conto che refactoring è un ciclo infinito: troverete sempre un modo migliore per fare le cose.
2. Va bene se si refactoring solo il 10% di ciò che deve essere refactored.
3. Trattate il refactoring come qualsiasi altra storia in modo che siate costretti a dare la priorità a cosa rifattorizzare e riconoscere dove nel vostro codice è più necessario il refactoring. L'unica differenza è che per le storie di refactoring ho lasciato agli sviluppatori la priorità.
4. Un refactoring parziale lascerà il tuo codice in uno stato migliore di nessun refactoring. Inoltre, tende a rendere più semplice il refactoring.
5. Il refactoring avviene anche al di fuori degli sprint di refactoring quando si lavora su storie, ma solo se il refactoring è un frutto a basso impatto che non interferisce con il completamento delle storie.

Questo è quello che uso personalmente come guida per il refactoring. Non solo rende il refactoring gestibile, ma serve anche come un buon indicatore per quando si sta esagerando.

Answer 5

Hai una definizione di "fatto"?

Una volta terminata la codifica e sono pronti al check-in, si dovrebbe hanno incontrato la tua definizione squadre di 'fatto'

Questa definizione dovrebbe tra l'altro comprendere che soddisfano i criteri di accettazione/revisione del codice/recensione di prova/e rispettare gli standard di codifica concordati.

Se dopo diversi sprint la base di codice necessita di un serio refactoring, suggerirei di definire la propria definizione di fatto.

Ecco un articolo da Scrum Alliance sulla definizione vostro 'definition of done'