Nuovo deploy per VSTS

Con la solita cadenza tri-settimanale ecco le release notes del nuovo sprint rilasciato su VSTS. La nuova funzionalità su cui mi voglio soffermare è il cambio di licenza / uso per i build agent. Tradizionalmente infatti VSTS permetteva di usare un agent on premise gratuitamente, e per ogni agent in più era necessario pagare un abbonamento mensile.

Con il nuovo update la situazione è cambiata, nella parte di amministrazione del vostro account è ora presente un menu dedicato alle Build and Release dove potete vedere le Resource Limits.

image

Di base avete solamente una free pipeline, il cui significato è discusso in questo articolo. Senza entrare nel dettaglio il concetto è che potete installare quanti agent volete, ma se avete una sola pipeline attiva, solamente una build o una release attiva possono coesistere contemporaneamente. Questo significa che anche se avete agent liberi, se una build è in corso le altre verranno accodate.

Questa situazione è molto più desiderabile rispetto alla gestione classica, perché in questo modo voi potete deployare quanti agent volete, senza doverli ogni volta attivare o disattivare, e lasciare che sia il sistema a gestire il throttling. Se vi rendete conto che una sola pipeline non vi basta, potete acquistarne altre, ma nel frattempo potete installare agent su linux, windows, mac senza dovere impazzire.

Gian Maria.

DevOps and Outsourcing: OutOps [pt.3]

Terzo e ultimo appuntamento di DevOps e Outsourcing, in cui vedremo le rimanenti strategie e tireremo un po’ le somme del discorso.

OutOps Strategy, Infrastructure Resilience

L’ Infrastructure Resilience (Resilienza ai cambiamenti Infrastrutturali) è la capacità del software di adattarsi ai cambiamenti evolutivi e alle condizioni inattese dell’infrastruttura a supporto, composta dall’hardware e dal software di base.

resili

In generale, una soluzione robusta deve essere tollerante ai cambiamenti dell’hardware e del software di base: si pensi, ad esempio, all’utilizzo di container per il suo dispiegamento.

In questo ambito è fondamentale avere strumenti automatizzati di verifica che consentono al committente di validare il corretto utilizzo dell’infrastrutture da parte della soluzione realizzata.

Questo approccio conferisce al delivery/deploy automatizzato una maggiore robustezza: si pensi ad esempio ad una nuova release del software che si scontra con il fatto che l’RDBMS è stato aggiornato. Se le verifiche vanno a buon fine è possibile essere confidenti che l’evoluzione infrastrutturale non ha prodotto side effect sull’applicazione e procedere con il relativo delivery. L’alternativa sarebbe un approccio “deploy & pray”, ovvero “io speriamo che me la cavo”.

Compito del Committente: Definire e gestire gli end-point di supporto alle soluzioni unitamente al provisioning automatizzato delle risorse annesse. Inoltre, è di primaria importanza l’individuazione o la realizzazione di tool che consentano di verificare lo stato di erogazione del servizio e rispondere autonomamente alle situazioni inattese più comuni.

Benefici Evidenti: garantire una buona resilienza consente di supportare adeguatamente l’evoluzione dell’infrastruttura a supporto, riducendo il rischio di blocco dei servizi e quindi un’operatività dell’azione di business.

OutOps Strategy, Intentional Architecture

Ogni software ha un’Architettura, sia essa specificamente definita o de-facto.

intentional architect

Quello che però deve essere evidente è il fatto che, a livello di “piattaforma” (formata dalle diverse soluzioni, realizzate eventualmente in outsourcing da uno o più fornitori) delle soluzioni erogate, non è possibile immaginare che ognuna di essa abbia una struttura che non tenga conto delle scelte d’insieme e, in particolare, non sposi architetture software moderne, andando a minare l’efficienza complessiva di una pipeline di Continuous Delivery.

Come esempio, si immagini lo scenario in cui la soluzione è monolitica e si debbano eseguire i test di regressione: per testare le modifiche relative ad una singola feature è necessario ricompilare tutto il sorgente e rieseguire tutti i test, perdendo ore e rendendo impossibile, nel concreto, attuare la pratica di Continuous delivery/deploy. Un’architettura in chiave “servizi” (nelle diverse declinazioni tecnologiche), consente di rendere il tutto estremamente più efficiente, concentrando le azioni di verifica e misurazione esclusivamente sul nuovo componente o su quello che è stato modificato.

