Continuiamo il nostro viaggio alla scoperta di DevOps attraverso l'ecosistema Microsoft (qui la prima parte).
Ogni nuova idea, prima di poter diventare un prodotto ed avere allocate le risorse per realizzarlo, deve necessariamente passare per la relativa validazione di sostenibilità (spesso indicata come Inception) analizzandone i contorni, valutandone i rischi e le relative opportunità di mercato.
In generale, per la prima fase di approfondimento si preferisce usare i cosiddetti Canvas, ovvero una serie di panel che permettono di esplicitare i diversi elementi strategici che andranno a caratterizzare l’azione di mercato del nuovo prodotto, oltre alle caratteristiche del prodotto stesso.
Canvas
I Canvas più noti sono: Vision Board Canvas, Business Model Canvas/Lean Canvas e Product Canvas che, nell’ordine esplicitato, vanno dalla visione annessa al nostro prodotto fino a quello che è una sorta di primo draft con i diversi elementi specifici.
Allo stato attuale, VSTS non offre un supporto diretto ai Canvas, per cui può essere utile sfruttare servizi terzi come Canvanizer per rappresentarli in modo digitale e collegarli tramite link a specifiche Epic del prodotto.
Canvanizer
Resta, chiaramente, sempre valida l’opzione di usare dei panel materiali (stampe) dei Canvas, fotografarli e gestirli tramite il repository documentale associato al prodotto, ad esempio SharePoint. In particolare, tramite il Product Canvas si vanno ad esplicitare diversi elementi di liftoff gestiti direttamente da VSTS:
- Name, il nome del prodotto;
- Goal, gli obiettivi;
- Metrics, il modo in cui il raggiungimento dei goal viene misurato;
- Target Group, le Personas che lo utilizzeranno;
- Big Picture, gli elementi fondamentali che descrivono il prodotto: Scenari, Mock-up, StoryBoard, ecc.;
- Product Details, gli item da realizzare: epic, feature, user story (anche se più di rado).
The Product Canvas
Come accennato, tali elementi sono effettivamente “mappati” e rappresentati direttamente in VSTS:
- Name, è il nome stesso del Team Project;
- Goal, è possibile utilizzare delle estensioni del Marketplace come “Product Vision” per esplicitarli nella Dashboard;
- Metrics, utilizzando l’estensione di “Application Insight” si può visualizzare una tile con le informazioni rilevanti direttamente nella dashboard;
- Target Group, è possibile sfruttare l’estensione del marketplace “Personas”.
Big Picture e Product Details necessitano di un maggiore approfondimento.
Partiamo da Big Picture. Qui si sfruttano strumenti come le StoryBoard di PowerPoint per produrre i mock-up del prodotto, consentendo al potenziale utente (Personas) di navigare le diverse schermante e fornire feedback agli sviluppatori in modo che possano essere allineati con le sue aspettative.
Una volta realizzato il mock-up, si potrà collegarlo direttamente ad un Product Backlog Item (PBI) e gestirlo come elemento di dettaglio della relativa realizzazione direttamente da VSTS.
Story Board con Power Point
La sezione del Canvas “Product Details” si trasforma negli elementi di Planning tipici del mondo Agile, vale a dire Epic/Feature/User Story, che VSTS utilizza in modo intensivo per consentire di coordinare le attività di realizzazione del prodotto.
VSTS Agile Items
I diversi item possono essere personalizzati ed estesi, e ne possono esserne creati di nuovi per adattare al meglio VSTS alle proprie esigenze. In generale, il consiglio è sempre quello di cercare di sfruttare al massimo quanto offerto di default con lo specifico process template e solo se veramente indispensabile effettuare specifiche personalizzazioni. Ciò riduce il rischio che futuri aggiornamenti possano invalidare quanto personalizzato o non funzionare correttamente.
A livello management gli item afferenti al IT Portfolio Management, ovvero le Epic e le Feature, vanno a definire le iniziative annesse al singolo prodotto e sono gestiti principalmente attraverso specifiche Kanban Board.
Epic Kanban Board
Feature Kanban Board
Le Kanban possono essere completamente personalizzate, consentendo di aggiungere, ad esempio, la specifica Definition of Done per singola colonna e il relativo Work in Progress Limit.
Personalizzazione della Kanban Board
Sia le Epic che le Feature dispongono di specifici dettagli che consentono di caratterizzarli in funzione sia degli obiettivi di Business che delle esigenze tecnico/tecnologiche. Non andremo ad analizzare i dettagli nello specifico perché ciò richiederebbe una trattazione specifica che esula dallo scopo dell’approfondimento in corso. Inoltre, molte informazioni a riguardo, sono presenti nell’ottima documentazione ufficiale a riguardo [Backlog and Work Items].
Epic Details
Fondamentale, invece, è sottolineare come VSTS (in chiave Agile) sposi l’organizzazione a Feature Teams, dove i membri del team stesso possono organizzare e gestire il proprio (Team) Backlog, composto primariamente da Story, Task e Bug.
Team Backlog
Anche in questo caso la gestione tramite Kanban consente di sfruttare al meglio la logica di Visual Management e avere sempre una fotografia aggiornata dello stato di avanzamento delle attività.
Per chi preferisce utilizzare una Kanban/Scrum Board “fisica” e vuole evitare di dover lavorare su entrambe, aggiornandole di conseguenza, può sfruttare una utile estensione del marketplace chiamata Agile Cards.
Agile Cards
Una volta definiti i Product Backlog Item (PBI) è possibile stampare le relative card, utilizzarle su una Kanban/Scrum Board “fisica”, fotografarne i cambiamenti e lasciare che VSTS si aggiorni di conseguenza! La “magia” avviene tramite una serie di “tag” posti su ogni singola card.
Nel caso il prodotto contempli più progetti e, quindi, più team specifici, il relativo lavoro può essere organizzato in modo che gli stessi abbiano in comune il Product Backlog ma al contempo lavorino su specifici Team Backlog correlati ad esso. Qui si entra nel campo dell’Agile Scaling dove troviamo framework metodologici come: Scaled Agile Framework (SAFe), Disciplined Agile 2 (DA 2) e LeSS.
Agile Scaling
Per adattare VSYS a questo scenario, è necessario creare più Feature Team ed associare ad ognuno di essi specifiche Work Area (derivate da quella base del progetto). In tal modo gli item identificati durante planning, in funzione a specifici goal, potranno essere associati ai diversi team coinvolti in modo esclusivo.
Multi Feature Team
Le attività di sviluppo dei diversi team afferenti allo stesso prodotto possono essere visualizzate e ottimizzate tramite l’estensione Delivery Plans, consentendo di avere un quadro a livello Program, così come inteso dal framework Scaled Agile Framework.
Delivery Plans
All’interno dei Project Template Agili (ovvero dei modelli di processo predefiniti, uno generico per Agile e uno più specifico di Scrum) oltre agli item di sviluppo evolutivo visti fin ora, sono presenti anche il già citato Bug e l’item di Impediment, che rappresenta un problema bloccante e come tale, ovviamente, non viene riportato nel Product Backlog non essendo un elemento di pianificazione. Entrambi sono estremamente importanti per consentire al team di attivare azioni di miglioramento, potendo, ad esempio, misurare il numero di problemi in ogni increment o i diversi impedimenti che si riscontrano durante le attività giornaliere. In particolare, è utile applicare la regola dell’80/20 (validata in modo empirico) che spinge il team a dedicare il 20% del proprio tempo a ottimizzare quanto realizzato, riducendo costantemente il Debito Tecnico.
Prima di chiudere la trattazione dell’area Agile Planning, è utile evidenziare che la pianificazione avviene al livello minimo indispensabile per dare il là alle prossime attività di sviluppo, in perfetto stile Agile/Lean. Questo perché la stessa viene rivista, approfondita ed estesa ad ogni iterazione o al raggiungimento dei goal specificamente settati per le attività in corso.
Nel prossimo appuntamento ci concentreremo sull’area Develop & Test, andando a vedere come VSTS e VS IDE supportano egregiamente le attività operative di realizzazione concreta della soluzione.
Stay tuned :-)
