Nota: il sito web è stato tradotto automaticamente. Passa all'inglese per una migliore esperienza di lettura.

fatto

Finito non è finito – un esempio della definizione di Fatto

L'altro giorno ho preparato un workshop insieme a un collega. Ci siamo subito trovati d'accordo sul contenuto, l'unica cosa che mancava era una presentazione PowerPoint adatta. Per poter lavorare alla presentazione nel modo più efficiente possibile, l'abbiamo suddivisa per temi. Quando poi ci siamo seduti a discutere la bozza finita, è emerso un grosso problema: avevamo idee molto diverse su cosa caratterizzasse effettivamente una "bozza finita". 

Questo problema può presentarsi anche nei team Scrum agili. Dopo due settimane, il team raggiunge la fine dello sprint, ma c'è disaccordo sul fatto che l'incremento di prodotto sia già finito e possa essere spostato da "in progress" a "done". Questo disaccordo porta a discussioni che a loro volta influenzano negativamente il clima del team. Per evitare queste discussioni e tutelare l'efficacia del lavoro di squadra, nel mondo Scrum esiste un artefatto chiamato "Definition of Done" (DoD). 

Qual è la definizione di "Fatto"?

Letteralmente, Definition of Done significa "definizione di finito". Ciò significa che il team si accorda su ciò che deve essere fatto affinché una caratteristica sia considerata finita. In termini pratici, la Definition of Done può essere rappresentata come una sorta di lista di controllo che viene utilizzata durante lo sprint e soprattutto alla fine per verificare se sono stati soddisfatti determinati criteri di completamento. Per i team di sviluppo software, questi criteri possono essere, ad esempio, i seguenti: 

  • La documentazione è stata preparata. 
  • Il codice è completamente implementato e commentato. 
  • È stata effettuata una revisione del codice. 
  • ...

Perché è importante la definizione di "Fatto"?

Che la definizione degli obiettivi sia di enorme importanza per le prestazioni non è un'intuizione nuova. La fissazione degli obiettivi è un argomento molto studiato in psicologia (cfr. Locke & Latham, 2006). È stato dimostrato che le prestazioni sono più elevate quando gli obiettivi sono il più possibile specifici e stimolanti senza sembrare irraggiungibili. La Definizione di Fatto non è, tuttavia, un metodo di definizione degli obiettivi (ma se deve essere utilizzata, è un metodo di definizione degli obiettivi). Supporto nella definizione degli obiettivi Se hai bisogno di aiuto, saremo felici di aiutarti); si tratta piuttosto di criteri che devono essere soddisfatti per raggiungere l'obiettivo. 

Questi criteri sono importanti per creare un'intesa comune nel team. Una comprensione di ciò che ogni membro del team deve realizzare per raggiungere l'obiettivo comune. Si tratta quindi di prestazioni individuali che alla fine si sommano a quelle di un team. 

Se consideriamo la questione della DoD dal punto di vista del proprietario del prodotto, i problemi diventano completamente diversi. Se non viene definito chiaramente quando un incremento di prodotto viene considerato finito, può verificarsi un disaccordo con il cliente quando gli viene presentato il prodotto. Se ciò accade e viene presentato un prodotto non finito, si blocca la possibilità di ricevere un feedback da parte del cliente. 

Miglioramento continuo

Poiché la Definizione di Fatto non è un concetto statico e può e deve essere in continua evoluzione o cambiamento, offre al team anche l'opportunità di imparare. Se, al termine di uno sprint, il team si rende conto di non essere riuscito a soddisfare i criteri della Definizione di Fine, i membri del team possono modificare la Definizione di Fine per soddisfare le prestazioni effettive, oppure il team trae le conclusioni per lo sprint successivo e cambia il proprio modo di lavorare. 

Prova subito Echometer e trova nuove ispirazioni per le tue retrospettive!

Queste riflessioni sulla Definizione di Fatto dovrebbero essere fatte dal team durante la retrospettiva. Possibile Articoli EchometerLe domande che si possono porre in fase di preparazione sono 

Abbiamo delle chiare Definizioni di Fatto per i nostri requisiti.

Di solito so a che punto siamo nel raggiungimento dei nostri obiettivi comuni.