Una soluzione efficace al problema è quella che vede il committente impegnato a definire una “Intentional Architecture” (Architettura Intenzionale), ovvero una architettura di riferimento che guidi le azioni progettuali del fornitore senza imbrigliarlo in scelte eccessivamente di dettaglio: ad esempio, si impone che l’architettura sia a Microservizi, ma al contempo al fornitore non viene imposto di utilizzare uno specifico design pattern perché si tratta di una scelta a livello di codifica (design applicativo), ininfluente a livello architetturale.

Compito del Committente: Definire l’Intentional Architecture e condividerla in modo chiaro con tutti i fornitori. Settare una serie di metriche che consentano, qualitativamente, di validare l’aderenza ad essa.

Benefici Evidenti: Con una Intentional Architecture si riduce fortemente il rischio di frammentazione della “piattaforma”, consentendo una gestione quanto più possibile omogena di essa. Inoltre, le architetture moderne abilitano all’utilizzo di molte delle pratiche alla base di DevOps.

OutOps Strategy, Security Validation

La Sicurezza (con la “S” maiuscola ad indicare la generalità e la necessità di declinarla rispetto allo specifico contesto) è un aspetto imprescindibile che deve essere alla base della realizzazione di ogni soluzione.

security 

Fondamentale è che le diverse applicazioni siano allineate alle necessità e ai vincoli individuati a livello enterprise al fine di non compromettere la sicurezza della “piattaforma” complessiva dei servizi in erogazione.

Questo tipo di azione richiede la creazione di una serie di servizi che i fornitori debbono utilizzare per validare quanto realizzato già durante lo sviluppo: si pensi ai penetration test, così come agli strumenti di analisi statica della qualità del codice che si concentrano sulla ricerca di pattern potenzialmente attaccabili.

Finché tutte le verifiche non sono superate positivamente, la soluzione non può essere accettata e sarà onere del fornitore risolvere i diversi problemi riscontrati.

Compito del Committente: Definire in modo chiaro il concetto di “Sicurezza” e le relative policy a cui attenersi, rendendo disponibili una serie di strumenti che il fornitore può utilizzare per validare oggettivamente la relativa conformità.

Benefici Evidenti: La “piattaforma” dei servizi ha un livello di Sicurezza minimo garantito. Il committente è sicuro che, solo quando una soluzione supera le verifiche automatiche di sicurezza stabilite nella pipeline di delivery, potrà raggiungere effettivamente la produzione.

 

Conclusioni

Quanto descritto fin ora vuole essere un contributo, sulla base dell’esperienza personale e dell’osservazione diretta di diverse realtà aziendali, nel capire come poter applicare i principi DevOps in contesti fortemente caratterizzati da azioni di outsourcing.

Si tratta di casi numericamente consistenti, in cui diventa difficile trovare il modo di sposare le pratiche che stanno gradualmente trasformando lo sviluppo, di soluzioni IT, da un’azione artigianale ad una sempre più ingegneristica.

Bisogna però fare attenzione a non cadere nell’illusione che OutOps possa richiedere un impegno minore, dal punto di vista della trasformazione aziendale, di quello che possa richiede DevOps: questo perché l’onere di guidare il processo di trasformazione in relazione agli obiettivi di business non può essere esternalizzato, ma resta di competenza esclusiva dell’IT aziendale, essendo l’unico responsabile dell’allineamento con la vision strategica.

Fondamentale diventa, inoltre, il coinvolgimento di funzioni non tipicamente IT, come Legal o Provisioning, che devono formalizzare e gestire le relazioni con i fornitori esterni. Tematica particolarmente calda in questo ambito è quello dei Contratti Agili, pensati per instaurare una collaborazione win-win tra committente e fornitore che non si basi esclusivamente sugli elementi costo-tempo-funzionalità.

Infine, è utile ribadire che, quanto descritto, è un’indicazione di cosa ad oggi funziona nelle realtà che si sono impegnate in OutOps, e non va preso come una “ricetta” ma come un punto di partenza per capire come potersi muovere nel proprio contesto.

<

p style=”margin-top: 6pt; line-height: 150%;”>

DevOps and Outsourcing: OutOps [pt.2]

Continuiamo il nostro viaggio nell’applicazione di DevOps al mondo dell’Outsourcing. 

OutOps Strategies

