Gestire la fine del ciclo di sprint tra tester e sviluppatori [duplicato]

Question

Gestire la fine del ciclo di sprint tra tester e sviluppatori [duplicato]

#1 da (2 voti)
#2 da (0 voti)

2

Ho convinto la nostra organizzazione a passare a una definizione a squadra completa di "Fatto", ovvero uno che include il test di controllo qualità e non solo il completamento del codice. Di conseguenza, ora possiamo dire con maggiore precisione dove sono i colli di bottiglia e vedere qual è la nostra vera velocità. Inoltre, questo progetto si integra continuamente e distribuisce regolarmente. Prima di questo, gli articoli completi del codice erano considerati conclusi e il QA si sarebbe regolarmente spostato per accettare le storie da 3-5 sprint fa. Avrebbero solo ricevuto il codice consegnato alla fine dello sprint.

Quindi, come ci si può aspettare, le cose si stanno svolgendo molto più agevolmente, ma ho una domanda alla quale non ho ancora risposto in precedenza nella mia ricerca. Anche con lo sprint, sembra esserci un tempo massimo nello sprint che una storia possa essere completata dagli sviluppatori e implementata prima che non ci sia tempo sufficiente per il QA. A seconda della storia e del volume di cose che devono ancora essere testate, questo sembra essere circa 2-3 giorni prima della fine dello sprint.

Al momento, continuiamo a lavorare sulle cose e spostiamo semplicemente tutti gli elementi non accettati dal QA (cioè cose in corso e cose implementate ma non testate) allo sprint successivo se non sono in grado di completare i test. È una pratica OK? Alcuni sviluppatori che erano abituati a lavorare con il vecchio sistema si lamentano del fatto che questo non dà credito agli sviluppatori per aver completato il lavoro che gli è stato assegnato, ma ritengo che l'idea sia quella di farsi un'idea di ciò che ha fatto l'intero team, non solo sviluppo. L'utente finale non ottiene alcun valore dalle cose non testate e distribuite. Tuttavia, questo processo ha la tendenza a precaricare lo sprint successivo, il che rende la pianificazione leggermente più problematica.

Inoltre, ho sentito che avere una fine dello sprint dello sviluppatore è in realtà OK. Dovremmo invece cercare di lasciare qualche tempo di sviluppo aperto alla fine?

agile scrum sprint

posta Nishmaster 08.04.2015 - 03:17

fonte

2 risposte

Leggi altre domande sui tag agile scrum sprint

Trova tutti i fattori (primo e composto) di un numero Scrivere un parser su un AST basato su XML: lo sto facendo bene?

score 2 · Answer 1

È responsabilità del tuo team - l'intero team - assicurarti che tutto sia fatto. Se gli sviluppatori hanno terminato la codifica e ci sono ancora dei test da scrivere o eseguire, dovrebbero inserirsi e aiutare i tester.

Non dovrebbe esserci alcun "open developer time" - perché penalizzare i tester dando agli sviluppatori tempo libero? Gli sviluppatori devono aiutare con i test. Renderà il tuo prodotto migliore, renderà i tuoi sviluppatori migliori sviluppatori, e farà sentire i tuoi tester più valorizzati.

Gli sviluppatori non devono "precaricare" il prossimo sprint fino a quando non viene eseguito tutto del lavoro nello sprint corrente. Ovviamente ci sono delle eccezioni, ma in generale non dovrebbero iniziare nuovi lavori fino a quando tutto il lavoro esistente non verrà completato.

Some devs that were used to working under the old system complain that this doesn't give the developers credit for completing the work that they were assigned

Questo è buono, perché gli sviluppatori non dovrebbero avere alcun credito. Il gruppo ottiene credito, e non dando credito ai dev, l'intera squadra è resa più strong.

score 0 · Answer 2

Some devs that were used to working under the old system complain that this doesn't give the developers credit for completing the work that they were assigned

Hanno davvero completato il lavoro in tempo quando non è rimasto abbastanza tempo nello sprint per completare il ciclo di test? Forse, forse il QA aveva bisogno di più tempo del previsto, chissà, ma il cliente non è interessato a chi è la colpa della tua squadra.

Una delle idee chiave dell'agile è quella di adattare la pianificazione a ogni sprint. Se il tuo VCS e il tuo modello di ramificazione ti danno la possibilità di spostare semplicemente le implementazioni di feature da uno sprint al successivo, allora usa questo: non fornire codice non testato ti darà sicuramente un prodotto migliore, i tuoi clienti lo apprezzeranno. Assicurati di non inquinare il tuo prodotto rilasciato con il codice "delovoped, ma non testato" - tale codice è sempre incompiuto.

E - come hai già notato nella tua domanda - devi assicurarti di adattare la tua pianificazione per il prossimo sprint. Quando i tuoi sviluppatori forniscono già una funzione appena implementata alla prima ora del nuovo sprint (perché è stata sviluppata di fatto durante lo sprint precedente), le persone del tuo QA avranno bisogno di più tempo per testare lo sprint attuale o meno funzionalità aggiuntive per test. Se ciò accade regolarmente e i tuoi sviluppatori producono costantemente più output di quelli che il QA può testare, devi cambiare qualcosa nel tuo processo o nella tua organizzazione (forse hai bisogno di più QA people, forse dovresti assegnare ai tuoi sviluppatori più compiti nell'area dell'automazione dei test ).