Scrum: con cosa sono impegnati i membri del team durante uno sprint

Quindi, uno scrum sprint è un periodo di tempo fisso durante il quale deve essere implementato un set specifico di funzionalità. E un team di scrum è composto da tutte le persone impegnate a fornire tali funzionalità, la maggior parte delle quali in genere sviluppatori e tester.

Avendo stabilito queste regole, ci si potrebbe chiedere come tenere tutte queste persone occupate durante l'intero sprint. All'inizio dello sprint non c'è ancora nulla da testare, e alla fine dello sprint in genere non c'è nulla o molto poco da sviluppare / risolvere.

Ho visto 2 approcci per gestirlo, ma nessuno dei due sembra risolvere correttamente il problema.

1) Lascia che i membri del team decidano cosa fare ogni volta che sono fuori dai compiti.

Contro:

• Se ciò che fanno non è pianificato in modo completo (ad es. Refactoring importante, passaggio a un nuovo framework di test), il loro lavoro potrebbe rivelarsi inutile o essere bloccato a metà strada
• D'altra parte, la pianificazione di tale lavoro può richiedere molto tempo e il cliente può essere deluso nel vedere il team perdere tempo su qualcosa che non porta valore immediato
• Tali compiti di solito non possono essere stimati in modo approfondito, quindi è abbastanza facile per i lavoratori senza principi passare il tempo a guardare i gatti di YouTube senza che si rifletta sulla mischia o altrove

2) Fai spazio nello sprint solo per lo sviluppo e inizia i test dopo lo sprint (quando gli sviluppatori iniziano a lavorare sulle funzionalità dal prossimo sprint)

Contro:

• Durante lo sviluppo di funzionalità per lo sprint corrente, gli sviluppatori si distraggono correggendo i bug del precedente e non possono eseguire la quantità di lavoro che è stata stimata da eseguire durante lo sprint corrente
• Sono necessarie due schede Scrum: una per le funzionalità di Sprint correnti e una per i bug di Sprint precedenti

Quindi la mia domanda è: come distribuire correttamente il lavoro durante lo sprint tra sviluppatori e tester in modo che nessuno venga sovraccaricato di lavoro o finisca senza attività in qualsiasi momento? Esistono modi per migliorare gli approcci sopra descritti? O ci sono approcci migliori?

All'inizio dello sprint non c'è ancora nulla da testare

Veramente? Non hai requisiti per convalidare? Nessuna discussione da avere con il cliente? Nessun wireframe da valutare? Nessun piano di test a cui pensare?

alla fine dello sprint non c'è in genere nulla o molto poco da sviluppare / correggere

Non sono mai stato in quel posto in un progetto. Non hai più lavoro da fare? C'è sempre qualcosa. Tutti i tuoi test sono completamente automatizzati? Come sta il tuo CI? Il livello di accesso al database potrebbe essere refactored per essere più semplice? E non ho mai lavorato su nulla con un elenco di bug e un backlog vuoti. Cosa facevano i tuoi sviluppatori in una fase di test a cascata?

So che alcune persone diventano molto religiose su ciò che è e ciò che non è "SCRUM". Non me ne potrebbe fregare di meno. Ma penso che tu abbia due problemi qui:

1. Un dipartimento di controllo qualità "tradizionale" che testa il codice una volta che è "finito" dagli sviluppatori anziché lavorare con clienti e sviluppatori per assicurarsi che tu stia costruendo la cosa giusta e costruendola nel modo giusto. Dai un'occhiata agli agili quadranti di prova di Lisa Crispin. I migliori tester sono coinvolti in ogni fase del ciclo di vita dello sviluppo del software e i migliori sviluppatori scrivono i propri test.

2. Cercare di attenersi troppo da vicino a un programma SCRUM di sprint di 1 settimana / 2 settimane senza disporre di un backlog prioritario e dimensionato suddiviso in attività abbastanza facili da completare in un breve periodo di tempo in un singolo sprint. Se avessi questo, ci sarebbe sempre più lavoro da fare. Forse l'ultima funzione su cui lavori in questo sprint non entra nella versione di questo sprint, ma può sempre passare a quella successiva.

A parte. Se hai una piccola squadra coesa, i ruoli contano meno. Invece di avere qualcuno con l'etichettatrice a cui non è permesso scrivere codice di produzione o che qualcuno abbia etichettato uno sviluppatore che pensa di essere al di sopra dei test, tutti dovrebbero fare tutto il necessario per il successo del team, comprese le temute attività di gestione del progetto quando sono necessari, questo è chiamato un team interfunzionale.

Un altro punto sollevato da @Cort Ammon nei commenti. Il manifesto agile parla della collaborazione dei clienti rispetto alla negoziazione del contratto. Lo dici tu:

il cliente può essere deluso nel vedere il team perdere tempo su qualcosa che non porta valore immediato

Può essere difficile da spiegare e capisco che a volte i clienti possono essere molto difficili, ma per me sarebbe una grande bandiera rossa. Si fidano di te per il loro codice sorgente / relazione cliente / affari / qualunque cosa tu stia sviluppando per loro. Se non possono fidarsi di te per agire professionalmente nel loro interesse, allora hai un problema o lo fanno.

Ho scritto un post che parla di sviluppatori di software non considerati professionisti. Un medico professionista, un avvocato, un ingegnere civile di fronte a un cliente che ha cambiato i requisiti su di loro a metà strada non solo ridurrebbe la qualità e si lamenterebbe al riguardo. Avrebbero detto ai loro clienti che sarebbe stato un problema. Se il cliente spingesse, un professionista non lo farebbe solo alla cieca secondo uno standard pericolosamente inferiore perché sarebbe responsabile. Non accettiamo esami di ammissione professionali e quindi non siamo responsabili. Ciò non significa che non dovremmo cercare di essere migliori.