I miei obiettivi sono allineati con quelli dei miei colleghi.

Il team copre tutte le competenze necessarie per raggiungere il nostro obiettivo.

Non solo mettono in dubbio l'esistenza di una Definizione di Fatto nel team, ma anche la trasparenza, l'autonomia e la chiarezza dei ruoli all'interno del team.

Puoi trovare l'elenco completo degli articoli nel nostro sito Strumento retrò.

Come può il nostro team definire il fatto? Un esempio di workshop 

Ti abbiamo mostrato cos'è una Definizione di Fatto e perché è importante per una collaborazione efficace nei team Scrum. Ma se il tuo team non ha ancora creato una DdT, probabilmente ti starai chiedendo come funziona. 

In linea di principio, è importante che il team si prenda tutto il tempo necessario per preparare il documento. Alla fine, dovrebbe emergere un documento in cui ogni membro del team possa identificarsi e che non sia visto solo come un male necessario. Per questo motivo, consigliamo un formato simile a un workshop con lo Scrum Master come moderatore. Ogni membro del team deve pensare a quali criteri sono importanti per il completamento del prodotto e il team può poi riassumere questi pensieri. Analogamente, abbiamo sviluppato un formato di workshop per la definizione degli obiettivi. Dai un'occhiataper trovare idee per il tuo workshop sulla Definizione di Fatto! 

La DoD completata può essere utilizzata nelle retrospettive, ad esempio sotto forma di semaforo della Definizione di Fatto:  

  1. Scrivi di seguito i tuoi criteri per la definizione di Fatto.
  2. Disegna un quadrato rosso, uno giallo e uno verde accanto a ciascuno di essi.
  3. Per ogni elemento della Definizione di Fatto, ogni membro del team segna se è stato implementato bene, moderatamente bene o male nell'ultimo sprint. 
  4. Discuti i tre con le menzioni più frequenti nell'area rossa. 
  5. Se necessario, modifica la tua definizione di "Fatto".

Conclusione – Sei pronto?

Per concludere: nell'ambiente agile non esiste il concetto di "finito". Fatto significa semplicemente che qualcosa è provvisoriamente finito, ma che possono e devono seguire ulteriori aggiustamenti e miglioramenti in qualsiasi momento. Questo è uno dei tanti aspetti belli del lavoro agile: il miglioramento continuo. 

Particolarmente emozionante: a volte i punti sono "fatti" finché il cliente non si fa avanti e mette in discussione l'intera soluzione, scuotendo così le tue ipotesi sulle esigenze del cliente. In queste situazioni, diventa chiaro se il team ha davvero dato priorità ai vantaggi per il cliente rispetto ai progressi nel sistema dei ticket.

Una chiara definizione delle cose da fare può evitare conflitti e aumentare le tue prestazioni. Se ti interessano altri modi per raggiungere questo obiettivo, dai un'occhiata anche al nostro articolo sulla sorprendente verità che si cela dietro la mentalità agile Guarda. Oppure arricchisci le tue retrospettive tenendo conto delle ultime scoperte scientifiche in campo psicologico.

Proprio con questa promessa abbiamo sviluppato il nostro strumento retrò Echometer. Se ti interessa sapere come (e se) funziona Echometer, leggi il resoconto dell'esperienza di Holger con il nostro strumento:

Vuoi portare il tuo team a un nuovo livello di prestazioni? Il nostro Retro Tool può aiutarti a farlo. Ecco le esperienze di Holger:

Fonti 

Locke, E. A., & Latham, G. P. (2006). Nuove direzioni nella teoria della definizione degli obiettivi. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x

Condividi questo articolo con la tua rete

Hai bisogno di una spinta per la squadra? Ecco cosa fare: La retrospettiva sullo stato di salute di Spotify!

Prima domanda sulla salute: "😍 Ci piace andare al lavoro e ci divertiamo molto a lavorare insieme".

Vuoi saperne di più? Prova subito il nostro Retro Tool.

Altri articoli

Newsletter Echometer

Non perdere gli aggiornamenti sull'Echometer e trova ispirazione per il lavoro agile

Ho recentemente scritto un eBook su "12 metodi retrospettivi dalla psicologia" – Ti interessa?

Christian Heidemeyer, psicologo e Scrum Master