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

Question

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

#1 da (5 voti)
#2 da (4 voti)
#3 da (3 voti)
#4 da (3 voti)
#5 da (2 voti)

8

Il mio team ha iniziato a utilizzare Scrum alcuni scatti fa. Il nostro progetto prevede la costruzione di interfacce software con dispositivi fisici (think robot e sensori) e il nostro tipico backlog di prodotti in genere rappresenta l'aggiunta di dispositivi di controllo all'intero sistema.

Suddividiamo il compito vicino all'esempio qui . Ciascuna funzione di integrazione del dispositivo è suddivisa in codice, test, test di integrazione, peer review, ecc. Ovviamente, esiste una sequenza inerente a ciascun articolo del Product Backlog. In genere, i nostri sprint durano 2 settimane e il team ha tra 4 e 6 membri.

Ci imbattiamo in 2 problemi alla fine degli sprint:

Il primo è mantieni tutti occupati alla fine dello sprint.
Il secondo (correlato) è il conflitto sul sistema. Quasi finiamo per integrarci durante gli ultimi giorni dello sprint. Abbiamo solo un sistema di integrazione, quindi le persone sono spesso bloccate dal continuare a lavorare sulla loro attività perché non possono accedere al sistema. Dato che è la fine dello sprint, non c'è molto lavoro da fare nello sprint backlog. Su cosa dovrebbero lavorare queste persone? Raccogliere gli articoli dalla parte superiore del backlog del prodotto non è ben ricevuto dal proprietario del prodotto, dal momento che gli articoli attuali non sono fatti. Lavorare sul debito tecnico aiuterà il progetto nel suo complesso ma non aiuterà a completare lo sprint.

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

agile scrum

posta Vincent Hubert 15.07.2011 - 17:53

fonte

5 risposte

Leggi altre domande sui tag agile scrum

Che cosa devo sapere prima di contattare uno sviluppatore web / un team di sviluppo? Come decidi dove la funzionalità dovrebbe appartenere a un progetto su larga scala?

score 5 · Answer 1

in un certo senso è bello che tu sia lento alla fine di uno sprint, che significa che stai valutando bene e non impegnandoti, per quanto riguarda il controllo, sui team di scrum su cui ho lavorato abbiamo sempre aggiunto compiti di ricerca per ciò che è in arrivo il prossimo sprint.

Questo potrebbe essere la dimostrazione di concetti per le cose che stanno arrivando, o cercare dove ri-fattorizzare il codice esistente, lavorando per ottenere una migliore copertura di test sul tuo codice, ecc.

score 4 · Answer 2

Devi sistemare il tuo sistema di integrazione in modo che il tuo team possa integrare il proprio lavoro non appena ogni attività è completata, piuttosto che attendere un big bang alla fine dello sprint.

Raccomando di lavorare con storie utente abbastanza brevi da essere terminate in pochi giorni. Finito qui significa codice completo, testato e integrato.

score 3 · Answer 3

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

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

score 3 · Answer 4

Abbiamo affrontato questo problema adottando l'approccio Kanban.

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

Ci sposo "se necessario". Potrebbe essere una volta alla settimana, potrebbe essere 3 volte, dipende dai limiti e dal lavoro svolto.

Questo ti aiuterà a mettere il proprietario del prodotto al centro dell'attenzione su come mantenere la tua coda con molto da fare e può ridurre la microgestione dei singoli biglietti. Ricorda che, come sempre, ci vorrà del tempo.

Ancora dimostriamo ogni due settimane e pubblichiamo settimanalmente

score 2 · Answer 5

Wow, se non avessi detto robot, immagino che tu fossi nella mia squadra in questo momento. Abbiamo lo esatto stesso insieme di problemi. Avendo lavorato su 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 facendo scatti di due settimane che causano alcuni problemi. Uno è che finiamo per essere troppo prudenti nella pianificazione e spesso finiamo con dei giorni morti alla fine. Il secondo è l'enorme sentimento di revisione, retrospettiva e pianificazione che richiedono 1-2 giorni ogni due settimane. Un altro è, come hai detto tu, dover integrare all'ultimo minuto e spesso mancando ore prima della revisione. Il mio primo e più fortunato progetto agile ha avuto quattro settimane di sprint, che ritengo sia piuttosto grande per gli standard del settore, ma ha funzionato benissimo per noi.

EDIT: Ricorda un'altra cosa di quel primo progetto che è stato un vantaggio. Abbiamo sempre avuto un backlog di prodotti con priorità assoluta e abbiamo dato agli sviluppatori la libertà di intraprendere attività fuori da esso se le attività di sprint fossero complete e non fossero disponibili altre attività di sprint.