Uno dei punti cardine di un buon processo di sviluppo è stabilire chiaramente cosa significhi che un qualcosa sia completato.

La cosiddetta Definition of Done [DoD] nasce in Scrum, ma è evidente che può, anzi deve, essere adattata a qualunque processo per raggiungere dei risultati accettabili

Sostanzialmente si tratta di una lista di attività, che vanno dallo scrivere codice, al testing, arrivando fino alle release note che aggiungono valore al prodotto. In Scrum è estremamente enfatizzata, cosiccome dalla Continuous Delivery, che quindi pretende che done corrisponda a shippable.

Naturalmente non esiste una DoD universale: va adattata in base allo scenario, al processo utilizzato e soprattutto al livello in cui la stiamo applicando: una DoD di un check-in non corrisponde alla DoD di uno sprint o di un backlog.

E’ essenziale che sia trasparente a tutti i membri del team, e tutti i criteri della DoD devono essere soddisfatti per ogni Product Backlog Item.

Modellare la DoD sul processo significa sostanzialmente utilizzare gli strumenti a disposizione per far si che il workflow di lavoro vada a configurarsi per seguire i passaggi della DoD del team.

Team Foundation Server ci aiuta in vari modi: innanzitutto con le Check-In Policy. Rispettare una serie di Check-In Policy significa dover rispettare alcune regole, quindi aderire alla DoD. Queste regole raggiungono il loro apice con un Gated Check-In, che funge da barriera netta: dentro o fuori. Ovviamente è possibile scrivere altre policy oltre a quelle presenti di default in TFS oppure utilizzare il Check-In Policy Pack for TFS, disponibile su CodePlex.

Nel caso in cui il check-in sia rigettato, è possibile eseguire uno shelve (che purtroppo vedo ancora poco utilizzato in molti casi). Con lo shelve, oltre a poter accantonare quel determinato task e quindi essere pronti per eseguirne un altro in attesa di nuovi sviluppi, si hanno molti piacevoli side effects.

Il primo è sempre in ombra ma in realtà estremamente importante: il backup. Infatti tutti gli shelveset sono coperti dal backup di Team Foundation Server.
Inoltre uno shelveset può essere oggetto di Code Review (in vari modi, a breve dedicherò un post alla nuova funzionalità in Visual Studio 11) da parte di altri membri del team, a tutto vantaggio della qualità.
Senza contare poi che gli shelveset rimangono proprietà intellettuale del proprietario, non essendo solamente un pezzo di codice che rimane lato client ma comunque qualcosa che rimane lato server e quindi all’interno dell’organizzazione.

posted on giovedì 2 febbraio 2012 12.15 | Print

Comments

Gravatar
# re: Rappresentare la “Definition of Done”
Posted by LudovicoVan on 02/02/2012 13.59
> Uno dei punti cardine di un buon processo di sviluppo è stabilire chiaramente cosa significhi che un qualcosa sia completato.

Sacrosanto.

> La cosiddetta Definition of Done [DoD] nasce in Scrum [...] Sostanzialmente si tratta di una lista di attività

Cosi' resta un po' troppo confinata all'ambito tecnico: occorre un legame con i requisiti a monte. Ergo, in primis, occorre un'analisi decente: dall'analisi viene poi un project plan (in salsa agile o meno agile), da cui poi la lista di task che un puo' flaggare fatti/non fatti. Senza analisi, non c'e' modo di verificare che i task completati hanno niente a che fare con le esigenze da risolvere.

-LV
Gravatar
# re: Rappresentare la “Definition of Done”
Posted by matteo.emili@gmail.com on 02/02/2012 17.48
Mi riferivo all'insieme di operazioni da compiere affinchè un qualunque task sia considerato 'done'.
Queste attività devono ovviamente essere concordate (anche in via formale se necessario) a tutti i livelli, altrimenti si rischia un'errore di comunicazione e valutazione non indifferente.
Sono rimasto volutamente legato all'aspetto tecnico, visto che parlo di 'rappresentazione' della DoD utilizzando gli strumenti a disposizione.
Gravatar
# re: Rappresentare la “Definition of Done”
Posted by Luca Minudel on 02/02/2012 18.23
aggiungo 2 dati curiosi sulla DoD.

1) quando piu team lavorano allo stasso progetto é preferibile che condividano la medesima DoD

2) quando un team é nuovo alla DoD e fino a quando non ha ancora l'esperienza per definire una propria DoD (per esempio non ha avuto training su Scrum e non ha completato con successo 3 sprint consecutivi), Jeff Sutherland parte usando questa DoD

* Feature Complete
* Code Complete
* No known defects
* Approved by the Product Owner
* Production Ready

che deve poi essere adattata dal team al progetto, alla tecnologia, e al proprio livello di skill
Post Comment
Title *  
Name *  
Email
Url
Comment *  
Please add 6 and 2 and type the answer here: