Priorizzare il proprio lavoro: Time Management Matrix

Tutti gli approcci Agile/Lean based spostano il focus dalle fasi al bouquet di funzionalità da realizzare per soddisfare un’esigenza del cliente. Ciò si traduce praticamente in un Product Backlog che contiene i work item su cui concentrare le nostre attività.

Tali work item vanno ordinati (priorizzati) per Valore… ma qui sorge una domanda fondamentale: “cos’è il Valore nel nostro contesto?”.

Il desiderata dell’utente? Una iniziativa mirata a ridurre il rischio per il progetto? Una serie di storie pensate per chiarire gli aspetti UX/UI?

Tutte queste declinazioni sono una valida interpretazione del concetto di Valore, per cui può diventare estremamente difficile ordinare il nostro backlog, visto che le variabili in gioco potrebbero aumentare in modo considerevole.

Un interessante framework che può essere utilizzato per dare una prima connotazione di Valore ai nostri work item è rappresentato dal Time Management Matrix (TMM) di Stephen Coveys, a sua volta formalizzazione di un sistema di supporto strategico utilizzato dal generale Dwight D. Eisenhower, successivamente presidente degli USA.

tmm 1

Time Management Matrix

Lo scopo è quello di inquadrare le attività in funzione di due assi di rilevanza specifica: Urgenza e Importanza. Questa scelta è decisamente ovvia, se si pensa che spesso, ogni richiesta del business è Urgente ed Importante allo stesso modo, e il tentativo è quello di porre sempre le nuove attività in cima a quelle in essere, andando a causare una saturazione di gestire efficacemente il loro completamento. Questo perché, spesso, si discute in termini di capacità (Capacity) totale del team e non di un efficace gestione del flusso (Throughput) operativo.

L’esempio classico per spiegare questa differenza è dato dalla similitudine con l’autostrada:

road capacity throughput

se la richiesta è inferiore alla capacità, allora le autovetture hanno lo spazio (slack) per avere un flusso sostenibile senza creare traffico. Viceversa, se la richiesta è uguale o addirittura maggiore alla capacità viaria, le autovetture resteranno incolonnate causando una congestione del traffico.

La TMM è uno strumento che consente di inquadrare i diversi work item in quattro fasce specifiche:

  • Urgente e Importante, sono i task più rilevanti nel breve periodo;
  • Importante ma non Urgente, sono i task più rilevanti nel medio-lungo periodo;
  • Urgente ma non Importante, sono i task che vanno fatti ma possono essere delegati;
  • Non Urgente e non Importante, sono i task da eliminare.

 

tmm 2

TMM Actions

Se da un punto di vista operativo, il primo quadrante cattura subito la nostra attenzione, il secondo quadrante è invece quello strategico, poiché contiene i task più importanti per la continuità del nostro business.

In pratica il primo quadrante è riconducibile all’Iteration/Sprint backlog, mentre il secondo appartiene a quello che è il Program Backlog e il Product Backlog, che trasformano le iniziative di business in azioni concrete.

Chiaramente il focus di interesse è proprio sul secondo quadrante, in quanto gestendo opportunamente le relative attività è possibile evitare che esse si spostino al primo trasformandosi in “urgenze” che vanno a minare la stabilità e il ritmo di lavoro raggiunto.

Il terzo e quarto rappresentano genericamente uno spreco da ridurre (terzo) e da eliminare (quarto). Le relative attività vanno però tenute in costante considerazione perché incidono sulla pianificazione generale. Facciamo un esempio: se non si riesce a sfoltirli, parte della giornata lavorativa, anche se minima, sarà chiaramente dedicata ad essi, per cui non sarà possibile stimare il tempo di una iterazione basandosi sulle canoniche 8ore lavorative, ma bisognerà ragionare sulle 7ore, o ancora meno, in cui effettivamente ci si dedica ai work item del primo e del secondo quadrante.

La difficoltà intrinseca di questo framework è, chiaramente, quella di riuscire a distinguere tra urgenza e importanza e, come tutte le cose, il miglior modo per affinare le proprie capacità è quello di esplorare e procedere sul campo.