Fatte fin qui le dovute premesse ed i dovuti richiami, andiamo ora a vedere le strategie attualmente più efficaci in ambito OutOps:

  • Shared Repository
  • Regression Test
  • Quality Measurement
  • Infrastructure Resilience
  • Intentional Architecture
  • Security Validation

Queste strategie consentono all’IT del committente di mantenere il controllo su quanto realizzato da uno o più fornitori terzi, attuando una governance efficace di supporto al business. Si tratta di mettere in chiaro gli elementi essenziali su cui si svilupperà il rapporto committente/fornitore in modo da non essere preda di “capricci” o azioni poco ortodosse da una delle parti.

Qui è necessario aprire una parentesi: l’idea di dare in outsourcing l’intera attività di sviluppo è un forte azzardo che può portare a risparmi, anche consistenti, nell’immediato, ma espone l’azienda a rischi altissimi per il futuro. Si prenda ad esempio lo scenario in cui lo sviluppo di tutto il software relativo al core-business viene esternalizzato: in questo caso, per la prima release, è probabile che si otterrà un cospicuo sconto da parte del fornitore che vuole entrare nelle “grazie” dell’azienda. Ma già dalla release successiva (se non prima!) le posizioni saranno invertite: le regole del gioco saranno dettate dal fornitore perché detiene le “chiavi” del successo del business.

Una corretta strategia di Program dovrebbe essere quella di mantenere lo sviluppo dei sistemi core in-house ed esternalizzare solo quello relativo alle soluzioni di supporto o comunque relativamente facili da sostituire.

In entrambi i casi, le strategie di OutOps sono preziose per garantire una costante efficienza dell’azione IT.

OutOps Strategy, Shared Repository

La strategia di Shared Repository consente di attivare il flusso di “Last Mile” (“Ultimo Miglio”), ovvero quello che porta il software dal Version Control System nelle «mani» dell’utente finale.

repo

Tipicamente, ogni team di sviluppo e ogni team di operation definisce il modo in cui il software viene versionato, compilato, impacchettato, dispiegato, ecc… Chiaramente, nello scenario di sviluppo in-house, l’approccio DevOps consente di trovare il miglior compromesso contestuale per raggiungere efficacemente gli obiettivi fissati.

In un’ottica OutOps invece, la strategia di Shared Repository mette a disposizione un VCS unico, gestito dal committente, che diventa il “punto di scambio primario” tra il team esterno e quello interno di “Ops”. In particolare, il fornitore deve conformarsi alle regole di versioning identificate dal committente e garantire che quanto presente su di esso sia compilabile.

Tutto questo è indispensabile per creare una strategia di building automatizzata con cui realizzare gli artefatti che poi attraverseranno i diversi ambienti di QA Testing, Pre-Prod, Collaudo… fino ad arrivare in produzione.

Non è assolutamente pensabile che ogni fornitore gestisca questi aspetti in modo autonomo, perché ciò porterebbe ad una giungla di soluzioni e di convenzioni che renderebbero difficile, se non in alcuni casi impossibile, gestire il tutto.

Compito del Committente: Gestire il Version Control System da utilizzare e definire un’opportuna strategia di versioning a cui tutti i fornitori dovranno attenersi.

Benefici Evidenti: Il software realizzato in outsourcing è sempre presente nel repository del committente, seguendone le regole di versionamento e di gestione. Tutto quanto necessario è presente nello specifico ramo del source control (codice, dipendenze, test, documentazione, ecc…) ed è possibile impostare azioni consistenti e predicibili (a partire dalla build) per completare l’ultimo miglio, con la certezza di non doverle rivedere per ogni fornitore.

OutOps Strategy, Regression Test

I Regression Test (o Test di Regressione) devono sempre accompagnare il software sviluppato, al di là che si utilizzi un approccio OutOps. I Test di Regressione vanno a verificare che quanto sviluppato (storia o feature) funzioni correttamente e produca gli output previsti in relazione al perimetro delineato dai relativi Criteri di Accettazione.

regression test

Tali test sono, inoltre, un’ottima fonte di documentazione (estraibile tramite tool automatici) che riflette costantemente lo stato reale di quanto sviluppato.

Compito del Committente: Lavorare con il team del fornitore per la definizione di Regression Test, annessi ai Criteri di Accettazione, che consentano di validare il corretto funzionamento di quanto realizzato e delle eventuali modifiche apportate.

