DA2, Release Management

da2 release managementL’azione di Deployment è l’azione che mette la soluzione realizzata “nelle mani” del cliente, rappresentando il momento in cui il proprio lavoro di Delivery è realmente completato.

Non stupisce che il processo di Release Management (RM) è estremamente delicato e che diverse metodologie Operational-oriented (si pensi ad ITIL) lo contemplino direttamente, mettendolo al centro delle proprie azioni.

DA2 non è da meno, prevedendo un esplicito processo di RM che però è border-line rispetto all’approccio Disciplined DevOps.

da2 rm

Questa scelta diventa estremamente chiara se ci si ricollega alle strategie di adozione di DevOps all’interno della propria organizzazione, rispondendo anche all’implicita domanda: “ma a cosa serve un’azione di RM se faccio DevOps?”.

Come abbiamo già ampiamente discusso, la Cultura DevOps va costruita progressivamente e contestualizzata, richiedendo, tipicamente, strumenti che consentano di gestire il cambiamento senza incidere sugli SLA offerti ai propri clienti.

In particolare, un’azione di RM, affidata ad uno specifico team di riferimento, consente di supportare il deployment attraverso una serie di strategie specifiche in riferimento al contesto operativo:

  • Complex Operational Infrastructure. Quando la propria catena di deployment è particolarmente complessa e laboriosa (si pensi alla presenza di diversi stack tecnologici o a configurazioni d’ambiente particolarmente fantasiose), il rischio che qualcosa non vada a buon fine è estremamente alto, rendendo indispensabile una corretta programmazione delle fasi di release;
  • Many Delivery Teams working in parallel. Quando la soluzione è composta da più progetti, ognuno affidato a team diversi, ogni specifica azione di team-deployment va correlata agli artefatti complessivi, valutando gli impatti contingenti. Chiaramente, maggiore è il numero di team coinvolti, maggiore è il rischio che qualcosa possa andare male;
  • IT delivery teams needs help. Questa condizione si verifica spesso quando il team di delivery è poco esperto, o di nuova formazione, e necessita di essere supportato nella comprensione e nell’attuazione della catena di deployment. In questo caso l’RM team si comporta da Coach trasferendo know-how e collaborando per rivedere il processo anche in funzione delle specialità delle nuove risorse.

Se si esclude l’ultimo punto, legato più ad un fattore di crescita di team che al contesto operativo, gli altri due punti sussistono anche se l’IT adotta un approccio full DevOps. La Complessità può essere ridotta investendo nel “pagamento” del relativo Debito Tecnico, mentre la gestione Multi-team è difficilmente abbattibile se la soluzione è estremamente articolata e complessa.

In generale la funzione di Release Management in un contesto DevOps viene progressivamente assorbita dal team stesso, ma è estremamente utile avere un supervisor di coordinamento per le situazioni multi-team in modo da evitare spiacevoli problemi e frequenti condizioni indesiderate.


Stay tuned!

AgileIoT, TFS 2015 Process Template

Come stiamo scoprendo nei vari post, AgileIoT è una “proposta metodologica” per approcciare alla complessità di una soluzione IoT industriale.

Per quanto le metodologie debbano considerare gli strumenti afferenti come “facility”, e per essere comprese e padroneggiate bisogna saperne fare a meno, è innegabile che il loro utilizzo consente di semplificare di molto le attività di gestione di un progetto, soprattutto se si hanno più Team delocalizzati tra loro o, addirittura, nei suoi singoli membri.

In quest’ottica AgileIoT propone un Process Template custom per Microsoft TFS 2015.

La scelta di TFS non è causale e, non poteva essere altrimenti, visto il background degli autori che utilizzano quotidianamente (anche se spesso in modo non esclusivo) la soluzione ALM di Microsoft.

Il template richiede TFS 2015, l’ambiente on-premise di Redmond che, ad oggi, rispetto all’edizione cloud, consente di personalizzare il tipo dei Work Item disponibili, creandone di nuovi laddove se ne ravvisa l’esigenza, come nel nostro caso.

agileiot process template

AgileIoT TFS Process Template

In particolare, due sono gli aspetti su cui il lavoro di personalizzazione si è concentrato:

  • Work Item type;
  • Iteration path.