In sintesi, non mi preoccuperei troppo di cercare di rendere le persone più efficienti all'inizio e alla fine di uno sprint, ma piuttosto lo vedrei come un sintomo di un problema più ampio all'interno del team. Hai mai sentito parlare di eXtreme Programming (XP) . Direi che i principi di XP da applicare qui sono comunicazione e rispetto:

• Rispetta la tua squadra per fare ciò che ritengono migliore. Direi che se ci sono molti video sui gatti, allora hai degli sviluppatori poveri o li stai trattando male.
• Comunicazione. Se i tuoi sviluppatori stanno parlando tra di loro, con i tester, con la direzione, con il cliente, allora probabilmente tutti dovrebbero avere una buona sensazione di ciò che accadrà e se non lo fanno, possono semplicemente chiedere.

Il primo punto è che Scrum si basa sull'ottimizzazione della squadra , non di ogni individuo. Se il team è produttivo ed efficiente, non importa molto se qualcuno è inattivo all'inizio o alla fine dell'attività.

Tuttavia, in ogni squadra in cui ho lavorato, c'è sempre molto lavoro. Consentitemi di affrontare un paio delle vostre preoccupazioni specifiche:

All'inizio dello sprint non c'è ancora nulla da testare,

Sebbene ciò possa essere vero in senso letterale, implica che pensi che l'unico lavoro per un tester sia "testare". C'è molto che si può fare prima che inizino a testare. Per uno, possono incontrare il proprietario del prodotto e gli sviluppatori per comprendere appieno i requisiti. Possono essere impegnati a lavorare su un piano di test, a raccogliere dati di test e così via. Se hanno il lusso di un buon framework, sono in grado di iniziare a scrivere test automatici in anticipo.

alla fine dello sprint non c'è in genere nulla o molto poco da sviluppare / correggere

Devo ancora vedere un team di sviluppo che ha finito le cose da riparare. Tuttavia, non è quello che dovrebbero fare alla fine dello sprint. Verso la fine dello sprint dovrebbero aiutare i tester a testare il prodotto. Possono aiutare a scrivere test automatizzati, a test di revisione del codice e dispositivi / parole chiave / ecc. Scritti dai tester. Possono lavorare con il team di documentazione per aiutarli a finire il loro lavoro, ecc.

Ho visto 2 approcci per gestire questo ... 1) Lascia che i membri del team decidano cosa fare ogni volta che sono fuori dai compiti.

Il difetto nel tuo pensiero è che gli individui finiscono i compiti. Le attività appartengono alla squadra nel suo insieme. Non dovrebbero svolgere altri lavori fintanto che ci sono storie o attività rimaste per la squadra nello sprint corrente.

Fai spazio nello sprint solo per lo sviluppo,

Questo approccio non rientra nella definizione tradizionale di mischia o agile. Il punto di agilità è che un'intera squadra è coinvolta nel lavoro verso un obiettivo comune. Ciò significa che tutto il lavoro necessario per completare una storia deve essere rappresentato in uno sprint: progettazione, sviluppo, test, documentazione, ecc.

Infine, questa non è l'unica altra soluzione praticabile. Trascuri la vera soluzione, ovvero che ogni membro del team dovrebbe presentarsi secondo necessità per aiutare a finire le storie in uno sprint.

L'obiettivo è un obiettivo di squadra , ma stai scrivendo come se ogni singola persona avesse obiettivi individuali ("finisci i miei compiti"). Se qualcuno non ha nulla da fare, può vedere su cosa si sta attualmente lavorando e offrire aiuto. Oppure, possono assumere il compito o la storia successivi e iniziare a lavorarci.

In tutti i negozi agili in cui ho lavorato, i tester sono considerati polli quindi non sono timebox nello sprint come lo sono gli sviluppatori. Prima di mettere le mani sul software, i tester dovrebbero scrivere piani e assicurarsi che gli ambienti siano impostati correttamente per ricevere il software. Come parte di questo, dovrebbero controllare tutti i documenti di design come sono.

Successivamente, dovresti cercare di riempire lo sprint. Non ci dovrebbe essere tempo libero alla fine dello sprint se le stime sono buone anche se la stima ovviamente è un'arte nera, quindi raramente si riempie esattamente .

Se uno sviluppatore ha tempo libero alla fine dello sprint, questa volta dovrebbe comunque essere monitorato per assicurarsi che stia aggiungendo valore (apprendimento di un nuovo framework, analisi, ulteriori test, ecc.).

La correzione dei bug è un'attività perfettamente accettabile da mettere in volata. Contribuisce a una funzione e quindi aggiunge valore. Questo non dovrebbe essere visto come il tempo rubato dal prossimo sprint - finendo più correttamente una funzione.

In un mondo ideale, la tua squadra sarebbe interfunzionale . Ognuno ha la sua specializzazione, ma tutti sono in grado di lavorare anche come un'altra specializzazione. Se i tester non sono in grado di codificare le attività più semplici, allora non hai un team interfunzionale.

Il modo SCRUM sarebbe quello di consentire alla tua squadra di essere interfunzionale. I tester dovrebbero avere comunque le competenze per l'automazione dei test, è un breve passo per codificare alcune delle cose meno complesse.