Benefici Evidenti: I Regression Test sono fondamentali per garantire al committente la possibilità di far evolvere la soluzione in modo indipendente dal fornitore specifico. Ciò allenta drasticamente il cordone ombelicale che lega tra loro committente e fornitore, fino a spezzarlo completamente se necessario.

OutOps Strategy, Quality Measurement

Misurare la Qualità del Software realizzato è essenziale per valutare il lavoro svolto dal fornitore, ma soprattutto consente di tenere sotto controllo il Debito Tecnico cumulativo, evitando che si avvicini al punto di massa critica.

measurement

È fondamentale quindi settare dei livelli minimi di qualità del codice, statici e dinamici, e individuare tool che possano misurarli automaticamente. Tali livelli dovranno essere rispettati e raggiunti da tutti i fornitori, altrimenti quanto depositato nel sistema di versionamento non può essere immesso nella pipeline di delivery e viene scartato automaticamente.

Tutti i problemi riscontrati devono inoltre confluire in un sistema di Change Request Management (o similare) che li rendi evidenti e che consenta di misurare il relativo trend in modo da intraprendere opportune azioni correttive a riguardo.

Compito del Committente: Definire livelli minimi di qualità che le soluzioni devono avere e le relative Metriche di valutazione. Queste informazioni devono essere chiare e disponibili in modo trasparente, oltre ad essere validate attraverso tool automatici messi a disposizione anche al fornitore per testare il proprio lavoro durante la fase di sviluppo.

Benefici Evidenti: Quanto realizzato ha un livello minimo di qualità, individuato dal committente, che minimizza i rischi al minimo livello accettabile. L’automazione consente di rimuovere gli approcci basati su verifiche manuali delle tradizionali milestone che spesso finiscono più per essere un’azione pro-forma che di reale utilità. Inoltre, il Debito Tecnico è costante monitorato ed è indicativo dello stato di salute di tutte le soluzioni software in essere.

 

Con “la misura” si conclude il nostro secondo appuntamento. La prossima settimana completeremo l’esplorazione delle altre tre strategie evidenziate.

Stay tuned :-)

Nuovo aggiornamento VSTS

Gennaio 25 arriva ed ecco il nuovo aggiornamento di VSTS, annunciato nel blog di Brian.

Come sempre ci sono alcune interessanti novità e nel blog di Brian Harry troviamo le più significative, la prima è un addin di una nuova funzionalità chiamata Agile Delivery Plans, che permette di verificare nella propria azienda lo stato di avanzamento dei lavori. Questa funzionalità è per ora presente come addin ed è in una early preview, ma vale la pena spenderci un po di tempo per giocarci e comprenderne le potenzialità.

La seconda, e secondo me ancora più importante, è la preview della visualizzazione Mobile Friendly dei Work Item, che finalmente permette di gestire un Work Item anche da un device, ecco una schermata.

mobile form

Ma le novità non finiscono qui, è ora possibile anche provare la preview del nuovo editor per le build

build editor switch

Il nuovo editor promette una ancora più facile esperienza nella creazione e manutenzione della definizione di build, con un nuovo editor completamente rinnovato, assieme alla possibilità di avere tutti i parametri principali della build in un unica schermata, invece di dover selezionare task dopo task.

Come sempre, data la grande importanza di Git, abbiamo delle modifiche di usabilità per la Pull Request, che permettono di visualizzare in maniera migliore i commenti, è stata aggiunta una toolbar nei commenti per permettere l’uso della formattazione Markdown anche a chi non ricorda o conosce la sintassi, e le pull request sono raggiungibili anche dal dettaglio dei commit che fanno parte di una pull request.

Se avete adottato VSTS, tra pochi giorni avrete disponibili automaticamente tutte queste nuove funzionalità, senza dovere installare od aggiornare nulla.

Happy VSTS.

DevOps and Outsourcing: OutOps [pt.1]

Con questo post iniziamo una mini-serie di articoli (presumibilmente 3) dedicati ad esplorare una tematica sempre più comune: DevOps e il mondo outsourcing.
Senza alcuna pretesa di dare una “ricetta pronta all’uso”, vedremo gli aspetti cruciali annessi alle situazioni in cui lo sviluppo viene esternalizzato e come possiamo adottare DevOps in questi ambiti, parlando di alcune strategie di successo.