Per modellare l’Iteration Path, si è proceduto a modificare quello base adattandolo alle tre fasi primarie di AgileIoT: Prototyping, Engineering e Deployment.

I Work Item type, invece, sono stati specificamente creati in funzione degli artefatti previsti da AgileIoT. Vale la pena, a questo punto, riprendere proprio tale aspetto della metodologia, descrivendo gli artefatti base, gerarchicamente rappresentati nella figura seguente:

value signal slot

Work Item type

Abbiamo quindi:

  • value story le Value Story, che enfatizzano il Valore in funzione del cliente, cogliendo aspetti trasversali che guidano e condizionano lo sviluppo. Per chiarire il concetto facciamo un esempio: si immagini di progettare una soluzione che monitori il traffico in una determinata strada. Per fare ciò si andranno ad osservare diversi fattori come: il numero di auto in transito nell’unità di tempo, la qualità dell’aria, il corretto funzionamento dei semafori, ecc. Ognuno di tali fattori è appunto una Value Story. Le Value Story sono accompagnate dai Criteri di Accettazione, ovvero una esplicita definizione del comportamento atteso nelle condizioni di esercizio previste. Essi impattano sia sugli aspetti tecnici, ad esempio test funzionali, che su quelli di supporto, ad esempio l’aggiunta delle relative specifiche al datasheet;
  • signal il Signal, l’elemento su cui si concentra l’attività dei Maker, in particolare dell’ST2. Si tratta di un’attività descrivibile in funzione di elementi di input/output dei dispositivi IoT specifici, suddivisibile in due categorie, sempre in funzione della “T” e della “I”:
    • Device Signals, ovvero i Signal specificamente orientanti allo sviluppo degli Smart Thing, che possono essere identificati in:
      • Measure Signals, sono i Signal che hanno come scopo primario quello di misurare parametri esterni come sensori ambientali. In questo caso l’input è il dato del sensore e l’output è il valore letto, eventualmente normalizzato;
      • Act Signals, sono i Signal caratterizzati da attuatori che effettuano un’azione in funzione dei parametri rilevati. In questo caso l’input è il dato del sensore di controllo e l’output è l’esito dell’azione/correzione effettuata in funzione di esso.
    • Cloud Signals, sono i Signal focalizzati sugli aspetti di elaborazione/analisi/processing in Cloud:
      • Data Signals, sono i Signal legati all’elaborazioni di dati, che rappresentano l’elemento principale del computo stesso;
      • Event Signals, sono i Signal legati ad un evento/allarme che non hanno focus su dati specifici.

Restando sull’esempio del monitoraggio del traffico stradale, prendiamo la Value Story relativa al numero di auto in transito nell’unità di tempo. Rispetto ad essa potremmo ipotizzare di avere i seguenti Signals: Smart Thing che conta il numero di veicoli in transito (device signal); Invio dei dati al sistema di raccolta e gestione (device signal); Analisi e gestione dei dati in formato aggregato (cloud signal);

Essendo i Signal rappresentativi di una esigenza di business, tale distinzione può essere ritenuta anche solo letteraria, non evidenziandola direttamente, come invece suggerito di seguito per gli Slot.

  • slot gli Slot, sono l’unità minima di lavoro, possibilmente specializzata per singola area applicativa: hardware [slot], firmware [slot], service [slot] e cloud [slot]. Per ottenere una chiara rappresentazione visiva dell’area afferente, è importante utilizzare colori differenti per rappresentare gli Slot stessi. Specificare la tipologia di Slot è molto utile per gestire le diverse specificità: ad esempio, fare una modifica dell’hardware a progetto inoltrato è molto rischioso e costoso, fattore che potrebbe spingere a ragionare su una possibile risoluzione del problema basata sulla modifica del firmware. In questo caso si adotterebbe una soluzione probabilmente meno efficiente, ma riducendo il rischio di aumentare drasticamente i costi ed allungare i tempi.

Tutte le personalizzazioni si riflettono anche sugli aspetti operativi e sulle metriche di progetto: è possibile, ad esempio, effettuare le query in funzione degli specifici work item e degli specifici path.

agileiot process template query

AgileIoT Work Item query da Visual Studio

Il process template è gratuitamente scaricabile da GitHub all’indirizzo: https://github.com/AgileIoT/TFS2015PT.

