Scrum - Sviluppatori che lavorano al di fuori di Sprint

Il team Scrum

• 3 sviluppatori
• 2 x tester
• 1 x Analista del test di automazione

Non siamo un team multifunzionale in quanto gli sviluppatori non testano e i tester non si sviluppano. Credo che questa sia la causa principale del problema.

Attualmente facciamo sprint di due settimane.

All'inizio dello sprint tutti sono occupati, gli sviluppatori stanno iniziando il lavoro di sviluppo e i tester stanno preparando i loro test (scrivendo casi di test, ecc.)

Una volta che i tester hanno terminato la loro preparazione, ora stanno aspettando il completamento del lavoro di sviluppo OPPURE il lavoro di sviluppo è completo e gli sviluppatori sono in attesa di feedback / bug.

Gli sviluppatori ottengono prurito qui e iniziano a lavorare su elementi nel backlog che sono al di fuori dello sprint corrente. Questo ha creato uno strano effetto per cui stiamo sempre sviluppando il lavoro degli sprint successivi nello sprint corrente. Per me questo non sembra giusto.

Dal punto di vista gestionale, preferirebbero che gli sviluppatori lavorassero piuttosto che sedersi alle loro scrivanie senza fare nulla, ma allo stesso tempo mi sento come l'obiettivo del team di mischia e l'attenzione dovrebbe essere esclusivamente sullo sprint corrente. Vorrei che il nostro team fosse multifunzionale, ma sfortunatamente non è realizzabile. I tester non hanno le competenze necessarie per svolgere il lavoro di sviluppo e la maggior parte degli sviluppatori ritiene che i test siano al di sotto di essi.

Questo è considerato un problema nella mischia? c'è una soluzione a questo? Scrum funziona solo con team multifunzionali?

Mi piacerebbe conoscere le esperienze di altre persone con questo, se possibile :)

Questo è un problema piuttosto comune, causato dalla pipeline . Il team è multifunzionale, ma ovviamente ci sono silos interni che riducono le prestazioni.

Innanzi tutto vorrei notare un paio di cose che ritengo importanti:

1. Se i tuoi sviluppatori lavorano in anticipo su un'iterazione, anticipano la tua riunione di pianificazione. Il responsabile del prodotto e il team devono discutere adeguatamente di ciò che è più prezioso per la prossima iterazione. La definizione delle priorità non dovrebbe essere effettuata in modo efficace dagli sviluppatori perché non hanno niente di meglio da fare.

2. Indipendentemente dal modo in cui dividi e organizzi le iterazioni, non puoi davvero tenere tutti occupati tutto il tempo e avere una sola squadra con una singola riunione di pianificazione purché la tua squadra abbia specialisti che lavorano nei silos. Anche con un approccio a cascata pura, dovrai comunque "gettare roba oltre il muro" e attendere il feedback.

3. Hai anche il problema che spesso una singola storia deve avere una fase di sviluppo, seguita da una fase di test, seguita da una fase di correzione dei bug, seguita da ... questo può davvero rendere il tuo team inefficiente, specialmente se lavorano in anticipo , perché devono cambiare contesto.

Chiaramente c'è un costo molto reale in questa situazione: il team non sta collaborando. L'ho incontrato ogni volta che era coinvolto un team di controllo qualità, quindi ho avuto un po 'di tempo per sperimentare soluzioni diverse.

Ciò che ha funzionato molto bene per me sono questi due strumenti:

1. Sottolinea il principio secondo cui l' intero team è responsabile del completamento delle attività. Rifiuta le storie "dev done", in quanto sono un modo per gli sviluppatori di dire "non più il mio problema", che non è né costruttivo né palesemente falso. Se una squadra non consegna una storia che ha accettato, è l'intera squadra che non ha consegnato.

2. Per occupare il tempo sia degli sviluppatori che del QA, abbinali . Questo è di gran lunga il modo migliore per condividere competenze e conoscenze di dominio che puoi scegliere. Gli sviluppatori possono aiutare i tester ad automatizzare i loro compiti. I tester possono mostrare agli sviluppatori dove è importante testare il codice perché è fragile. Entrambi collaborano e lavorano più velocemente che no.

Usando queste due tecniche, il team dovrebbe diventare meno sciocco e più performante. Mentre è molto improbabile che tester e sviluppatori siano in grado di scambiare lavori, saranno in grado di lavorare in gruppo e risolvere il problema internamente, invece di incolparsi a vicenda.

Non vi è alcun problema con il modo in cui si lavora in relazione a SCRUM e sprint, a condizione che al momento della valutazione venga registrato che il lavoro degli sviluppatori è stato completato in meno tempo (e quanto meno tempo) rispetto a quanto pianificato. Ciò consentirà alla squadra di affrontare più punti trama per il prossimo sprint. Dopo tutto, lo scopo degli sprint è migliorare la pianificazione. Ovviamente hai ancora margini di miglioramento.

sviluppiamo sempre il lavoro dei prossimi sprint nello sprint corrente

Whoa! Questo non è tecnicamente possibile in Scrum. Non si conoscono gli elementi arretrati nel prossimo sprint, che deve essere stabilito all'inizio dello sprint successivo in una sessione di pianificazione dello sprint.

Resta interessante conoscere nuovi modi creativi in ​​cui le organizzazioni inventano per sabotare Scrum.

