Precedenti post sulla personalizzazione Work Item in TFS
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
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni
Post su personalizzazione VSTS
1 – Personalizzare il process template in VSTS
2 – Process template Ereditati in VSTS
3 – Aggiungere ad un Work Item un campo esistente in un altro template
4 – Creare un campo Custom
Per chi ha personalizzato il Workflow di un Work Item, sicuramente la possibilità di personalizzazione degli stati dei Work Item offerta attualmente da VSTS sembrerà alquanto primitiva. La personalizzazione offerta da VSTS infatti non permette ancora di definire un vero e proprio Worklfow, come invece è possibile fare personalizzando il template di TFS, ma permette solamente di gestire l’anagrafica degli stati.
Nella figura sottostante si può infatti vedere la parte di personalizzazione degli stati (1) di un Work Item (PBI), in cui è possibile aggiungere nuovi stati (2) oppure editare gli stati presenti (3).
Come si può vedere dalla figura, gli stati del Work Item sono raggruppati in aree, chiamate: Proposed, In Progress, Completed e Removed. Questi valori rappresentano una sorta di “macro categorie” per gli stati. La regola è che deve esistere almeno uno stato valido per ogni macro categoria. Questo garantisce al motore di poter sempre “ragionare” sulle “macro categorie” per generare le board di default e per tutti i comportamenti di default.
Le limitazioni di personalizzazione ed il concetto di Macro Categorie permette di rendere indolore l’aggiornamento, evitando che l’utente possa andare a modificare qualsiasi aspetto del Workflow. Si paga quindi la limitazione, ma si ottiene di contro un aggiornamento senza sorprese.
Per tutti gli stati già presenti, l’unica opzione possibile è quella di “nasconderli”, con l’opzione hide. Questo significa che lo stato è sempre presente nel template (garantendo quindi la compatibilità degli upgrade), ma non è più possibile associare questo stato ad un Work Item. Tutti i Work Item associati ad uno stato che è messo in Hide sono considerati in uno stato invalido.
In questo caso nella figura precedente è stato mostrato lo stato Approved messo in “hide”. A questo punto aprendo un Work Item in quello stato la UI forza a cambiarne il valore.
Come regola non è possibile mettere in hide tutti gli stati di una “Macro Categoria”, questo garantisce al motore di VSTS che ogni Work Item ha uno stato che al 100% appartiene ad una delle Macro Categorie.
La tecnica di mettere uno stato in Hide, previene una delle personalizzazioni che maggiormente rendono complicati gli upgrade, la rimozione di uno degli stati base.
Si può naturalmente creare un nuovo stato e le uniche opzioni che possono essere configurate sono: il nome, la Macro Categoria ed il colore.
A differenza degli stati base, gli stati nuovi aggiunti dall’utente possono essere rimossi. L’effetto è simile a quello che si ha con l’hide degli stati di default. In questo caso però lo stato verrà rimosso completamente dalla lista e potrà chiaramente essere riaggiunto in seguito. Anche se lo stato viene rimosso i valori storici rimarranno, per cui nella storia dei vari Work Item le transizioni da e per quello stato saranno sempre presenti nella storia. Tutti i Work Item che si trovano attualmente in uno stato rimosso sono in uno stato non valido e debbono essere corretti prima di poter essere salvati nuovamente. (analogamente a quanto succede con l’Hide)
Purtroppo in questa prima versione la personalizzazione si ferma qui e non si hanno altre opzioni. Di base la mancanza maggiore che si ha rispetto alla personalizzazione completa è l’impossibilità di definire un vero workflow, stabilendo le transazioni tra gli stati. Questo impedisce anche di poter mettere security tra la transazione degli stati, e di fatto è quindi possibile muoversi da qualsiasi stato in qualsiasi altro stato di destinazione.
Sebbene questa personalizzazione sia limitata, permette comunque di poter aggiungere stati e garantire di adeguare la nomenclatura del flusso al proprio processo.
Una volta terminata la personalizzazione degli stati, è necessario aggiornare la configurazione nella Kanban Board. Ad esempio avendo messo in Hide lo stato Approved per il PBI la configurazione di default lamenta questo errore:
In questo caso la colonna “Approved” non è più valida perché referenzia lo stato “Approved” del Work Item Type PBI, che invece è stato messo in uno stato Hide.
E’ sufficiente specificare un nuovo stato valido per tutte le colonne della Kanban Board per risolvere l’errore. Ad esempio potremmo voler tracciare il fatto che sia i Bug che i PBI hanno una fase di Valutazione, che concettualmente appartiene alla categoria “In Progress” perché implica che alcune risorse sono al lavoro su di essi. In questo caso è stata aggiunta la colonna “Evaluating” che cataloga i bug in Triage ed i PBI in fase di Analisi.
In questo caso la colonna di Evaluating ha un significato differente per Bug e PBI, nel primo caso si sta facendo Triage, mentre nel secondo caso si sta analizzando il PBI, magari producendo gli Storyboard.
Anche in questo caso, sebbene con le dovute limitazioni, è possibile con pochi click adattare il Processo di VSTS al proprio modo di lavorare e non viceversa.
Gian Maria