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! 

Aggiornamento di VSTS 13 aprile

Il nuovo aggiornamento di TFS è in deploy, e contiene come sempre molte novità interessanti, come potete leggere dal post originale.

Le novità in questo caso sono molto interessanti, innanzitutto ora i Work Item hanno una icona che vi permetterà di “seguire” il Work Item, ovvero venire notificati ogni qualvolta il Work Item viene modificato.

Follow a work item

Di seguito poi viene una delle funzionalità più richieste di tutti i tempi (dopo il rename del Team Project) ovvero la possibilità di cambiare tipo ad un Work Item.

image

Le ragioni per il cambio di tipo sono molteplici, ma la prima è una riorganizzazione e promozione durante il Backlog Grooming. Supponiamo di avere una User Story che si rivela molto grande in fase di analisi, cosi grande da non poter entrare in un singolo sprint. A questo punto deve essere decomposta e la soluzione migliore è quella di, convertirla in epics (feature) e poi andare a decomporla in nuove User Stories.

Chiaramente anche il cambio di tipo è una operazione che viene tracciata.

image

Ma le novità non sono finite quì, un’altra delle funzionalità più richieste, ovvero il poter muovere un Work Item tra Team Project è stata finalmente implementata. E’ ora possibile muovere un singolo Work Item, oppure una serie di Work Items in un altro progetto.

image

Si può specificare quindi dove andare a mettere i Work Item, ma soprattutto, è possibile anche cambiare tipo.

image

Nell’esempio in questione, ho preso tre Product Backlog Items, e li ho spostati in un Team Project basato sul template Agile, per questa ragione ho deciso anche di cambiare il tipo di Work Item in User Story.

A questo punto già abbiamo un bel insieme di novità, ma non è finita qui, è ora possibile personalizzare i work item scegliendo una Pick List, ovvero aggiungendo un campo che può assumere un pre-determinato insieme di valori.

Add a field to a bug

Un’altra interessantissima funzionalità è la possibilità di cliccare su un errore di compilazione di una build ed essere portati direttamente alla riga di codice che la ha causata, direttamente dal vostro browser.

Per finire sono state introdotte anche numerose interessanti funzionalità sul Release Management che potete leggere dal blog ufficiale.

Buon fine settimana a tutti. :)

DA2, IT Delivery: lifecycles

Nell’ambito di Disciplined DevOps, le attività di delivery sono costruite su quelli che erano i cardini portati della precedente versione di Disciplined Agile.

 da2 it delivery

DA2, IT Delivery

Il presupposto da cui DA2 parte è che ogni team è unico e tale può essere anche la soluzione che ci si accinge a sviluppare, per cui è opportuno prevedere più modelli di ALM, generalizzabili comunque secondo un modello che prevede tre fasi primarie:

  • Inception, la fase di inizializzazione del progetto, in cui gli elementi fondamentali per la sua riuscita prendono corpo e si valutano aspetti come il Rischio e la Sostenibilità;
  • Construction, la fase di realizzazione, ovvero dove la soluzione viene concretamente implementata;
  • Transition, la fase che si occupa degli aspetti di Delivery e Deployment.

da2 delivery general

 Delivery general

Le fasi di Construction e Transition, quando si approccia alla Cultura DevOps, diventano fortemente correlate tra loro, anche mantenendo una ovvia sequenzialità logica, mentre se si estende il campo di osservazione, è evidente come il ciclo di delivery sia strettamente legato agli aspetti di pianificazione complessiva, fino al Portfolio e al Reuse Engineering.

da2 delivery

DA Delivery extended context

DA2 specializza questo meta-modello di riferimento in funzione delle variabili Team-Solution Context, proponendo quattro modelli di riferimento specifici:

  • Agile/Basic Lifecycle (Extending Scrum): si tratta del lifecycle pensato per i team che già lavorano con Scrum e hanno la necessità di scalare le proprie attività. Questo approccio si caratterizza per:
    • Iteration Based, esattamente come Scrum la soluzione è sviluppata con un approccio time-boxed e ogni intervallo di sviluppo è definito Iteration;
    • Non-Scrum Terminology, di base la terminologia Scrum è sostituita con una duale più generica (es: Iteration vs Sprint), anche se ciò non è un must;
    • Inputs from outside the delivery lifecycle, vengono evidenziati gli elementi esterni primari in grado di condizionare la soluzione e generare cambiamenti durate la sua realizzazione;
    • Work item list, not Product Backlog, DA2 preferisce il concetto di Work Item a quello di Product Backlog. Questo per evidenziare che nello stack non sono presenti solo User Story o Feature da realizzare, ma anche requisiti, difetti, aspetti non funzionali, ecc…. In pratica il Product Backlog contiene tutto quanto necessario al successo della soluzione (e non allo sviluppo del prodotto/progetto), comunque ordinato secondo diversi criteri;
    • Explicit milestones, sono previste milestone esplicite che consentono una governance efficace delle attività, e rappresentano spesso il momento di Deployment concordato con il cliente.

da2 delivery base