Aspettiamo i vostri feedback!!!

Update VSTS – 6 Maggio

Un altro aggiornato è stato fatto a Visual Studio Team Service il 6 Maggio, come sempre l’aggiornamento non è disponibile a tutti gli account immediatamente, per cui ho deciso di attendere qualche giorno prima di fare il post.

Anche in questo aggiornamento troviamo importanti novità, che il team spesso prende da UserVoice . In questa release finalmente abbiamo la possibilità di personalizzare il Process Template includendo campi booleani che vengono rappresentati come Check-Boxes.

Checkbox control added to a work item

Altre modifiche cosmetiche sono state fatte alle board, in cui è possibile ora scegliere se vedere o meno le annotazioni.

Un’altra interessantissima modifica è la possibilità di personalizzare le tile di tipo Query nelle Dashboard, cambiando i colori di sfondo in maniera condizionale. Ad esempio nella figura sottostante è stato chiesto di visualizzare il background in rosso se il numero di Bug Attivi eccede il valore di 40.

Selecting rules and colors for Query Tiles

Per quanto riguarda il Release Management, è stata introdotta la possibilità di utilizzare un repository Git o TFVC come sorgente di artefatti. In questo modo non è più necessario essere costretti a pubblicare tramite build script o altri artefatti per poterli usare in una definizione di RM.

Sono state introdotte inoltre REST API per interagire con il Release Management, in modo da rendere semplice interagire tramite codice con RM.

Come sempre ci sono altre modifiche minori e potete leggere tutta la lista nel sito ufficiale di Visual Studio.

Gian Maria.

Agile@School – quinta puntata del 16/04/2016

E’ arrivato il momento di vedere il software prodotto, almeno durante l’incontro, purtroppo non possiamo ancora mostrare il tool in questo blog.
L’applicazione web su cui stanno lavorando i ragazzi sta arrivando verso la fine degli sviluppi. Non è così bella da vedere, è molto “developer” ma, da questo sprint, penseremo a come applicare cambiamenti grafici per renderlo gradevole alla commissione di esame.
Ad ogni modo, la review che abbiamo fatto è stata molto interessante. Tutto, o quasi, era funzionante, e l’umore era alto, come si può notare anche da questa foto:


Davide (il ragazzo in piedi davanti alla lavagna) è in posa, lo ammetto. Ma credetemi che l’umore è alto!

Come dicevamo, il software gira, la classe ha scovato ed aggiunto al backlog un paio di importanti bug che verranno presi in carico probabilmente nel prossimo sprint. Purtroppo questi bug sono emersi solo durante la review, il che mostra che il team non ha fatto sufficienti prove durante lo sviluppo o nella fase di test (che forse è proprio mancata). Per mancanza di tempo, purtroppo, non potremo insegnare ai ragazzi l’automazione dei test, e quindi non potremo nemmeno accennare in generale il concetto di integrazione continua, ma ci sta, almeno per ora. Di certo è materiale da retrospettiva.

Alla fine della review, abbiamo affrontato la prima retrospettiva tramite il diagramma Starfish:

This particular retrospective technique helps people by getting them to reflect on varying degrees of things that they want to bring up, without having it fit into the black or white category of ‘What Went Well’ or ‘Not So Well’ so I think it scales a little bit better

Ed ecco il risultato


Gli elementi sono:

– Start ognuno deve fare il suo changeset ed associarlo al task
– Start commentare il codice
– Start aggiungere documentazione tecnica e funzionale
– Start test funzionali
– More Of upload e pin dei media su slack
– More Of più punto di contatto tra le classi (i ragazzi fanno parte di due classi diverse)
– More Of utilizzo di slack, è comodo
– Less Of lavoro non notificato agli altri
– Stop fare eccessivo rumore con @here e @channel su slack (allertano tutti praticamente)
– Keep Doing canali basati su PBI di VSTS

Gli studenti vedranno l’importanza di questo meeting in qualche giorno, quando i problemi si risolveranno grazie alle azioni intraprese ai fini di non ridurre la produttività del team.
Nel prossimo sprint (che stiamo disegnando) andremo a gestire i seguenti nuovi “tipi” di attività:

Testing
User’s manual
Technical documentation
Business presentation (vorrei far capire l’importanza di presentare bene un progetto)
Grafica e design (logo, colori, temi, brand, ecc.)
Stay Tuned! 

