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.