Scrum ottimizza per la squadra , non per l'individuo. Il punto centrale della mischia è che la squadra diventi efficiente. Se gli sviluppatori stanno iniziando a lavorare su cose al di fuori dello sprint corrente, stanno facendo un disservizio al team. Mostra anche che stai fallendo un po 'nel processo di pianificazione, se non pianifichi abbastanza lavoro per riempire la molla.

Se gli sviluppatori hanno esaurito le attività di sviluppo, dovrebbero assolutamente dare una mano e aiutare i tester, gli scrittori di tecnologia o i progettisti, chiunque nel team. Non devono necessariamente scrivere test effettivi (tuttavia, dovrebbero ), ma possono comunque partecipare al processo di test. Possono scrivere script che aiutano i tester ad essere più efficienti, oppure possono semplicemente discutere con i tester quali sono le loro sfide e aiutarli a superare quelle sfide (ad esempio: aggiungere attributi id agli elementi della pagina Web, fornire hook o API che i tester possono usare nei loro test, ecc.).

Penso che il cuore del problema sia che se i tuoi sviluppatori non stanno sempre lavorando allo sprint corrente, non stanno ancora lavorando in gruppo. Il tuo Scrum Master dovrebbe prenderne atto e lavorare per far lavorare la squadra come un'unità piuttosto che come una raccolta di individui.

Suggerisco anche che questo è un problema di gestione. Se stanno facendo pressione sugli sviluppatori per rimanere occupati, allora non hanno completamente abbracciato la mischia. Questa è un'altra cosa che può aiutare lo Scrum Master. Possono lavorare con il management per aiutarli a capire come funziona la mischia in modo da poter aiutare a supportare e incoraggiare i team di sviluppo anziché sovvertirli.

Penso che il problema chiave qui sia il seguente:

la maggior parte degli sviluppatori ritiene che i test siano sotto di loro

Il modo in cui lo abbiamo gestito nella nostra azienda è che abbiamo chiesto agli sviluppatori come possono dire che hanno effettivamente finito il loro lavoro se non possono provarlo. Naturalmente, l'unico modo per dimostrarlo è dimostrare che il codice che hanno scritto funziona davvero, e questo viene fatto attraverso i test. È opportuno sottolineare loro che se accettano di partecipare ai test, i test verranno eseguiti più rapidamente e avranno più tempo per codificare funzionalità aggiuntive (che dovranno anche essere testate).

Fai notare che testare il tuo codice non è al di sotto del livello degli sviluppatori. È parte integrante del processo di sviluppo. Non può essere separato dalla semplice codifica. Chiunque può programmare. Non tutti possono codificare e dimostrare che ciò che hanno effettivamente funzionato.

Un altro modo per tenere occupati gli sviluppatori è farli lavorare sulla codifica dei test automatici per le funzionalità sviluppate nello sprint. Tali test potrebbero quindi essere utilizzati per i test di regressione che verrebbero eseguiti periodicamente.

Ad ogni modo, fare qualcosa che non era previsto all'inizio dello sprint è un grande no-no. È meglio non fare nulla, piuttosto che fare qualcosa che non era previsto. La funzionalità che scrivono in quei casi molto probabilmente non soddisfa i criteri DoD (Definition of Done), poiché probabilmente non è stata testata bene, poiché i tester erano impegnati a testare ciò che era originariamente pianificato. Questo è un modo sicuro per introdurre bug e deteriorare la qualità del prodotto, che quindi invia il team in una spirale discendente di problemi di regressione e cambio di contesto, con conseguente stress, velocità ridotta e, infine, abbandono del team a causa di esso.

In teoria, tutti i membri di un team SCRUM dovrebbero avere le stesse conoscenze, in modo che ciascun membro possa svolgere tutte le attività di ogni altro membro. In caso contrario, dovresti diffondere la conoscenza.

Ma in pratica c'è sempre qualche tipo di specializzazione. Il software può essere complesso, il membro del team ha competenze diverse, ecc. Dividere il team in sviluppatori e tester è solo un (molto comune) esempio di specializzazione.

Diffondere la conoscenza potrebbe richiedere più tempo di quanto la direzione voglia accettare.

Per la mia esperienza, potresti fare diverse cose:

• Non rendere la squadra troppo piccola. Se ad esempio hai 4 sviluppatori e 4 tester, è molto più semplice spostare un'attività su un altro sviluppatore o tester, avendo solo 3/2 come in questo esempio.
• Prova a dividere le attività più grandi. Se hai compiti più piccoli sarai più flessibile.
• Definire alcune attività opzionali che potrebbero essere eseguite se rimane tempo.

Questi suggerimenti potrebbero non essere una teoria SCRUM al 100%, ma prima devi continuare a far funzionare lo sviluppo. SCRUM è solo una cassetta degli attrezzi.

Sembra che tu debba desicronizzare la tua squadra. Come quello:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Se ho capito l'automazione del test, i ragazzi devono iniziare con qualche giorno di anticipo.

Ma sento un problema nel tuo team: ho un problema con gli sviluppatori che non verifica il proprio codice. Se i ragazzi del test preparano il test senza rivedere il codice, probabilmente stanno facendo solo test blackbox che non tengono conto dei punti di decisione del programma sviluppato. Sei soddisfatto della qualità del tuo software?