A proposito della Build di Xamarin con gli Hosted Agent di VSTS

Venerdì scorso (22/04/2016) durante un’evento organizzato da DotNetToscana ho avuto modo di parlare, tra le altre cose, della build di applicazioni sviluppate con Xamarin utilizzando gli Hosted Agent di Visual Studio Team Services
Per poter far funzionare il tutto, nella build definition ho dovuto inserire due task relativi alla Xamarin License: uno che attivava la licenza ed un altro che, dopo la compilazione, la disattivava. 
E proprio riguardo a questi due task, c’è una piccola grande novità: ora non sono più necessari
Con il deploy che hanno fatto qualche giorno fa, infatti, gli Hosted Build Agent hanno già una loro licenza interna che viene attivata automaticamente nel momento in cui devono compilare i progetti Xamarin. 
Riepilogando, se avete o dovete fare delle build definition per Xamarin (ed usate gli Hosted Agent) ora non dovete più aggiungere i task di attivazione e disattivazione della licenza. 
Buona build a tutti :)

AgileIoT, EVK and BOM

L’ascesa del mondo dell’Internet of Things ha comportato la nascita di una miriade di micro-controllori programmabili alla portata di chiunque voglia sperimentare e toccare con mano il futuro della Rete.

Arduino, Raspberry PI, BeagleBone, sono solo alcune delle soluzioni più note che possono essere raggruppate sotto il cappello terminologico EVK: Evaluation Kit. Si tratta di strumenti preziosi, fondamentali per la cerimonia di fast-prototyping al centro della fase di prototyping di AgileIoT.

bigpicture 091 prototyping

In pratica, grazie agli EVK è possibile sperimentare velocemente la propria idea di business (Solution Vision), andando a ridurre il rischio annesso alla sua implementazione grazie a “prove” concrete della sua reale sostenibilità.

Il fast-prototyping si basa sul ciclo Make-Measure-Learn (MML), pensato per ottenere rapidamente una soluzione funzionante che sia in grado di validare le ipotesi portanti e porre dei punti di riferimento per quanto riguarda gli aspetti di: Energy, Hardware, Code, Data Flow, Cloud, Security e Delivery.

 

mmlloop

Make Measure Learn

La selezione dell’EVK più idoneo passa, in primis, dalla scelta della CPU/MCU, dopodiché si inizia a “costruire” il prototipo lavorando sugli altri componenti (es: RAM, USB, ecc.), affiancandolo con i servizi Cloud centrali.

L’utilizzo di questi kit continua anche durante gran parte della fase di Construction, in cui la soluzione nel suo complesso (Hardware, Software e Cloud) viene realizzata, consentendo di paralizzare le attività in attesa che venga progettato lo smart thing industriale e definita la relativa Bill of Materials (BOM), sulla cui base verranno realizzati i primi prototipi e poi l’hardware finale da installare negli ambienti di riferimento per la Soluzione.

 

Di questo e molto altro parleremo a Napoli alla Microsoft Embedded Conference 2016. Trovate tutte le informazioni e le modalità di iscrizione sul sito dotnetcampania.org.

Live update nella Kanban Board in VSTS

Una delle ultime novità per la Kanban Board in VSTS offre la possibilità di abilitare il “live update” per la board, attivabile selezionando una semplice icona a fianco delle impostazioni.

image

Figure 1: Icon to enable live update to Kanban Board

Una volta abilitata, la board rifletterà in tempo reale ogni cambiamento dei work item che sono rappresentati nella board stessa. Questo significa che modificando o riordinando o cambiando colonna o in generale modificando qualsiasi proprietà di un Work Item da qualsiasi sorgente (web, Visual Studio, Integratione con Excel, etc), i cambiamenti si rifletteranno immediatamente nella board.

Questa possibilità è interessante in accoppiata con la visione in full screen (l’icona a destra dei settaggi), che permette di visualizzare la board a pieno schermo. Questa funzionalità, assieme al Live Update, permette di mettere un monitor o televisione che mostra sempre in tempo reale la situazione della board.

Questa funzionalità è per ora solamente disponibile per VSTS.

Gian Maria.

DA2, IT Delivery: Program Management