Stay tuned!

Aggiornamento VSTS del 17 giugno

Questa volta l’aggiornamento è stato più rapido del previsto, il 17 giugno abbiamo avuto un altra wave di aggiornamenti su Visual Studio Team Service. Come sempre potete leggere tutti i dettagli nel blog ufficiale, qui vi farò un riassunto delle mie nuove funzionalità preferite.

Innanzitutto se avete un team corposo ed usate GitFlow è possibile che il numero delle branch in Git diventi elevato, per questo nel tab delle branches è ora disponibile una sezione “my branches” dove vedrete le branch che avete creato voi o a cui avete contribuito. In questo modo è immediato distinguere le vostre branch da quelle di altri componenti del team.

Branch picker featuring Mine

Un’altra importante novità è un nuovo header per la form dei Work Item, in particolare è ora presente in molta evidenza il bottone “Save & Close” che sicuramente è quello più utilizzato, dato che molto spesso dopo che si apre un Work Item se lo si modifica si vuole semplicemente chiudere salvando le modifiche effettuate.

Improved work item header

Per tutti coloro che usano le funzionalità di Test ed in particolare le exploratory sessions, è ora finalmente possibile avere una visualizzazione chiara di tutte le exploratory session effettuate sul progetto.

Insights in exploratory testing

Nell’addin di Chrome è ora possibile anche richiedere la registrazione del desktop da includere in un eventuale bug.

Un’altra interessantissima funzionalità è la possibilità di vedere l’andamento dei test per singole branch, questo è molto importante perché cosi si ha la chiara indicazione della qualità delle varie branch

History tab in the result summary page

La funzionalità sicuramente più corposa è però data dalla possibilità di personalizzare il Process Template introducendo stati custom. Questa funzionalità ha un intero post dedicato all’argomento, e costituisce un ulteriore importante passo verso la parità di funzionalità tra VSTS e TFS. Questo permette quindi di avere colonne personalizzabili nella Task Board, grazie alla possibilità di aggiungere stati al Work Item di tipo Task. Non è ancora possibile personalizzare in maniera avanzata le transizioni tra stati (con regole o decidere quali transizioni sono possibili), ma già questa funzionalità rende possibile personalizzare VSTS in modo che si adatti maggiormente alle vostre esigenze.

Per chi sviluppa Java invece è ora possibile effettuare analisi di codice direttamente da un task Maven, senza la necessità di impostare un server Sonar Qube, anche questa funzionalità è abbastanza corposa e descritta in dettaglio in un post dedicato.

Vi invito comunque a leggere il post ufficiale in modo da vedere tutte le novità disponibili.

Gian Maria.

AgileIoT Kanban::Board: il workshop a BetterSoftware

Lunedì ho avuto il grande piacere di partecipare nuovamente come speaker a BetterSoftware, che quest’anno si è presentato al pubblico, sempre numeroso e competente, nel nuovo format “workshop based”.

Come accennato nel post precedente, il mio workshop puntava a far toccare con mano la Kanban::Board di AgileIoT, evidenziando l’efficacia del WorkPivot e del D-ARCH.

Ebbene,  i 4 team pratecipanti (da 5 e 6 persone) si sono divertiti nel:

“realizzare un sistema intelligente di pubblicità da posizionare su strutture di piccole dimensioni come, ad esempio, le statue. Il messaggio doveva essere visibile dalle diverse angolazioni ed illuminato adeguatamente, gestendo in modo efficiente l’aspetto energetico al fine di consentire un abbattimento dei costi e consentire l’installazione in aree anche senza fornitura elettrica.”

Ovviamente non sono stati utilizzati dei veri EVK e laptop, ma la prototipazione è avvenuta tramite una “torcia a mano” di origine cinese, mentre alla consegna del BOM, l’external PO Manufactoring forniva una torcia decisamente più industriale.

Particolare attenzione è stata posta nel tracciare il lavoro attraverso la Kanban::Board, evidenziando anche i disallineamenti tra lo stato reale del lavoro e quanto evidenziato visivamente, con tutti i problemi derivanti.

