Definizione di fatto per molti team Scrum

Insistere nell'imporre un processo fisso ai team sconfigge l'idea di lavorare in modo agile. Ogni squadra dovrebbe essere libera di organizzarsi in modo da poter funzionare al meglio. Se ciò significa che ogni squadra ha la propria definizione di fatto, allora dovrebbe essere accettata come la soluzione migliore. Se, nel tempo, i team si parlano e si stabiliscono in una singola definizione, allora sono grandiosi. Se diverse definizioni continuano a funzionare per loro, mantienili in quel modo.

Each Teams have negotiated their own DoD. There are some differences between each DoDs.

La coerenza ha il suo posto, ma finché non identificherai i problemi causati da una sua mancanza, è difficile trovare una soluzione.

Il vantaggio di Scrum / Agile è di consentire ai team di gestire se stessi. Se una squadra non riesce a raggiungere un consenso su un problema, è opportuno disporre di alcune regole di gestione che potrebbero aiutare a restringere l'attenzione. Inoltre, dato che i membri passano da una squadra all'altra, è bello sapere cosa aspettarsi nella speranza di inserirsi subito. C'è un problema qui che stai cercando di correggere o evitare?

Quindi, per rispondere alla tua domanda, penso che tu sia sulla strada giusta nel cercare di ottenere l'input di tutti, ma dovresti essere pronto a scoprire che c'è una tale mancanza di accordo, che dovresti dimenticare un singolo DoD e lasciare che ogni squadra aggiusta e sviluppa il proprio significato durante il corso di questo progetto come meglio ritiene opportuno.

Qui stai entrando nel territorio di gestione top-down / gerarchico anche se stai coinvolgendo tutti. Stai molto attento nell'applicare una regola rigida a tutte le persone in tutte le situazioni. Sarà molto difficile ottenere 5 singoli team per rivedere continuamente il DoD ogni volta che c'è un'eccezione.

Condivisione di un nucleo comune

Penso che sia ragionevole avere un insieme comune di elementi chiave sulla definizione di fatto, ma deve essere flessibile. Questi elementi comuni dovrebbero essere chiaramente ovvi e necessari per ogni squadra, al punto in cui non ci sono argomenti che dovrebbero essere inclusi.

Ad esempio, ogni squadra dovrebbe probabilmente avere "test unitari che passano" come un oggetto. Un altro buon candidato è "deve essere controllato per il controllo della versione" e "deve superare tutti i criteri di accettazione".

Empowerment del team

Ogni squadra dovrebbe essere libera di modificare la propria definizione di fatto senza richiedere l'approvazione di un comitato. Scrum riguarda l'empowerment team . Costringendo una squadra ad avere una "definizione di fatto" che è stata progettata da un'altra persona o squadra non è l'empowerment.

Ad esempio, alcuni team potrebbero voler richiedere la revisione tra pari, ma forse non è appropriato per tutti i team. Alcuni team potrebbero richiedere un buyoff da un esperto di usabilità, ma in genere non ha alcuna rilevanza per un team che lavora su un back-end. Un team potrebbe avere requisiti di copertura del codice più rigidi di un altro e così via.

Scrum riguarda tutto il team

Nella mischia, il focus è sul team . Se ciò significa che richiede un po 'più di lavoro da parte del proprietario del prodotto o del misum master, così sia. Il ruolo dello Scrum Master è di rimuovere i roadblock, non di aggiungerli.

If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”

If "done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

The Scrum Guide

Senza una definizione comune di "Fatto" per un prodotto , la qualità e la sua trasparenza avranno un impatto negativo. I livelli organizzativi di definizione di Done dovrebbero essere minimi, tecnici e talvolta forniti dall'organizzazione in modo che possano essere applicati universalmente. L'organizzazione può fornire standard di codifica. L'organizzazione potrebbe richiedere build automatizzati fornendo al tempo stesso le risorse per crearlo e mantenerlo per ciascun prodotto. Qualsiasi parte della definizione di "Fatto", creata dall'organizzazione o da un singolo team di sviluppo, deve apportare valore.