Diciamolo: quando in Agile compare la parolina “management” spesso si osservano molte persone storcere il naso, immaginando ancora che si tratti di un retaggio del passato e che vada “rimosso” o, peggio ancora, “nascosto.”

Eppure l’esperienza quotidiana prima, e da “agilisti” poi, ci dimostra che la governance dei prodotti e dei processi, nonché dell’intera organizzazione aziendale conta quasi sempre più delle capacità tecniche del singolo.

It’s the Whole System, not the singularity” potremmo esprime così la “regola del 95/5” di Deming che enfatizza l’importanza del sistema aziendale (formale, a soprattutto informale) rispetto al singolo… System Thinking… Lean… DevOps the first way!

da2 pgmo iconDetto questo non deve sorprendere che DA2 identifichi nell’area di Delivery la funzione di Program Management, meglio in realtà Program Coordinator, anche se quest’ultima terminologia è meno comune e richiede a sua volta una transizione semantica che è meglio ottenere progressivamente con l’adozione diretta.

Ma perché dovremmo avere la necessità di istituire tale funzione? La risposta più evidente è la complessità e la dimensione che un prodotto software oggi può raggiungere, rendendo impossibile avere un singolo team che se ne occupi e coinvolgendo molti aspetti trasversali non strettamente tecnico-tecnologici (sales, market, financial, customer care, ecc…).

Questi progetti tendono spesso a diventare estremamente burocratizzati e il macro-team, a sua volta, tende a crescere in modo importante. Entrambi gli aspetti sono da mitigare, partendo proprio dalla dimensione del team che, come ormai abbiamo imparato, deve essere sufficientemente piccolo da potersi auto-organizzare al suo interno e adottare le pratiche di cui tanto discutiamo.

In tal modo si ottengono una serie di vantaggi chiave:

  • Reorganize the problem into a collection of smaller problems. I team possono concentrarsi su specifici boundary all’interno del contesto complessivo sotto la governance del PgMO (Program Management Office, da non confondere con PMO – Project Management Office);
  • Reduce the problem. Se i problemi non sono riferiti alla Big Picture ma ai specifici Goal/Feature è possibile gestirli in modo più efficace, eventualmente rivedendo le priorità o rimuovendone gli elementi costituenti;
  • Address your organization’s culture. Non basta “fare Agile” ma bisogna “essere Agile”, il che significa realizzare un profondo cambiamento culturale e… gestirlo!
  • Organize the large team into a collection of smaller teams. Come evidenziato, meglio piccoli team dinamici e collaborativi che un unico grande team burocratizzato.

Quest’ultimo punto nasconde anche un’ulteriore elemento da evidenziare: la revisione dell’assegnazione dei bonus e premi aziendali. Nell’approccio tradizionale, le aziende sono portate a riconoscere un bonus maggiore ai manager che gestiscono un numero maggiore di persone e team grandi. Bisogna quindi rivedere questa politica seguendo, ad esempio, un’assegnazione “Achieved Goal based” o “Aware Contribution”.

Ma come costituiamo il nostro PgMO?

Come sempre nessuna soluzione è universalmente corretta, anche se un valido approccio è quello di creare una board composta dai singoli Product Owner responsabili dei sotto-prodotti (indicando con sotto-prodotti la suddivisione Goal-Driven del sistema complessivo) che più o meno democraticamente eleggono il “Chief”, anche a rotazione.

da2 pgmo team

 PgMO board

Si tratta di una scelta tutto sommato “naturale”: essendo il PgMO un gruppo di coordinamento ed allineamento, chi meglio dei singoli Product Owner possono renderlo efficace, avendo, per ognuno dei propri team, la relativa visione d’insieme di quanto realizzato e dove bisogna spingersi.

Questo anche in relazione alle principali attività di cui il PgMO si occupa: Allocate work, Prioritize work, Organize teams, Coordinate teams, Coordinate Schedules, Scheduling solution releases, Negotiate functional dependencies, Negotiate technical dependencies e Govern the program. In pratica lo stesso diventando un po’ il nodo centrale di una fitta rete di relazioni tra le diverse funzioni aziendali, definito da DA2 come Program Mangement External Workflow, con “external” ad indicare la non diretta appartenenza all’ambito IT.

da2 pgmo external workflow