In particolare un team aveva praticamente terminato tutta la componente Software/Firmware e Cloud, mentre la parte hardware era bloccata: questa situazione può spingere, ad esempio, ad intervenire sul know-how in ambito hardware, avendo ottenuto come risposta “non siamo in grado di rimontare la torcia”.

Un workshop ricco di spunti per i quali i ringraziamenti vanno ovviamente ai partecipanti che si sono sbizzariti, soprattutto nel creare la struttura di supporto all’ADV, come potete vedere dalle foto seguenti. Un ulteriore e doveroso ringraziamento agli amici di BetterSoftware per l’alto livello dell’evento e l’ottima organizzazione.

Al prossimo anno!

2016 bsw16 agileiot workshop 1 2016 bsw16 agileiot workshop 2

2016 bsw16 agileiot workshop 3 2016 bsw16 agileiot workshop 4

2016 bsw16 agileiot workshop 5 2016 bsw16 agileiot workshop 6

2016 bsw16 agileiot workshop 7

Potete trovare le slide del workshop qui: http://www.slideshare.net/felicepescatore/advtorch-agileiot-bettersoftware-2016-workshop

Stay tuned!

Usare Azure come PAAS e non come IAAS

Si parla tanto di Cloud in questi periodi, e spesso purtroppo l’adozione del Cloud non viene fatto, a mio avviso, nel modo giusto.

Ad esempio, parlando di Azure, se si inizia l’approccio spostando e creando Virtual Machines su Azure il risultato non sempre è piacevole. Se una azienda ha già il suo sistema di virtualizzazione (vmware o Hyper-V) l’avere le VM su Azure non da vantaggi tangibili, soprattutto considerando la banda che abbiamo in Italia.

Se si vuole veramente avvantaggiarsi del Cloud, bisogna approcciare il problema da un punto di vista differente. Per fare un esempio prendo un post scritto dal caro amico Matteo (http://mattvsts.blogspot.it/2016/06/a-simple-vsts-based-pipeline-for-java.html) che spiega come creare una pipeline di Build –> Test –> Release di una app Java in un Azure Web Site.

In questo caso ci stiamo avvantaggiando del cloud in molti punti, e l’esperienza di Matteo è stata molto positiva dal punto di vista dell’operational. Pur non essendo un esperto in java, ma avendo semplicemente un progetto Java con una build di Maven è riuscito in poco tempo a mettere in produzione il prodotto automatizzando tutto il processo.

I vantaggi sono molti

1) Usiamo VSTS, per cui non più sorgenti in casa, abbiamo tutti i tool che servono per la pipeline di sviluppo nel cloud, zero manutenzione
2) Stiamo adottando un approccio DevOps, dove abbiamo automatizzato tutta la pipeline, senza dover mettere nulla in casa.
3) Stiamo rilasciando una applicazione Java standard (un War) per cui non ci stiamo legando a nessuna tecnologia proprietaria che deriva dal Cloud che abbiamo scelto (Azure).
4) Non dobbiamo gestire Tomcat perchè usiamo un approccio PAAS con Azure Web Sites.

Il punto 4 è quello che ci da vantaggio, non dobbiamo installare, manutenere Tomcat, non dobbiamo pensare a creare una infrastruttura di hosting ridondante che ci permetta di essere online 24/7 e soprattutto possiamo modificare le risorse del website a piacimento. Se abbiamo un ecommerce, nel periodo di Natale possiamo semplicemente aumentare le risorse e siamo a posto.

Se al contrario approcciamo il problema installando una VM su Azure dove mettere Tomcat … abbiamo perso in partenza, perchè non stiamo veramente sfruttando il cloud.

Gian Maria.

Agile@School – settima puntata del 11/06/2016

Nel precedente post abbiamo parlato di come il fallimento dello sprint ci ha colti. Ma avevamo anche sottolineato l’importanza di trovarsi in queste situazioni per capire come riprendersi e come raggiungere gli obbiettivi, con un nuovo spirito. Ed effettivamente è successo proprio tutto quanto ci aspettavamo Gabriele ed io. Nonostante gli sforzi impiegati per supportare le ultime implementazioni, possiamo dire che l’applicazione funziona e ha tutte le funzionalità pronte per essere valutate in sede di esame.