DevOps and Outsourcing: OutOps

Come ci sforziamo da tempo di evidenziare, DevOps è prima di tutto un approccio culturale, così come sintetizzato dalla definizione seguente:

 Culturale in cui l’intera Line of Business si assume la responsabilità della creazione di Valore per il cliente.

Developers e Operations sperimentano continuamente nuovi modi di lavorare insieme, andando a standardizzare e padroneggiare i processi attraverso la ripetitività e la pratica [cit. FP]

Tutto interessante, di valore e dai forti riflessi applicativi pratici, ma…. come sempre, purtroppo, esistono situazioni in cui tale livello di integrazione tra “Dev” e “Ops” non è concretamente realizzabile per il semplice fatto che l’azienda ha adottato una strategia di outsourcing (totale o predominante) delle attività di sviluppo.

In pratica, i “Dev” non ci sono proprio!

Quindi si potrebbe, a primo acchito, essere tentati nell’affermare che: “DevOps non è applicabile nei contesti fortemente caratterizzati dall’outsourcing”.

dev wall out ops mini 

Se questa affermazione d’impeto ha dei fondamentati (di cui discuteremo a breve), la realtà, fortunatamente, non è nera o bianca, ma esistono diverse possibilità per applicare DevOps con successo anche in questi contesti, proprio perché si tratta prima di tutto della capacità di cooperare perseguendo un obiettivo comune.

Infatti, è come se la parte di “Dev” diventasse un “artefatto” da incastrare nel proprio processo di delivery, gestendo sempre l’ottimizzazione del flusso complessivo delle attività, in contrapposizione alla logica dell’ottimizzazione locale tipica degli approcci tradizionali.

Per indicare questo scenario, andremo a coniare uno specifico acronimo: OutOps (Outsourcing & Operations).

Va specificato che si potrebbe avere anche il caso duale, ovvero “Dev” interno e “Ops” esterno, dando vita a un ipotetico DevOut (Development & Outsourcing). Questo caso è però molto più raro nella realtà, perché tipicamente la governance della infrastruttura è quasi sempre interna alle diverse aziende, indipendente dal fatto che l’hardware sia in-house, gestito da terze parti o in cloud. Infine, il caso di Out-Out, in cui tutto è in outsourcing, ci porta nel dominio del Software-as-a-Service: l’azienda compra la soluzione sotto forma di servizio, svincolandosi da tutti gli oneri realizzativi. Tale scenario è chiaramente poco attinente al discorso che si sta facendo.

I diversi scenari sono rappresentati dal seguente DevOps Outsourcing quadrant, in relazione all’outsourcing di “Dev” e “Ops”.

 

devops quadrant

DevOps Outsourcing quadrant

Nel prosieguo faremo riferimento al contesto specifico di OutOps.

Be C.A.L.M.S and Stay Agile

Prima di parlare delle possibili strategie di adozione di DevOps in realtà ousourced-orinted, è bene fare alcuni richiami a quelli che sono gli elementi fondanti di questo approccio.

DevOps si basa su cinque pillar (pilastri) fondamentali: Comunicazione, Integrazione, Collaborazione, Automazione e Misurazione, ognuno dei quali deve essere presente all’interno della propria azione di delivery per poter operare in chiave di Continuous Improvement.

 

devops pillar

DevOps Pillar

Si tratta di un ecosistema complessivo che può assumere diverse sfaccettature e va opportunamente bilanciato al fine di ottimizzare l’intero flusso di delivery in funzione degli obietti di business, in chiara logica Lean.

Proprio per attuare questo bilanciamento, all’interno del proprio DevOps journey, è possibile sfruttare il meta-framework operativo C.A.L.M.S., creato da Damon Edwards e Jez Humble, il cui nome è formato dalle diverse leve a disposizione per raggiungere tale obiettivo:

  • Culture – gestire il cambiamento focalizzandosi sulla collaborazione e la comunicazione
    • Hearts & Minds, Embrace Change;
  • Automation – rimuovere le azioni manuali lungo la catena del valore
    • Continuous Integration, Continuous Delivery/Deployment, Infrastructure-as-a-code;
  • Lean – utilizzare i principi Lean per velocizzare, standardizzare e rendere efficienti le attività
    • Customer Value focus, Small batch size;
  • Metrics – misurare qualsiasi cosa, utilizzando i risultati per rifinire costantemente le attività
    • Measure Everything, Show the improvement;
  • Sharing, condividere le esperienze di successo e di fallimento per una crescita diffusa
    • Open Information Sharing, Collaboration. 

