In Scrum, come gestire la contesa / carico di lavoro alla fine dello sprint

Il mio team ha iniziato a utilizzare Scrum alcuni sprint fa. Il nostro progetto prevede la creazione di software che si interfaccia con dispositivi fisici (pensa a robot e sensori) e il nostro tipico portafoglio ordini di prodotti solitamente rappresenta l'aggiunta di dispositivi di controllo all'intero sistema.

Abbiamo suddiviso l'attività vicino all'esempio qui . Ogni funzionalità di integrazione del dispositivo è suddivisa in codice, test, test di integrazione, peer review, ecc. Ovviamente, esiste una sequenza inerente a ciascun articolo di backlog di prodotto. In genere, i nostri sprint durano 2 settimane e il team ha tra 4 e 6 membri.

Incontriamo 2 problemi alla fine degli sprint:

• Il primo è quello di tenere tutti occupati alla fine dello sprint.
• Il secondo (correlato) è la contesa sul sistema. Praticamente finiamo per integrarci durante gli ultimi giorni dello sprint. Abbiamo un solo sistema di integrazione, quindi le persone sono spesso bloccate dal continuare a svolgere il proprio compito perché non possono accedere al sistema. Poiché è la fine dello sprint, non c'è molto lavoro da fare nel backlog dello sprint. Su cosa dovrebbero lavorare queste persone? Il ritiro degli articoli dalla parte superiore del backlog del prodotto non è stato ricevuto correttamente dal proprietario del prodotto, poiché gli articoli correnti non vengono eseguiti. Lavorare sul debito tecnico aiuterà il progetto nel suo insieme ma non aiuterà a completare lo sprint.

Esistono buone pratiche per strutturare gli sprint per evitare questi problemi? Suggerimenti per negoziare con i proprietari dei prodotti?

in un certo senso è positivo che tu sia lento alla fine di uno sprint, ciò significa che stai valutando bene e non impegnarti troppo, per quanto riguarda l'impegno, nei team di scrum su cui ho lavorato, abbiamo sempre aggiunto attività di ricerca per quello che verrà dopo sprint.

Questo potrebbe essere la prova dei concetti per le cose che stanno arrivando, o guardare dove ricodificare il codice esistente, lavorare per ottenere una migliore copertura dei test sul tuo codice, ecc.

Dovresti risolvere il tuo sistema di integrazione in modo che il tuo team possa integrare il loro lavoro non appena ogni attività è completa, piuttosto che aspettare un big bang alla fine dello sprint.

Consiglio di lavorare con le storie degli utenti abbastanza brevi da finire in pochi giorni. Finito qui significa codice completo, testato e integrato.

Ricordando che è responsabilità dell'intero Team consegnare, non i singoli membri, di per sé , è possibile avere tutti i 4-6 membri che lavorano su ciascuna attività INSIEME - spingere ciascuno attraverso il processo e passare al successivo. All'inizio questo potrebbe sembrare inefficiente, ma se i colli di bottiglia che stai vedendo sono così gravi, potrebbe essere un'opzione valida.

Inoltre, potresti voler esaminare la teoria dei vincoli (Goldratt's The Goal ) e vedere come puoi analizzare meglio perché e dove hai questi colli di bottiglia di integrazione.

Abbiamo affrontato questo problema adottando l'approccio Kanban.

Abbiamo code nel nostro software di tracciamento (Jira) con il minimo e il massimo.

Lo sposo 'secondo necessità'. Potrebbe essere una volta alla settimana, potrebbe essere 3 volte, dipende dai limiti e dal lavoro svolto.

Questo ti aiuterà a focalizzare il proprietario del prodotto sul mantenere la coda con molto da fare e può ridurre la micro-gestione dei singoli biglietti. Ricorda che come sempre il cambiamento richiederà tempo.

Dimostriamo ancora ogni due settimane e rilasciamo settimanalmente.

Wow, se non avessi detto robot, immaginerei che fossi nella mia squadra in questo momento. Abbiamo l' esattostesso set di problemi. Avendo lavorato a numerosi progetti agili con vari gradi di fedeltà al manifesto e vari gradi di successo, la mia analisi è che il nostro problema è che gli sprint sono troppo brevi. Stiamo effettuando sprint di due settimane che causano alcuni problemi. Uno è che finiamo per essere troppo cauti nella pianificazione e spesso finiamo con giorni morti alla fine. Il secondo è l'enorme sentito di revisione, retrospettiva e pianificazione che richiede 1-2 giorni ogni due settimane. Un altro è, come hai detto, dover integrarsi all'ultimo minuto e spesso mancare ore prima della revisione. Il mio primo e agile progetto di successo ha avuto sprint di quattro settimane, che ritengo abbastanza grandi per gli standard del settore, ma ha funzionato benissimo per noi.

EDIT: Ricordato un'altra cosa da quel primo progetto che è stato un vantaggio. Abbiamo sempre avuto un backlog di prodotto completamente prioritario e abbiamo dato agli sviluppatori la libertà di accaparrarsene se le loro attività di sprint erano complete e non erano disponibili altre attività di sprint.

Il secondo problema è probabilmente una conseguenza del tentativo di risolvere il non problema n. 1. Dovresti trovare persone che non sono occupate, per aiutare i loro coetanei; invece di lavorare su attività non sprint, che causano contese sull'integrazione limitata.

Inoltre, non dovresti integrarti alla fine dello sprint, ma continuamente.

Stai appena iniziando. Offri ai team la possibilità di affrontare questo problema da soli attraverso il loro processo retrospettivo.

In secondo luogo, il proprietario del prodotto dovrebbe fidarsi del team per sapere come organizzarsi e ottimizzarsi. In cambio, il team si fida dell'OP per sapere meglio di cosa ha bisogno il cliente.

Queste sono sfide molto comuni con i nuovi team agili. È bello vedere quando una squadra inizia a rompere il proprio silo e crescere.