Vi presentiamo Students’ Yearbook!
L’ultimo incontro è stato più che altro un “debriefing” da una parte, ed una preparazione all’esame dall’altra.
Fase di “debriefing”
In questa fase abbiamo fatto nuovamente una review tecnica e funzionale dell’applicazione, questa volta utilizzandola pubblicata online. Già ad una prima occhiata è chiaro che i ragazzi sono riusciti anche ad utilizzare bootstrap nell’applicazione. E, per chi come chi li ha seguiti, ha visto la precedente versione, questa è una versione decisamente più gradevole. La review ha dato ottimi risultati sul piano dell’entusiasmo, seppure sia un momento decisamente complesso per gli studenti. Non dimentichiamo che manca un mesetto all’esame. 
Facendo un riassunto:
  – abbiamo valutato l’applicazione come “pronta per essere presentata”
  – abbiamo confermato il logo, totalmente studiato dai ragazzi
  – abbiamo valutato lo sprint e i comportamenti in relazione alle cerimonie e alle abitudini del team
  – abbiamo parlato di quanto fatto a mo’ di retrospettiva
  – abbiamo infine consegnato gli attestati di partecipazione al progetto (firmato anche dalla Preside)
La professoressa Pedullà ha creato l’attestato che segue e ha premiato i ragazzi per l’impegno e per la riuscita del progetto.
Come potete notare dalla firma della Preside, sembra proprio che il progetto avrà un seguito in questa scuola. E la cosa mi rende molto orgoglioso e felice allo stesso tempo.
Fase di preparazione all’esame
Questa è stata una parte impegnativa, che in realtà non ha proprio a che fare con il progetto in sé. Ho preparato un set di sette percorsi che i ragazzi possano seguire durante l’orale. Dopo aver tenuto le prime due “lezioni” sul glossario e sull’importanza di un vocabolario comune, nell’ottica della trasparenza, ho deciso di suddividere la proposta in due parti, una più accademica ed una più tecnica. Inoltre, ho deciso di separare ulteriormente gli insiemi in più generico (vedi agile manifesto) e più orientato a scrum. Insomma, ho pensato a:
  – percorso 1 – Agile manifesto e principi
  – percorso 2 – Scrum, glossario termini generale e ruoli
  – percorso 3 – Sprint, glossario termini e cerimonie
  – percorso 4 – Agile gamification (http://www.agilegamification.org)
  – percorso 5 – Documentazione del progetto (manuale utente e presentazione commerciale)
  – percorso 6 – Descrizione tecnica dell’applicazione (manuale tecnico e riferimenti tecnologici)
  – percorso 7 – Approfondimento su Visual Studio Team Services
I primi tre sono orientati ai principi, alle metriche, ai termini e alle cerimonie tipiche dello scrum e dell’agile in generale. Il quarto è molto particolare e viene definito come “l’utilizzo di meccaniche di gioco in contesti non di gioco, in modo da coinvolgere gli utenti nella risoluzione dei problemi e da guidarli per ottenere i comportamenti desiderati”. Si tratta di una pratica che rende stimolante il coinvolgimento dei membri del team in contesti non ludici tramite l’ausilio di giochi che allenino le persone a capire il vero teamwork.
Il quinto ed il sesto argomento sono orientati all’applicazione, alla documentazione allegata e ai risultati ottenuti tramite essa. Il settimo vuole aiutare chi è più tecnico e chi vuole parlare dello strumento che abbiamo utilizzato per gestire il progetto.
Su sette studenti, tre hanno scelto la parte accademica, in modo da poter sfruttare la cosa anche per l’interrogazione di inglese. Uno di loro porterà le definizioni interamente in inglese, così come il resto del suo orale. Gli altri ragazzi si sono divisi le documentazioni tecniche e funzionali, ma purtroppo nessuno ha scelgo la gamification, che personalmente trovo interessantissima.
Il risultato è più che soddisfacente, insomma.
Ed ora, un grosso in bocca al lupo ai giovani maturandi!
Stay Tuned! 

AgileIoT Kanban::Board

agileIoT kanban boardAbbiamo avuto già modo di presentare AgileIoT, un’approccio Agile per la gestione dei progetti legati al mondo dell’Internet of Things.

Il progetto, completamente open e rilasciato in chiave Creative Commons, su fonda su un Manifesto che ne illustra la filosofia, i principi e le pratiche. Insieme al Manifesto, è stato portato avanti lo sviluppo del Framework, un processo articolato per poter gestire in modo efficace i progetto.

Come l’Agile ci ha insegnato, però, le migliori soluzioni nascono dal campo e spesso è fondamentale disporre di un supporto meno strutturato che lasci spazio al team di auto-organizzarsi e “trovare la propria strada”.

Basandosi su queste considerazioni, nasce l’AgileIoT Kanban::Board, una personalizzazione dell’approccio Kanban in funzione del mondo IoT, che introduce due innovativi aspetti di visual management:

  • WorkPivot: che consente di passare dall’evidenza delle attività afferenti l’intero AgileIoT Team (verticali) a quelle del singolo Signal Temporary Team (orizzontali);
  • DARCH (Doing ARCH), in cui le attività (Slot) sono identificate in funzione della loro specificità (Hardware,Software e Cloud – asse verticale) associandole, contemporaneamente, all’ST2 (asse orizzontale) e al relativo Work in Progress limit (WIP-limit / WIP-l).

Nel complesso l’AgileIoT Kanban::Board si presenta simile a quella della figura seguente:

agileiot kanbanboard fullboard v01

AgileIoT Kanban::Board

In particolare il D-ARCH (ACHIEVE RAPIDLY CUSTOMER HOPES, ovvero centrare velocemente le aspettative del cliente) è il cuore pulsante dell’AgileIoT Kanban::Board, consentendo di mettere in evidenza le attività in essere e gli elementi “push” che ne cadenzano il ritmo.

agileiot kanbanboard darch v01

D-ARCH

Tale risultato si ottiene capovolgendo la vista d’insieme (da qui WorkPivot), spostando così il focus sull’attività dei singoli ST2 e creando una specifica caratterizzazione delle dimensioni Verticali ed Orizzontali:

  • Dimensione Verticale: evidenzia gli aspetti afferenti all’intero AgileIoT Team e al progetto in generale;
  •  Dimensione Orizzontale: evidenza gli aspetti afferenti ai diversi ST2.

Questo nuovo approccio ha arricchito direttamente anche il Manifesto, introducendo un quarto e fondamentale principio:

If you can’t remember it, you can’t improve it!

che pone in evidenza l’importanza di avere sempre e costantemente una visione d’insieme dello stato del progetto, avendo prontezza di eventuali problemi e colli di bottiglia che ne ritardano l’avanzamento.

Curiosi? Ebbene, se volete toccare con mano il tutto, venite a seguire il nostro workshop a BetterSoftware 2016.

Stay tuned!

VSTS release del primo Giugno

Come sempre il team di VSTS ha rilasciato live un nuovo sprint, andato online il primo Giugno e quindi disponibile in tutti gli account in questi giorni (gli update sono attivati a tutti gli account incrementalmente). Come sempre potete leggere online tutti i dettagli in questo post, e qui vi darò un riassunto delle novità più interessanti.

Anche in questo sprint abbiamo un miglioramento della Kanban board, in questo update sono stati aggiunti i filtri, in modo che voi possiate velocemente filtrare e visualizzare solamente le Card che soddisfano particolari requisiti.

Setting filters on the Kanban board 

Per quanto riguarda Git, è ora disponibile il protocollo SSH per connettervi ai vostri repository. SSH è un protocollo oramai deprecato anche da GitHub, ma nondimeno è ancora molto utilizzato, e per questo VSTS lo mette ora a disposizione per tutti gli account.

Managing SSH connections to Git repos

Sempre riguardo Git, la pagina web delle branch è stata completamente ridisegnata, ed in particolare è stato aggiunto un tab “mine” che permette di visualizzare le branch dove l’utente corrente ha contribuito. Inoltre se la branch ha il carattere / nel nome, viene visualizzata come un albero. Questa funzionalità è molto interessante per tutti coloro che lavorano con GitFlow.

Branches page showing the Mine pivot

Sul fronte DevOps è stata introdotta l’integrazione con Docker per la build e soprattutto per il Release Management. Sul fronte della build è stata introdotta la possibilità di creare immagini Docker e di inviarle a Docker Hub. Tutte le nuove funzionalità per Docker sono disponibili con una estensione del marketplace.

Running a Docker image

L’estensione è scaricabile per essere usata con TFS 2015 on premise.

Per tutti coloro che usano Sonar Qube, per tutte le build effettuate su una pull request, e per le quali è attivata l’analisi su Sonar Qube, si possono vedere le code analysis direttamente come commenti al codice.

SonarQube analysis comments

Questa funzionalità, descritta in dettaglio in questo post, è particolarmente interessante, perchè effettua una analisi in modalità differenziale, ovvero viene analizzato solamente il codice nuovo, che quindi entrerebbe nella branch target. In questo modo si può validare la qualità del codice di una pull request, mantenendo molto alta la qualità del proprio codice.

Per tutti gli afficionados della continuous integration, è ora disponibile un Widget per le dashboard che permettono di visualizzare metriche interessanti per i test. In questo modo potrete avere sempre sottocchio tutta la parte di testing delle vostre build.

Test results trend widget

Come sempre queste sono solamente alcune delle novità rilasciate, per una lista completa rimando al post ufficiale https://www.visualstudio.com/news/2016-jun-1-vso

Happy VSTS.

Gian Maria.

0  

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!

Agile@School – sesta puntata del 14/05/2016

Finalmente, i problemi sono arrivati.

Non sarebbe stato normale avere un progetto senza intoppi, anche se i ragazzi hanno sempre assunto un buon comportamento, sia per quello che riguarda le metriche, sia per il lavoro svolto. Non è da sottovalutare la particolarità del momento. La necessità di prepararsi alle prove che hanno in questo momento dell’anno scolastico, le varie simulazioni e la preparazione del materiale d’esame possono portare anche ad una perdita di focus generale.
I ragazzi non sono a tempo pieno su Agile@School, quindi le loro priorità possono essere spesso variabili.
Però, un impegno è un impegno, e poi, per molti di loro, Agile@School diventa anche il materiale che servirà loro nelle giornate di esposizione orale all’esame. Quindi, una correzione, dopo questo sprint “in calo” era d’obbligo, sia da parte dello Scrum Master, sia da parte del sottoscritto, in qualità di coach, e quindi, di riferimento principale, soprattutto sul comportamento di crescita necessario del team. E non siamo stati molto “morbidi”, proprio per far capire l’importanza del lavoro che stiamo facendo tutti.
Oggi non è stata una giornata felice per nessuno di noi, perché sono emersi i primi fallimenti. Ma senza questo punto di incontro di certo non si sarebbe raggiunta nemmeno l’ondata di ottimismo successiva, e nessuno avrebbe ripreso la “voglia di ripartire” per rimediare. 
Ma perché dopo cinque incontri così positivi, ora parliamo di fallimenti? 
Perché tramite essi ripartiremo e chiuderemo tutto alla grande, perché ho una grande fiducia in chi mi aiuta (la prof e Gabriele) e in chi sta lavorando per cogliere il valore aggiunto che questo progetto dà. Probabilmente, parte dei problemi è fisiologico, per i motivi di cui sopra e per una flessione normale che si ha nei processi di migrazione culturale. E non è tutta colpa di chi ha lavorato sul software. A volte, anche noi “dall’alto” sbagliamo, e sta a noi risolvere tali situazioni di stallo.
Quali sono stati i fallimenti?
Se vi ricordate, nel precedente post, abbiamo parlato di come presentare il lavoro, motivo per cui parte del team si è concentrato a creare presentazioni di business, manuali utente e tecnici. Nella fattispecie, abbiamo affrontato i seguenti topic:

– 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.)