Il livello di ciascuno di questi 5 elementi vi permette di avere una istantanea dell’azione di Change Management in chiave DevOps, evidenziando punti di forza e debolezza e portando ad individuare opportune strategie di miglioramento.

Nel contesto specifico di OutOps è chiaro che alcune leve sono più aggredibili di altre, in particolare: Automation, Lean e Metrics. Questo non vuol dire che le altre siano assenti, ma che assumono delle forme meno libere, e più vincolate da aspetti relazionali spesso regolamentati da specifici contratti o accordi formali.

 

Questo primo post termina qui. Nel prossimo vedremo le strategie di OutOps e i relativi vantaggi operativi.

 

Stay tuned :-)

Agile@School, si ricomincia!

Agile@School è un progetto nato l’anno scorso, per ora seguito solo dal sottoscritto e da pochi altri amici che mi hanno aiutato nello svolgimento delle attività. Tuttavia, seppure l’anno scorso fosse stato totalmente sperimentale, credo che possa diventare sempre più interessante, soprattutto se condiviso con chi vorrebbe partecipare.

Ad oggi non abbiamo nemmeno un sito che descriva di cosa si tratta, anche perchè non abbiamo ancora definito un reale contesto ed un insieme di step da seguire. Ed è proprio per questo che scrivo il post. Oltre a descrivere ed aggiungere dettagli su qualcosa che può diventare importante, sono qui a chiederVi disponibilità di partecipazione, ovunque vi troviate sul territorio nazionale. Ma andiamo per passo.
Cos’è Agile@School?
Si tratta di un’idea che si pone come obbiettivo quello di portare le metodologie Agili (a scelta di chi segue il progetto stesso in accordo con la scuola) all’interno di istituti di scuola superiore o di media inferiore (anche questo a scelta) al fine di gestire progetti scolastici, quali ad esempio tesine di esame, progetti paralleli, sviluppo di idee utili all’istituto stesso, e via discorrendo.
Ok, ma cosa si deve fare?
Seppure l’organizzazione sia in mano a chi si prende l’onere (e l’onore) di seguire il progetto, l’esperienza che ho avuto l’anno scorso mi permette di dare un paio di dritte:
– crearsi una board (con Trello, ad esempio)
– trovare un aiutante per le volte in cui ci si riuinisce con la scuola
– creare un team con una chat collaborativa (con Slack, ad esempio)
– concordare con i professori un referente a scuola
– prepararsi una sessioncina di 4/5 slide da presentare agli studenti, sessione semplice ed accattivante, non tediosa e già formativa (quello viene dopo)
– organizzare un primo incontro illustrativo per selezionare il team da seguire (il numero degli studenti è selezionato dai docenti stessi)
– cercare di seguire un team di massimo 7/8 persone, ma se la scuola ne offre di più, provare a fare due team, aumentando gli aiutanti (consiglio di partire con uno)
– organizzare con i prof. le date e le periodicità di incontro per seguire con il metodo scelto (Scrum, Kanban, ecc..) da coach
– istruire il vostro aiutante come un facilitatore, tipo uno ScrumMaster, per seguire insieme la “cosa” da esterni
– selezionare i ruoli nel team e determinare l’area di lavoro comune
– postare ogni incontro sul vostro blog (più social FB, Twitter, LinkedIn, ecc.)
Chi può aiutare?
Chiunque abbia voglia di impararsi le basi dell’agile (meglio se ha già esperienza) e soprattutto chi è già nel mondo del lavoro, il che aiuta davvero a capire come comportarsi. 
C’è una community?
L’unica community che, ad oggi, segue questa cosa, è GetLatestVersion.it, con la quale stiamo provando a promuovere questo progetto dal nord al sud Italia.
Periodo?
Questo è il periodo migliore per partire. L’inizio dell’anno. Ma possiamo intanto parlarne insieme in una call di pochi minuti per ulteriori delucidazioni.
Futuro?
Nel futuro penseremo a come accentrare le informazioni per realizzare un vero e proprio progetto con relativo Sito (e anche qui vedremo se usare strumenti comuni o meno). Una volta che avremo poi almeno un paio di realtà in più, faremo il nostro team su chat collaborativa (probabilmente Slack).

