Una definizione di "Fine" nel caso di più team di sviluppo che lavorano su uno stesso prodotto

Uno dei test di Scrum contiene la domanda sulla definizione che meglio descrive "Fatto" quando più team di sviluppo eseguono un lavoro su uno stesso prodotto.

Una risposta adeguata afferma che tali team di sviluppo devono avere una tale definizione di "Fatto" che può potenzialmente rendere il loro lavoro combinato potenzialmente rilasciabile.

Ciò che non è chiaro per me dalla risposta corretta a questo quiz, è:

i team possono avere diverse definizioni di "Fatto"? Fino a che punto?

agile scrum

Pensa a un team che rilascia direttamente un prodotto e allo stesso lavoro utilizzato da altri team.

— Ian,

O ad esempio le versioni inglesi del software possono essere spedite prima di essere tradotte in francese.

— Ian,

Questo tipo di confusione è il motivo per cui non dico mai che sia stato fatto qualcosa. Invece dico sempre esattamente quello che abbiamo fatto. Decidere se si fa qualcosa è una trattativa. Non una dichiarazione. Indipendentemente dalla definizione che segui.

— candied_orange

Risposte:

Quando tutti i team definiscono "Fatto" in un modo che tenga conto del lavoro svolto da altri team, allora si garantisce che la funzionalità sia completa.

Se ogni squadra definisce "fatto" in modo diverso e si aspetta solo che le altre squadre conoscano quella definizione, incontrerai diversi problemi:

Quando si presenta un problema di integrazione, nessuna squadra vorrà prendersi cura di risolverlo. Dopotutto, è stato "fatto" quando hanno iniziato a integrare le cose, quindi deve essere qualcosa con il lavoro dell'altra squadra.
Quando hai più di una manciata di squadre, diventa difficile ricordare la "definizione di fatto" di tutti, specialmente quando ci sono differenze tra le squadre.
La definizione di done non garantisce che il lavoro di integrazione funzioni correttamente.

La risposta accettata afferma chiaramente che le cose non vengono fatte fino a quando il lavoro di tutti i team non viene integrato e funziona correttamente. Deve essere rilasciabile e quindi in grado di essere accettato dagli utenti finali nella sua interezza.

Modifica in risposta ai commenti: questo non significa che ogni squadra abbia la stessa definizione di fatto. Significa che parte della definizione di done di ogni team è il sistema più grande e altri componenti integrativi non vengono interrotti.

— Greg Burghardt
fonte

Chiedo scusa, ma mi sembra che la risposta corretta non dica nulla sull'avere la singola definizione di "Fatto". Inoltre, non sono sicuro che le peculiarità di integrazione debbano essere incluse in esso. Dire se due team lavorano entrambi su implementazioni completamente diverse della stessa API dedicata a clienti diversi? Tuttavia formalmente stanno ancora lavorando allo stesso prodotto.

@Andremoniy, la risposta corretta in effetti non dice nulla su un singolo DoD, ma significa che i DoD di tutti i team dovrebbero avere un elemento comune che il prodotto complessivo rimane funzionale. Il tuo esempio di diversi team che lavorano su diverse implementazioni di un'API non mi convince che quello potrebbe essere chiamato un singolo prodotto.

— Bart van Ingen Schenau,

@Andremoniy, non appena un team dipende dal lavoro di un altro team, possono verificarsi (si) problemi di integrazione, anche se le parti vengono distribuite in posizioni diverse. È anche un problema di integrazione, ad esempio, quando un micro-servizio utilizza un altro micro-servizio in un modo imprevisto, possibilmente errato.

— Bart van Ingen Schenau,

@Andremoniy: hai ragione nel dire che quei due team non dovrebbero usare lo stesso DoD, ma possono condividere la regola secondo cui qualsiasi modifica non deve influire negativamente sull'altra squadra (che si innescherebbe principalmente se il lavoro comporta modifiche all'interfaccia con la parte posteriore -end server).

— Bart van Ingen Schenau,

@Andremoniy: grazie per i tuoi commenti. Ho aggiornato la mia risposta per risolvere alcuni dei problemi che hai sollevato.

— Greg Burghardt,

Potrei immaginare una situazione in cui un team definisce "Fatto" come "Sviluppo fatto" (ovvero il codice unito al repository) mentre l'altro lo definisce come "Test fatto" (ovvero il codice rilasciato in Q / A e testato).

Ciò porterebbe intrinsecamente a seri problemi perché lo stato generale del prodotto sarebbe ampiamente indefinito e quindi sarebbe difficile dire se possiamo effettivamente rilasciarlo o meno.

— Pawel Gorczynski
fonte

Consideri la risposta corretta come se uno affermasse che tutte le squadre dovrebbero condividere la stessa definizione?

Sì, concordo sul fatto che dovrebbe esserci una definizione comune per un semplice motivo: un progetto complesso può essere considerato una struttura ad albero in cui i sottoprogetti (ad es. Microservizi) costruiscono il prodotto complessivo (ad es. MyCool ERP). Quindi, in un dato momento, vuoi sapere se è possibile rilasciare una nuova versione del prodotto. Ma se hai un DoD diverso per particolari sottocomponenti, queste informazioni diventano estremamente difficili da dedurre.

— Pawel Gorczynski,