1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 - Customizzare il process template, regole per i campi aggiuntivi dei WI
5 - Personalizzare i Work Item di TFS, ancora qualche regola interessante
Fino ad ora si è esaminato solamente come aggiungere informazioni ai Work Item, ma non si è mai affrontato l’argomento "gestione dello stato”. Il valore del campo Status è infatti molto particolare ed è gestito in modo particolare, dato che a livello sottostante è presente un workflow che determina le possibili transizioni. Supponiamo ad esempio di dover gestire il ciclo di vita di un Bug, inizialmente sarà nello stato “Triage” ad indicare che qualcuno lo ha appena inserito nel sistema e che deve essere esaminato da qualcuno prima di poter essere dato in pasto agli sviluppatori.
Il concetto di Triage è analogo a quello di un pronto soccorso, qualcuno analizza tutti i bug in triage e ne determinerà lo stato successivo rispetto al risultato dell’analisi. Dopo il triage un bug potrebbe andare ad esempio in stato Attivo (indica che deve essere corretto) oppure si può decidere di non correggerlo per varie ragioni: wont fix (non verrà per ora corretto), Non replicabile (non si è riuscito a replicare il tester può quindi aggiungere più informazioni). Supponiamo quindi di volere modificare la definizione del Bug per il processo agile standard, in modo da supportare il concetto di Triage. Per fare questo è necessario andare a modificare una sezione particolare della definizione di un Work Item, gli stati e le transizioni (State and Transitions)
Lo stato (State) rappresenta uno dei possibili stati logici del WI, in un bug come già detto potremmo avere: Triage, Closed, Active e Resolved, mentre le transizioni (Transition) servono a rappresentare la possibilità di muovere un Work Item da uno stato ad un altro. Tutte queste informazioni fortunatamente possono essere editate tramite un editor grafico presente nel Process Template Editor dei Power Tools.
Ecco ad esempio come si presenta il diagramma degli stati per il Work Item di tipo Bug del processo agile.
Figura 1: Stati e transizioni del bug nell’editor grafico del Process Template Editor.
Supponiamo ora di volere introdurre il concetto di Triage del bug, basta trascinare dalla toolbox un nuovo stato e cambiare il suo nome in Triage.
Figura 2: Abbiamo aggiunto uno stato al workflow del WI
Ora è necessario far puntare la transizione iniziale allo stato Triage invece che allo stato Active, per fare questo si clicca con il tasto destro sulla transizione, e si sceglie “Open Details”, operazione che permette di editare i dettagli della transizione, per ora siamo interessati solamente a cambiare il campo To.
Figura 3: Cambiare lo stato di destinazione di una transazione dalla finestra dei dettagli.
Come potete vedere il campo From è nullo, ad indicare che questo è lo stato iniziale. Una transizione non può essere però salvata se non ha almeno una Reason, ovvero una informazione sul perché il Work Item ha cambiato stato. In questo caso io ho semplicemente rimosso tutte le ragioni precedentemente presenti, ed ho aggiunto quelle che rappresentano meglio il mio nuovo modello di bug.
Figura 4: Le reasons per potere aprire un bug nello stato Triage.
Come si può vedere in questo caso ho deciso che il bug di default è segnalato da un tester, ma posso avere un bug aperto da una build failure e anche un bug che è stato segnalato direttamente dal cliente (solitamente questi hanno priorità maggiore). La cosa interessante è che posso cliccare con il tasto destro sul workflow e scegliere di validare il tutto. Ad esempio ora ho il seguente errore:
State Active cannot be reached from the start Transition.
Perché ho staccato la transizione iniziale dallo stato Active e la ho fatta puntare allo stato Triage e quindi lo stato Active non è ora più raggiungibile. Si deve quindi procedere a creare le nuove transizioni, semplicemente selezionando il “Transition Link” dalla toolbox e facendo drag and drop dallo stato di partenza allo stato di destinazione. Dopo un minimo di customizzazione si arriva ad esempio a questo risultato.
Figura 5: Come si presenta il workflow dopo la customizzazione.
Ora in realtà bisognerebbe rivedere tutte le transizioni affinché tutto sia coerente, ma già in questo modo possiamo verificare cosa succede quando andiamo a creare un nuovo bug. Si può subito notare come l’unico stato possibile sia lo stato Triage e le uniche ragioni possibili siano le tre specificate, con automaticamente selezionata la ragione di default.
Figura 6: Il nuovo Bug parte in stato Triage ed abbiamo nuove Reason da poter specificare.
Ora si può inserire un titolo valido al bug e salvarlo, immediatamente il campo Reason diventa Read-Only, perché è possibile cambiarlo solamente in relazione ad un cambio di stato. Se ad esempio si prova a cambiare lo stato in Active, si può notare come il campo Reason diventi editabile, ma si può selezionare solamente il valore “Accepted”, mentre se si seleziona lo stato Closed si può selezionare una delle reason associate alla transazione.
Figura 7: Il cambio di stato permette di selezionare nuovamente una delle reason associate alla transizione.
Grazie alla gestione di Stati e Transizioni è possibile quindi determinare il flusso logico per lo stato di ogni tipologia di Work Item che meglio si adatta al proprio processo. Anche in questo caso TFS si dimostra uno strumento veramente flessibile ed adattabile al proprio processo di sviluppo.
Alk.