Contatti?
Alessandro Alpi (Io), Gabriele Etta (il mio aiutante), tutta la community di GetLatestVersion.it

Vi aspetto, in questo progetto credo davvero tanto, visto anche il successo dell’anno scorso!

Stay tuned! :)

AgileIoT Funnel: le metodologie

Concludiamo il nostro viaggio attraverso l’AgileIoT Funnel, arrivando alla punta dell’iceberg. Dopo aver parlato della filosofia, dei principi e delle pratiche, esploriamo ora le due metodologie attualmente basate su di esse: Duttile e Fiotto.

agileiot funnel methodologies

Prima di proseguire, è fondamentale evidenziare che le struttura di AgileIoT consente di adottarne gli aspetti portanti senza essere legati alle specifiche metodologie. Questo aspetto è fondamentale poiché essi sono sempre validi al di la del processo, che va sempre adattato e contestualizzato.

Ma torniamo alle metodologie.

Duttile è il framework di processo principale, riassumibile dal Poster seguente:

duttile poster 097 mini

Duttile Poster

Duttile definisce un processo ricco ed articolato per la produzione di soluzioni legate al mondo dell’Internet of Things, orientato al Valore e alle soluzioni End-to-End. In particolare, la creazione di una specifica soluzione passa attraverso tre fasi ben delineate:

  • Prototype Phase: è la prima fase del processo. Viene definita la Vision, effettuata la fase di Prototipazione Veloce e creato il Product Backlog attraverso una fase di planning specifica;
  • Engineering Phase: è la fase in cui la soluzione viene Ingegnerizzata e Sviluppata. Si tratta, intuitivamente, della fase più corposa e più complessa dell’intero processo;
  • Workout Phase: è l’ultima fase focalizzata sul Delivery in esercizio, sul Supporto e sul Miglioramento Continuo.

La complessità intrinseca affida un ruolo fondamentale alla Solution Definiton of Done (sDoD), chiarendo in modo esplicito quando i seguenti Goal, contemplati da Duttile, possono ritenersi raggiunti.

Dualmente, chi preferisce un approccio in chiave Lean, può optare per Fiotto, che si sviluppa in chiave “Continuous Value” e “Continuous Deployment” per la realizzazione di soluzioni IoT secondo l’AgileIoT Manifesto.

fiotto poster sample

Fiotto Poster

Utilizzando gli elementi costituenti identificati in Duttile, Fiotto sfrutta il WorkPivot per passare dall’evidenza delle attività afferenti l’intero AgileIoT Team (verticali) a quelle del singolo Signal Temporary Team (orizzontali).

Questa trasformazione avviene visivamente grazie all’introduzione del D-ARCH (Do it for… Achieve Rapidly Customer Hopes), in cui le attività (Slot) sono identificate in funzione della loro specificità (Hardware, Firmware e Cloud – asse verticale) associate, contemporaneamente, all’ST2 (asse orizzontale) e al relativo Work in Progress limit (WIP-limit / WIP-l). Si vanno quindi ad enfatizzare le attività dei sub-team, specializzati sul singolo Signal, così come previsto dal Framework, supportando in modo visuale il Flashback per il riallineamento giornaliero.

Si conclude così il nostro viaggio attraverso l’AgileIoT Funnel, ma non alla scoperta di AgileIoT.

Stay tuned J

Nuovo Ask Me Anything con il team di GetLatestVersion il 31 gennaio.

Il 31 Gennaio 2017 GetLatestVersion organizza un nuovo AMA (Ask Me Anything) online. Per chi non lo sapesse l’AMA è un appuntamento in cui chiunque può partecipare e chiedere quello che si vuole sull’argomento in discussione ed il team di GLV cercherà :) di rispondere.

L’argomento come sempre è ALM su piattaforma TFS/VSTS, metodologie Agili e DevOps.

Potete registrarvi a questo indirizzo http://bit.ly/2hPgjgc

Vi aspettiamo.

Il Team di GetLatestVersion

AgileIoT Funnel: le pratiche

Quanto illustrato fin ora dell’AgileIoT Funnel, ovvero la filosofia ed i principi, pone le basi per un’azione efficace nella realizzazione di soluzioni dell’internet of things di mercato.

Ma per guidare in modo diretto tale attività vanno utilizzate e fatte proprie le Pratiche fondamentali di AgileIoT:

agileiot funnel practices 

Nello specifico si evidenziano 5 pratiche:

  • Fast Prototyping, che ha lo scopo di validare la sostenibilità generale della soluzione. Sostenibilità che passa attraverso 8 bobble- aspects, rappresentanti i principali aspetti annessi ad una soluzione IoT: Energy, Hardware, Code, Data Flow, Cloud, Security, Delivery e Legal. 
  • Make-Measure-Learn, che spinge a sperimentare rapidamente le diverse ipotesi e le diverse assunzioni:
    • Make: creo un prototipo per testare le ipotesi annesse alla Vision e per iniziare a consolidare il team di riferimento;
    • Measure: analizzo il prototipo in funzione dei Goal e delle relative metriche. Inoltre verifico se l’organizzazione aziendale ed il team sono a proprio agio per la realizzazione della soluzione;
    • Learn: attuo le opportune modifiche in funzione dei risultati.
  • Flashback, porta il team a confrontarsi sull’avanzamento dello sviluppo, creando un’azione di allineamento rapido specifica per il mondo dell’IoT in cui è l’osservatore ad andare direttamente al desk su viene presentato l’attuale manufatto in lavorazione e ponendo un numero limitato di domande temporalmente vincolate;
  • Continuous Improvement, che spinge a ridurre al minimo gli interventi sugli aspetti hardware della soluzione, azione estremamente costosa e lunga. L’approccio è quello di intervenire sul firmware, sui servizi e sul cloud in modo da poter costantemente migliorare la soluzione complessiva e intervenire con workaround in caso di problemi dei dispositivi fisici;
  • Continuous Integration, spinge a integrare costantemente ed il prima possibile tutte le differenti anime della soluzione, in modo da rilevare quanto prima i difetti ed i problemi esistenti ed intervenire rapidamente per risolverli. Si tratta di un’azione fondamentale per ridurre i costi associati a mal funzionamenti o riposte inattese dal sistema.

Queste pratiche operative consentono di attivare l’azione complessiva del team in funzione di quelli che sono gli obiettivi di collaborazione e condivisione degli obiettivi, fondamentali per il successo di ogni iniziativa.

Stay tuned J

AgileIoT Funnel: i principi

A legare il mondo delle pratiche (cosa fare) con la filosofia (visione) alla base di AgileIoT troviamo i Principi, ovvero un insieme di fattori che hanno l’ambizione di Ispirare il modo in cui viene approcciata la realizzazione di una soluzione IoT.

agileiot funnel principles

Nello specifico, AgileIoT individua 4 principi fondamentali:

  • Non si tratta di software, hardware o servizi: è l’insieme che va realizzato bene! Questo principio spinge il team cross-skill e cross-functional a lavorare a stretto contatto, coordinandosi costantemente e andando ad operare in chiave incrementale in modo da far emergere il prima possibile i problemi e risolverli nel modo più efficace dato il contesto specifico;
  • Pensare meno e agire prima! Lo sviluppo di una soluzione IoT passa attraverso l’utilizzo di tecnologie abilitanti che consentono di sperimentare rapidamente, e a basso costo relativo, le diverse ipotesi che si presentano durante l’intero ciclo di ALM (o PLM che si voglia). È quindi possibile ridurre al minimo la fase di “progettazione a tavolino” per focalizzarsi sulla “costruzione a tavolino” grazie ai diversi EVK disponibili sul mercato.
  • Semplice è meglio!  Più si è in grado di rendere semplice la propria soluzione, più si può essere confidenti che la stessa abbia la complessità minima necessaria e quindi possa evolvere in modo efficace e sostenibile. “Semplice” va inteso come “comprensibile” e “manutenibile”, obiettivo che si raggiungere utilizzando in modo preferenziale approcci standard e strumenti consolidati.
  • Se non puoi ricordarlo, non puoi migliorarlo! L’utilizzo di strumenti di Visual Management è fondamentale per poter avere prontezza dello stato di avanzamento complessivo della realizzazione della soluzione. Il più classico degli strumenti in quest’ottica è la Kanban Board.

Come si evidenzia, i principi non danno delle indicazioni operative, cosa demandato alle pratiche, ma comincia ad inserire quei tasselli che vanno a consolidare in contesto pratico di operatività dell’AgileIoT Team.

 

Sta tuned >J