DA2 Base

  • Advanced/Lean DAD Lifecycle: si tratta del lifecycle pensato per team maturi che lavorano in chiave di Continuous Value Stream, rilasciando gli Incrementi quando sono pronti, senza avere una finestra specifica di riferimento, e sforzandosi di ridurre al minimo il tempo che intercorre tra due rilasci. Questo approccio si caratterizza per:
    • Continuous flow of delivery, il delivery/deployment avviene ogni volta che è disponibile un nuovo Increment significativo, senza vincolarsi ad alcuna Iterazione. Le nuove attività sono “tirate” dal team nel flusso di lavoro appena si ha la capacità per farle e non “spinte” in funzione di una pianificazione time-boxed (pull vs push);
    • Practices are on their own cadences, le varie cerimonie (retrospettive, grooming, ecc…) vengono eseguite quando ha senso farle e non secondo una cadenza pre-stabilita;
    • Work item pool, non tutti i work-item sono uguali. Alcuni sono risk-value driven, altri value-driven e altri ancora data-driven (si pensi ai vincoli normative). Per questo motivo un Work Item pool ha molto più senso che uno stack ordinato per priorità generica.

da2 delivery advanced

DA2 Advanced

  • Continuous Delivery Lifecycle: si tratta di un Advanced/Lean DAD Lifecycle in cui il tempo di delivery/deployment è ridotto al minimo, anche con frequenza di più volte al giorno, sfruttando strumenti di automazione e processi standardizzati nel tempo.

da2 delivery cont delivery

DA2 Continuous Delivery

  • Exploratory (Lean Startup) Lifecycle: è il processo contemplato da Lean Startup, pensato per le startup o le LOB di ricerca che devono prima di tutto validare la sostenibilità della propria idea, andando a scoprire il mercato con una serie di Minimum Viable Product (MVP) e una specifica implementazione del ciclo Build-Measure-Learn. Questo modello è caratterizzato da:
    • Envision, si tratta di esplorare la nuova idea e formulare le ipotesi in relazione alla possibile idea che potrebbe attrare i potenziali clienti;
    • Build a Little, sviluppare velocemente quanto necessario per validare le proprie ipotesi: Minimum Viable Product (MVP). Non è importante concentrarsi sulla qualità tecnica, bensì essere estremamente veloci e capaci di evidenziare le caratteristiche peculiari;
    • Deploy, l’MVP deve essere reso velocemente fruibile agli early-adopter in modo da poterne testare l’interesse;
    • Observe & mesure, una volta in erogazione, è necessario monitorare il comportamento degli early-adopter “instrumentando” l’MVP. In tal modo è possibile rendersi conto se quanto realizzato è sulla direzione giusta o è necessario eseguire un pivot;
    • Cancel, dopo aver testato le idee portanti e sfruttato i pivot, potrebbe essere necessario decidere di abortire lo sviluppo della soluzione perché non è di interesse per i potenziali clienti. Se ciò deve avvenire, meglio che avvenga in un tempo ristretto limitando le risorse impiegate e massimizzando il know-how acquisito;
    • Productize, se il prodotto trova il proprio spazio, la fase di Customer Delivery può ritenersi conclusa ed è opportuno passare alla fase di ingegnerizzazione, preferibilmente, tramite uno degli altri modelli di sviluppo presentati.

da2 delivery experiment

 DA 2 Exploratory

La presenza di 4 diversi lifecycle è una precisa scelta in chiave “no-prescribing” di DA2, che riconosce come naturale il fatto di potersi/doversi adattare ai diversi contesti, oltre a prevede l’evoluzione in funzione della Cultura aziendale, dalla maturità del team, delle tecnologie e delle mutate condizioni di mercato.

Tutto questo ha chiaramente un costo, poiché avere persone in grado di adattarsi alle specifiche connotazioni dei vari modelli non è cosa da poco, ma il risultato è sicuramente più efficace del costringere i team a seguire un approccio pre-determinato, eventualmente poco consono allo specifico contesto.

Disponibili BugGuardian.MVC e BugGuardian.WebForms

Oggi sono veramente felice di poter annunciare il rilascio di 2 moduli addizionali per BugGuardian.
Per chi non lo conoscesse, BugGuardian è una libreria che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Team Services o su un Team Foundation Server 2015 on-premises nel caso in cui l’applicazione sollevi un’eccezione non gestita (Unhandled Exception).
Per supportare nel modo migliore l’integrazione di questa libreria con i progetti web, da oggi sono disponibili BugGuardian.MVC and BugGuardian.WebForms.
BugGuardian.MVC (GitHub, NuGet) è un estensione di BugGuardian scritta specificamente per supportare ed integrarsi con le applicazioni Asp.net MVC. 
Aggiunge degli Action Filter alle tue applicazioni in modo da poter intercettare automaticamente tutte le eccezioni non gestite.
BugGuardian.WebForms (GitHub, NuGet), invece, è un modulo aggiuntivo per BugGuardian scritto specificamente per supportare le applicazioni Asp.net WebForms.
Queste due nuove librerie sono entrambe basate sulla nuova versione 1.3.0 di BugGuardian (anch’essa rilasciata da pochissimo) e supportano progetti che utilizzano il .Net Framework v4.0 e superiori.

Com’è per BugGuardian, queste due librerie aggiuntive sono Open Source; guardate pure il codice su GitHub.
Se doveste avere dubbi o problemi durante l’utilizzo di queste nuove librerie, fatemelo sapere attraverso le rispettive  Issues page di GitHub e cerchero di fixare il problema prima possibile!
Di nuovo, Voglio ringraziare il mio amico e “collega” MVP Marco Minerva (@marcominervaGitHub) per il supporto ed i suggerimenti.