Quali sono le possibili e probabili insidie di avere team di scrum asincrona?

Question

Quali sono le possibili e probabili insidie di avere team di scrum asincrona?

#1 da (8 voti)

5

Nel nostro progetto di gioco attualmente ci sono 2 squadre che lavorano in iterazioni di 2 settimane. In passato abbiamo avuto ripetutamente problemi con funzionalità più grandi (cattiva pianificazione / stima, problemi non risolti prima che il codice si bloccasse e le storie non si chiudessero, ecc.) E abbiamo discusso questi problemi in molte retrospettive.

Poiché le funzionalità che dovremmo implementare non stanno diventando più piccole o più semplici (in realtà esattamente l'opposto), abbiamo pensato a modi per aiutarci a ridurre il rischio di ogni iterazione. Un'idea del genere che ho avuto, stava andando con una configurazione simile a quella di ArenaNet fa con Guild Wars 2 :

[...] “And they’re all staggered, so even though we ship every two weeks, the development time for any one of these releases is around four months, it’s just that it’s a smaller team working for an extended period of time which allows them to give it the level of polish that players have come to expect. But it is intense!” [...]

L'idea di base era di mantenere il ciclo di rilascio di 2 settimane, ma spostare i team sfasati l'uno con l'altro, in modo che ogni singola squadra avrebbe avuto un totale di 4 settimane per lavorare sui contenuti. Quindi, in pratica, il setup cambierebbe da questo:
aquesto:

Naturalmente, i rilasci sarebbero più grandi di prima, ma a prima vista sembra almeno in qualche modo vantaggioso:

Più tempo per reagire a problemi imprevisti (bug, errori di sistema, fattori di bus, modifiche progettuali ad-hoc, ...) senza mettere in pericolo l'intero sprint
Il QA potrebbe concentrarsi su una squadra / funzione / versione alla volta, invece di dover controllare tutto da entrambi i team contemporaneamente
Capacità di lavorare su feature più grandi senza doverle dividere / dividerle in segmenti artificiali per adattarsi agli sprint

Ora mi chiedo se questa sia stata effettivamente una buona idea, o se mi manchi qualcosa di ovvio e rovinerebbe tutto. Ci sono altre risorse su questo argomento? I team di scrum asincrono sono fattibili, o è generalmente solo una cattiva idea?

teamwork scrum

posta arotter 01.11.2015 - 10:51

fonte

1 risposta

Leggi altre domande sui tag teamwork scrum

Qual è la motivazione per lanciare un puntatore in un numero intero? Perché le funzioni pure non dovrebbero essere sempre statiche e pubbliche? [duplicare]

score 8 · Accepted Answer

In the past we've repeatedly had issues with larger features (bad planning/estimates)

Se incontri problemi di pianificazione / stima solo per due sprint di due settimane in anticipo, veramente credi che questo migliorerà se ora dovrai stimare il lavoro della tua squadra per quattro settimane anziché due? Onestamente, penso che questo renderà le cose peggiori, non migliori (e non fa differenza se i tuoi team lavorano in modo sincrono o meno).

Ability to work on larger features without having to chunk/split them into artificial segments

La necessità di dividere le grandi funzionalità in sezioni più piccole è IMHO un punto di forza del processo: se si sacrifica questo, la pianificazione / stima peggiorerà, i cicli di test si allungheranno e la capacità di controllare il processo diminuirà. Quindi raccomanderei strongmente contro questo. Meglio cercare di rendere la divisione delle caratteristiche non così artificiali.

Se si dispone di funzionalità più grandi su cui lavorare non possono essere completate in uno sprint, dividerle in quelle più piccole, ma non rendere queste funzionalità parzialmente completate disponibili agli utenti immediatamente alla fine di ogni sprint. Meglio, impara a utilizzare "feature branch" e "feature toggles" per le tue esigenze.

Una strategia di ramificazione / fusione migliore potrebbe anche essere un approccio per sciogliere i team dal ciclo di sprint "due settimane" fisso - se la prossima feature slice si adatta meglio in 9 giorni anziché 14, mentre l'altra squadra ha bisogno di 16 giorni, questo dovrebbe essere perfettamente possibile. E il tuo team di QA può ancora ottenere una nuova versione ogni 14 giorni. Devi stabilire una strategia per questo che ti consenta di vietare la consegna di funzionalità semi-elaborate dal ramo di sviluppo a "staging" nel mezzo di uno sprint, senza interrompere le tue squadre dal lavoro. Ci sono diversi approcci su come ottenere questo risultato con Git e, ovviamente, lo sforzo di gestione della configurazione probabilmente aumenterà, ma probabilmente è in disuso dai benefici che ne derivano.