Testing
Il primo punto è quello che, purtroppo come spesso accade, ha fatto emergere maggiormente la scarsa qualità del lavoro in termini di funzionalità. Il distacco maggiore si è verificato soprattutto tra gli Acceptance Criteria e l’effettiva implementazione. Il 90% della frustrazione sta qui. I test sono falliti tutti, o quasi, e i bug creati sono proprio tanti. Il motivo? si sono letti con poca attenzione di PBI e i criteri. Come mai? Ragazzi non abituati a farlo, semplice. Problema di facile risoluzione.
Comunicazione interna al team
Nonostante la stesura di un manuale tecnico, di un manuale utente e di una presentazione di business siano tra loro collegati da un punto di vista di immagine (logo, colori, brand, temi, ecc.) nessuno, all’interno del team, si è posto il problema di condividere in un solo momento gli stili, l’idea di grafica di insieme. Risultato? Tanti contenuti un po’ disordinati e poca uniformità nella presentazione. Il motivo? Stiamo parlando di due classi quinte differenti, che hanno avuto la possibilità di collaborare fisicamente nello stesso posto insieme troppo poco tempo. Come mai? Si è lavorato solo a scuola. Anche questo è un problema di facile risoluzione, investendo tempo insieme (anche online) al di fuori delle ore in classe.
Comunicazione con il team
Abbiamo slack, un toccasana per il lavoro in collaborazione. Eppure, sembra non essere utilizzato o, quanto meno, capito. Il motivo? Nonostante questi ragazzi siano sempre sullo smartphone, hanno percepito slack come un tool “da computer” e non si sono (alcuni) nemmeno posti il problema di cercare l’app sul proprio cellulare. Strano, ma vero. Alcuni ragazzi propongono watsapp, ma è troppo dispersivo. Chi ha usato slack bene in questi ultimi tempi, convincerà ed allineerà i “ritardatari”. Problema quasi risolto, ma la correzione è stata necessaria.
Utilizzo dello strumento
Risulta tangibile il calo di attenzione sulla gestione dei task su Visual Studio Team Services. Stati errati, comunicazioni del progresso del lavoro frammentate. Il motivo? non è stato percepito a fondo il vero valore aggiunto di un software di team working. Come mai? maturità dei ragazzi, inesperienza, errori da parte del sottoscritto (sottovalutazioni). Il problema è da risolvere, ma probabilmente gli esempi più concreti fatti in questo incontro, potrebbero aver aperto gli occhi agli studenti. Ho preferito spiegare cosa succede pragmaticamente a tutti se non si usasse. Speriamo si possa definire almeno parzialmente risolto. Queste dinamiche non sono semplici da implementare nella mente di uno studente così giovane.
Conclusioni
Ad una prima lettura, si può pensare che sia tutto andato male. Al contrario, vedo tante cose positive. Ad esempio, il fatto che un processo di test sia già attivo, proprio QA, con tanto di test case, che si basano su user story scritte a puntino. In quanti possono dire di avere realmente processi ripetuti o team dedicati alla QA o anche solo momenti di test funzionale approfondito? In quanti investono sui processi che migliorino la qualità? E parlo di aziende, non solo di scuola.
Ma non è solo questo, è stato utilizzato uno strumento per la collaborazione (Slack) fin dall’inizio. E ogni lavoro è gestito da canali, da pin di elementi importanti, da video condivisi e da integrazioni con software esterni (wunderlist, dropbox, ecc.).
Ed infine, certo, ci sono problemi nel capire realmente l’utilità della gestione del lavoro con VSTS, ma esso è presente in tutta la scuola, sia per la parte di controllo del codice sorgente, sia per la gestione (da questo progetto in avanti) del teamworking.
Insomma, quello che voglio dire è che i problemi su processi esistenti sono risolvibili, mentre se un processo manca, si è in alto mare. Per questo confermo la mia visione. Finalmente abbiamo avuto problemi, che risolveremo e che ci daranno nuovi stimoli, per ripartire spediti verso l’esame!
Chiudo con una frase emblematica sul fallimento, di Michael Jordan: “I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.
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!!!