Uncovering better ways of developing software
Storie che tornano
A volte ci capita (ahime) che alcune storie concluse e accettate debbano essere riesumate per colpa di un errore riscontrato dal cliente.
Come vi comportate in questi casi?
La mia idea sarebbe di rimettere la storia nella coda e inserirla nell'iterazione successiva ma al cliente la cosa non piace molto, visto che l'errore è del team di sviluppo e quindi ci troviamo a doverle "inserire di nascosto" annegando i punti nel totale dell'iterazione. Avete qualche consiglio su come gestire questi casi eccezionali?
thx
ema
Come vi comportate in questi casi?
La mia idea sarebbe di rimettere la storia nella coda e inserirla nell'iterazione successiva ma al cliente la cosa non piace molto, visto che l'errore è del team di sviluppo e quindi ci troviamo a doverle "inserire di nascosto" annegando i punti nel totale dell'iterazione. Avete qualche consiglio su come gestire questi casi eccezionali?
thx
ema
Risposte a questa discussione
-
Permalink Risposto da Pierluigi Pugliese su -
"Inserire di nascosto" le correzioni non aiuta proprio: il lavoro va fatto comunque e "annegare i punti" vuol dire semplicemente ridurre la velocità di sviluppo delle altre storie. Non aiuta neppure il morale del team in quanto le persone lavorano senza avere un risultato visibile. Prova a vendere il concetto al cliente spiegando che volete essere completamente trasparenti su cosa e come sviluppate e "annegando" il lavoro di correzione diminuirebbe la trasparenza nel progetto.
Ho visto svariati sistemi in uso (backlog multipli, persone dedicate ai fix, ...), ma quello più efficiente è senza dubbio il backlog unico, dove i fix vengono trattati con la dovuta priorità in parallelo alle altre storie.
Certo che se le storie ritornano indietro perchè non implementate correttamente andrei a rivedere la Definition of Done e/o il modo in cui le storie vengono definite per capire se c'è qualcosa da migliorare li'.
Pierluigi
-
Permalink Risposto da Emanuele DelBono su -
Ciao Pierluigi
Non posso che essere d'accordo, inserire di nascosto "funziona" su piccole cose, ma come giustamente dici, va a minare il rapporto di fiducia che si instaura durante il progetto. Cercherò di riparlarne con il cliente.
Il fatto che alcune storie tornino, purtroppo capita perchè il team non è pratico con gli unit test e molte parti non sono coperte. Purtroppo non è sempre facile far capire certi benefit....ma lo stanno capendo a loro spese :-)
ciao
ema
-
Permalink Risposto da Pierluigi Pugliese su
-
Ciao Ema,
Io chiederei al team durante le retrospettive (o in una retrospettiva ad hoc) cosa intendono fare per migliorare a.) la loro abilità nell'uso di JUnit e b.) opzioni alternative per migliorare la qualità complessiva del codice consegnato al cliente (JUnit è un tool, la strategia di test utilizzata è un'altra cosa!).
Se la quantità di storie che ritornano indietro è rilevante perchè la copertura dei test non è adeguata, potrebbe valer la pena di dedicare uno sprint/mini sprint al miglioramento della copertura dei test. Se hai dati storici adeguati potresti anche riuscire a vendere la storia al cliente...
Contattami pure direttamente se vuoi discutere la situazione specifica in dettaglio.
Pierluigi
-
Permalink Risposto da Emanuele DelBono su
-
Grazie per le dritte. Ci ragiono.
A presto
ema
Benvenuto in
Italian Agile Movement
Info su
Eventi
© 2010 Creato da Marco su Ning. Crea un network Ning
Badge | Segnala un problema | Privacy | Termini del servizio
