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 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:

Work Item type

Abbiamo quindi:

•  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;
•  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.

•  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 Work Item query da Visual Studio

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

Aspettiamo i vostri feedback!!!