Scrum - Sviluppatori che lavorano al di fuori di Sprint

Questo è un problema piuttosto comune, causato da pipelining . Il team è multifunzionale, ma naturalmente ci sono silos interni che riducono le prestazioni.

Innanzitutto vorrei sottolineare un paio di cose che ritengo importanti:

1. Se i tuoi sviluppatori eseguono un'iterazione in anticipo, stanno anticipando la tua riunione di pianificazione. Il tuo product manager e il team devono discutere ciò che è più prezioso per la successiva iterazione in modo corretto. Le priorità non dovrebbero essere fatte in modo efficace dagli sviluppatori perché non hanno niente di meglio da fare.

2. Indipendentemente dal modo in cui dividi e disponi le iterazioni, non puoi davvero tenere tutti occupati tutto il tempo e avere una singola squadra con una sola riunione di pianificazione, purché il tuo team abbia specialisti che lavorano in silos. Anche con un approccio a cascata pura, devi comunque "gettare la roba sul 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 risoluzione dei bug, seguita da ... questo può davvero rendere la tua squadra inefficiente - soprattutto se lavorano in anticipo, perché hanno bisogno di cambiare contesto.

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

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

1. Sottolinea il principio che il team intero è responsabile per fare le cose. Rifiuta le storie "dev done", poiché 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 di entrambi gli sviluppatori e il controllo qualità, accoppiale . Questo è di gran lunga il modo migliore per condividere le conoscenze e la conoscenza del dominio che puoi scegliere. Gli sviluppatori possono aiutare i tester a automatizzare i loro compiti. I tester possono mostrare agli sviluppatori dove è importante testare il codice perché è fragile. Entrambi collaborano e funzionano più velocemente che non.

Utilizzando queste due tecniche la squadra dovrebbe essere meno silenziosa e più performante. Sebbene sia improbabile che i tester e gli sviluppatori siano in grado di scambiare i lavori, saranno in grado di lavorare come una squadra 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 patto che proceda alla registrazione al momento della valutazione che il lavoro dello sviluppatore sia terminato in meno tempo (e quanto meno tempo) quindi pianificato. Ciò consentirà al team di acquisire più punti storia per il prossimo sprint. Dopo tutto, il punto di partenza è quello di migliorare la pianificazione. Ovviamente hai ancora margini di miglioramento.

we are always developing next sprints work in the current sprint

Whoa! Questo non è tecnicamente possibile in Scrum. Non sai quali saranno gli elementi del backlog nel prossimo sprint, che sarà stabilito all'inizio dello sprint successivo in una sessione di pianificazione sprint.

Resta interessante conoscere nuovi modi creativi che le organizzazioni inventano per sabotare Scrum.

Scrum ottimizza il team , non l'individuo. L'intero punto di difficoltà è 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 tuo processo di pianificazione, se non riesci a pianificare abbastanza lavoro da riempire la primavera.

Se gli sviluppatori hanno esaurito le attività di sviluppo, devono assolutamente inserirsi e aiutare i tester o gli scrittori tecnologici oi designer - chiunque nel team. Non devono necessariamente scrivere test effettivi (anche se dovrebbero ), ma possono comunque partecipare al processo di test. Possono scrivere script che aiutano i tester a essere più efficienti, o possono semplicemente discutere con i tester quali sono le loro sfide e andare aiutandoli a superare quelle sfide (ad esempio aggiungendo attributi id agli elementi della pagina web, fornendo hook o API che i tester può usare nei loro test, ecc.)

Penso che il nocciolo del problema sia che se i tuoi sviluppatori non lavorano sempre allo sprint attuale, non stanno ancora lavorando come una squadra. Il tuo supervisore dovrebbe prendere nota 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 perché restino occupati, non hanno completamente abbracciato la mischia. Questa è un'altra cosa che può essere d'aiuto al maestro di mischia. Possono lavorare con il management per aiutarli a capire come funziona la mischia in modo che possano aiutare a sostenere e incoraggiare i team di sviluppo piuttosto che sovvertirli.

Penso che il problema chiave qui sia il seguente:

the majority of developers have the opinion that testing is beneath them

Il modo in cui l'abbiamo gestito nella nostra azienda è che abbiamo chiesto agli sviluppatori come si può dire che hanno effettivamente terminato il proprio lavoro se non sono riusciti a dimostrarlo. Certo, l'unico modo per dimostrarlo è dimostrare che il codice che hanno scritto funziona davvero, e questo viene fatto attraverso i test. Dovrebbe essere loro indicato che se acconsentono a partecipare ai test, allora i test saranno fatti più velocemente e avranno più tempo per codificare funzionalità aggiuntive (che dovranno anche essere testate).

Dimostra 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ò codificare Non tutti possono codificare e provare che ciò che codificano effettivamente funziona.

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

In ogni caso, fare qualcosa che non era stato pianificato all'inizio dello sprint è un grande no-no. È meglio non fare nulla, piuttosto che fare qualcosa che non è stato pianificato. La funzionalità che scrivono in questi casi molto probabilmente non soddisfa i criteri DoD (Definizione di fatto), poiché probabilmente non è stata testata correttamente, poiché i tester erano impegnati a testare ciò che era stato originariamente pianificato. Questo è un modo infallibile per introdurre bug e deteriorare la qualità del prodotto, che quindi manda il team in una spirale discendente di problemi di regressione e interruttore di contesto, causando stress, velocità ridotta e, infine, l'uscita dal team a causa di esso.

In teoria tutti i membri di un team SCRUM dovrebbero avere le stesse conoscenze, in modo che ogni membro possa prendere ogni compito da ogni altro membro. In caso contrario, dovresti diffondere la conoscenza.

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

La diffusione della conoscenza potrebbe richiedere più tempo di quanto la direzione desideri accettare.

Per quanto riguarda 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 suddividere compiti più grandi. Se hai compiti più piccoli, sarai più flessibile.
• Definisci alcune attività facoltative che potrebbero essere eseguite se è rimasto del tempo.

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

Sembra che tu abbia desicronizzato la tua squadra. Così:

   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 testano il proprio codice. Se i ragazzi di test preparano il test senza rivedere il codice, probabilmente stanno facendo solo test blackbox che non tengono conto dei punti decisionali del programma sviluppato. Sei soddisfatto della qualità del tuo software?