Program Management External Workflow

In sintesi, è utile sottolineare come la funzione di PgMO è una funzione cruciale per il successo di prodotti complessi e di ampie dimensioni, mitigando il rischio di fallimento e creando un centro nevralgico di coordinamento che aumenta sensibilmente le opportunità di successo nelle proprie iniziative di business.

Stay Tuned!

Configurare TFS 2013+ con il Team Field

In alcuni articoli passati ho spiegato come configurare TFS o VSTS per utilizzare un solo Team Project, dividendo il lavoro logico con il concetto di Team in TFS. In tutti gli articoli l’approccio utilizzato è stato quello di configurare per i vari Team L’area Path e l’iteration path assegnati, in modo che ogni Work Item appartenesse al backlog di uno o più team in base all’area path o all’iteration Path.

Se avete TFS on-premise, dove potete configurare il process template, potete adottare una soluzione che spesso porta ad una configurazione più chiara, ovvero modificare il Process Template per far aggiungere un campo esplicito che determina l’appartenenza di un Work Item ad uno o più Team. Questo approccio viene chiamato Team Field e la sua configurazione viene descritta direttamente in MSDN.

Il processo da seguire è molto semplice, si crea una GLOBALLIST con la lista dei vari team, si configurano tutti i Work Item che sono visualizzati nelle varie board aggiungendo un campo custom ed infine si configura il processo per utilizzare tale campo invece dell’Area ed Iteration path.

Una volta effettuata questa configurazione, per ogni Team del vostro Team Project si dovranno scegliere i valori di tale campo per cui un Work Item è associato al team. Questo permette quindi di creare anche un Team chiamato Admin che ha associati tutti i valori possibili per tale campo, in modo che questo Team possa vedere tutto nella board.

A questo punto per assegnare un Work Item ad un particolare team si può semplicemente cambiare il valore del Team Field, rendendo il processo di assegnazione sicuramente più esplicito.

Gian Maria.

Agile@School – quarta puntata del 18/03/2016

Lo sprint 2 è stato completato con successo. Questa è stata un’ottima notizia, e quando ho sentito la frase pronunciata dai ragazzi ho provato una sensazione di benessere che non mi aspettavo. Certo, abbiamo sbagliato qualcosa, ci siamo dimenticati qualche iter o elemento, ma ci sta, siamo in fase di apprendimento, non solo per quello che riguarda la formazione dei ragazzi, ma anche per il progetto in sè. Essendo in fase sperimentale, dobbiamo capire i problemi anche dall’alto e non solo nel team di sviluppo.

Un mese fa ho lasciato i ragazzi con cinque PBI da implementare ed ecco come me li trovo dopo 20 giorni, considerando una capacity molto bassa di ogni sviluppatore:
Grande risultato! Ma non è tutto.. I ragazzi hanno anche associato i changeset ai task ed hanno aggiunto allegati laddove necessario.
E pensare che avevo il sospetto, prima di iniziare, che un progetto del genere potesse fallire. Ho cambiato idea, vedo proattività negli studenti, vedo gli sforzi che fanno e vedo pure quanto si impegnano ad usare gli strumenti. Nel tempo, anche slack è cresciuto. Siamo arrivati ad aggiungere un canale per ogni PBI che si affronta e abbiamo iniziato a “pinnare” media sui canali, anche se poco spesso per ora: 


Gli strumenti sono utilizzati, ma non abbiamo di certo ignorato le cerimonie. Nell’ultimo incontro infatti abbiamo affrontato lo stand up meeting. Per essere sincero non mi aspettavo tanta disciplina ed ordine, quasi meglio dei team di sviluppatori professionisti!

Nel prossimo incontro andremo ad affrontare le cerimonie finali dello sprint. Vedremo come funziona una review, affronteremo una retrospettiva utilizzando il diagramma Starfish (grazie Felice) ed inizieremo ad aggiungere elementi non ancora visti, come la parte di design, di documentazione e di test. Intanto i nostri neo sviluppatori continueranno ad implementare le parti mancanti del progetto “Annuario Studenti”.

Speriamo di poter vedere qualcosa nel prossimo mese, stiamo raggiungendo il giorno dell’esame e dovremo impacchettare il tutto per bene, al meglio delle nostre possibilità.

Stay tuned!