DevOps, Agile e Lean: non è più concesso ignorarli

DevOps è diventato ormai il killer-approach per la delivery di soluzioni che siano in grado di avere un basso time-to-market e ottimizzare l’intero value stream aziendale annesso.

Devo ammettere che da sempre considero DevOps la naturale estensione dell’Agile, con una positiva contaminazione dei principi Lean (che ricordo sono derivati dal mondo manifatturiero), cosa che mi porta ad amare poco il termine “DevOps” in sé perché, almeno lessicalmente, sembra limitare il tutto ai Developer ed agli Operation oltre che all’ambito IT.

solution s curve

Detto questo, è importante evidenziare che DevOps non “appartiene” solo al mondo dell’IT, bensì è un approccio che spinge a far propri i 3 principi portanti: Flow, Feedback e Learning (così come sono oggi riformulati rispetto alla prima enunciazione), per un’azione efficace nella creazione di Servizi e Prodotti negli ambiti più diversi. A tal proposito segnalo l’interessante approfondimento degli amici di AgileReloaded: L’orizzonte allargato di Agile.

Resta comunque indubbio che l’IT è la culla di DevOps, trasformando gradualmente le azioni annesse allo sviluppo di soluzioni complesse da attività “artigianali” ad attività più “ingegneristiche”, con precisi elementi di riferimento. Ciò fa si che le aziende percepiscano sempre più il proprio IT per quello che deve essere: un Asset strategico al servizio del Business e non un Centro di Costo.

E le parole sono estremamente importanti: parlare di “divisione IT” porta ad immaginare un Silos a sé stante con regole proprie e ben identificabili. Ciò è quanto di più semplicistico si possa immaginare perché l’IT è estremamente pervasivo e condiziona, restandone a sua volta condizionato, tutte le aree aziendali.

La centralità di DevOps, anche se non del tutto maturata nel nostro contesto nazionale, è confermata da un’indagine di IDC che oggi ne vede l’adozione in oltre il 70% delle principali aziende mondiali (con livelli diversi e penetrazione diversa) e stima il superamento della soglia dell’80% entro il 2019.

Ma questa penetrazione così profonda, quali sfide comporta?

Anche qui dobbiamo avere una visione olistica del contesto poiché molte aziende che provano a sperimentare DevOps su un progetto pilota o un’area di riferimento, si accorgono rapidamente che è necessario coinvolgere tutte le diverse funzioni aziendali, per cui lo Scaling diventa inevitabile e anche estremamente veloce.

Ma torniamo alla nostra precedente domanda, andando ad evidenziare le sfide primarie che ogni azienda incontra nell’adozione concreta di DevOps e, quindi, nel profondo percorso di trasformazione e cambiamento Culturale:

  • Sponsorship aziendale: adottare DevOps significa investire e avere pazienza nell’ottenere risultati tangibili localizzati a breve termine, ma complessivamente visibili nel medio termine. L’investimento è sia in termini finanziari che in termini di impegno delle Persone (vi prego… non usate il termine “risorse” per indicarle!), per cui solo se è uno dei massimi dirigenti aziendali (CxO) a supportarla, l’adozione potrà avere il sostegno necessario e raggiungere risultati lusinghieri;
  • Abbandonare le rigide strutture di controllo del passato: una Cultura volta al continuo miglioramento, basata su applicazioni empiriche, mal si lega con una organizzazione aziendale basata sul pattern command-and-control, in cui è difficile cambiare. I manager devono imparare a delegare, mentre le linee più operative ad avere coraggio, cercando di rendere la struttura più flessibile ma soprattutto focalizzata sul value stream;
  • Il Core know-how deve essere in azienda: considerare l’IT un “centro di costo” ha portato negli anni ad abusare dell’outsourcing, perdendo conoscenza, controllo e capacità di gestire le nuove sfide di mercato. Questa tendenza deve trasformarsi in un’outsourcing bilanciato in cui gli elementi chiave, per rispondere efficacemente e prontamente al Business, sono all’interno e ci si appoggia ad un’outsourcing controllato per gli elementi corollari (abbiamo parlato abbondantemente di questo aspetto nella serie DevOps and Outsourcing: OutOps);
  • Ridurre la resistenza al cambiamento: DevOps è Cultura, e una trasformazione aziendale nella sua direzione comporta nuovi modelli organizzativi, nuovi ruoli e un diverso approccio alle prospettive di carriera. Questi aspetti spingono ad aumentare la resistenza al cambiamento per restare nella propria “confort zone” e ridurre al minimo la necessità di rimettersi in discussione. È compito dell’organizzazione fare chiarezza su questi aspetti e creare le opportunità a sostegno dei desideri intersechi (leggasi Management 3.0) ed estrinsechi di ogni singolo collaboratore;
  • Fail Fast o meglio… Learn Fast: il fallimento è una componente poco desiderata ma fortemente presente, e a volte indispensabile, nel mondo dei sistemi complessi. Il mantra non deve essere: “non fallire mai…” ma “fallire il meno possibile e quando accade far tesoro del fallimento stesso”. In pratica ogni fallimento diventa un tassello nel cambiamento e nell’ottimizzazione complessiva… chiaramente questo non vuol dire fallire sempre!
  • Mai applicare qualcosa “out-of-the-book”: DevOps è un cambiamento culturale da ricamare nel proprio contesto e come tale necessita di essere capito profondamente nelle sue varie sfaccettature. Non basta comprare un libro e leggere qualche blog per iniziare la propria trasformazione: il rischio di fallimento è estremamente elevato! Meglio affidarsi al supporto di professionisti che accompagnano l’organizzazione a muovere i primi passi e ad individuare gli elementi focali che consentono affacciarsi al mondo DevOps con maggiore fiducia e minori incertezze.

Se tutto questo vi spaventa o vi fa tornare nel “vostro mondo” fatevi una domanda: possiamo permetterci di non cambiare quando tutto sta evolvendo ad un ritmo frenetico ed inarrestabile?

In fondo bisogna lasciare andare il passato per essere padroni del futuro.

Stay tuned J

Agile@School 2017 – Primo incontro

Il progetto Agile@School è ufficialmente ricominciato. E rispetto all’anno scorso, con una marcia in più, vista la grande partecipazione. Quasi una ventina di persone, tante idee e progetti, tanti team e quindi, cambiamento di metodologia. 

L’anno scorso abbiamo introdotto il concetto di Scrum ed i relativi principi e pratiche. Questa volta abbiamo pensato, proprio per la natura distribuita dei partecipanti, di passare a Kanban. Senza entrare troppo nel dettaglio metodologico, avremo:
– Alcuni micro team, che chiameremo “task force”, prendendo spunto da un termine usato (in modo diverso in realtà) da Mauro Servienti nelle sue slide sul suo lavoro in Particular
– Una Kanban board
– La definizione delle personas
– La definizione della customer journey e di una Story Map
– Alcune cerimonie utili all’allineamento delle persone nel complesso
Le task force
Come detto in precedenza, il termine è stato preso da un’interessantissima sessione di Mauro Servienti, in cui si racconta la sua esperienza sul suo posto di lavoro, una realtà molto distribuita, anche geograficamente, che necessita di una gestione ben studiata. Nelle slide si parla di task force per indicare un elenco di “volontari” che si uniscono per risolvere un problema (o una issue). Ogni task force effettua un meeting per capire come e cosa fare al fine di portare l’elemento dal backlog fino alla completa implementazione e, ovviamente, inizia a lavorare per portare a compimento l’implementazione stessa. Il tutto seguendo un ciclo di vita (lifecycle) che dura quanto serve a portare a termine il tutto. 
In Agile@School avremo quindi sei task force, sei gruppi di due o tre persone che prenderanno in carico le implementazioni e le relative analisi. Nel nostro caso avremo una task force per progetto, ed ogni progetto sarà una tesina differente da preparare entro i prossimi tre mesi.
La Kanban board
Vedendo l’insieme dei ragazzi come un grande team di circa venti persone, abbiamo deciso di organizzare la nostra Kanban board non solo con le colonne che identificano il processo di ogni elemento, bensì aggiungendo swimlane, ovvero linee orizzontali che distinguono ogni prima release di ogni progetto, e quindi, task force:
Sulla foto indicata ci sono tutti i termini propri di Visual Studio Team Service, e sono stati tutti descritti ai ragazzi. Abbiamo quindi un glossario comune, in modo da potersi esprimere con un linguaggio comune. Anche questo dà valore aggiunto.
Le personas
Ogni membro delle task force ha compilato una scheda appositamente preparata, per dare indicazioni interessanti su interessi, obbiettivi ed informazioni generali. Perché scrivere di sé? Perché conoscersi è il primo passo verso la costruzione di una fiducia reciproca e di trasparenza, necessarie per avere team solidi e produttivi. La scheda delle personas proposta, molto semplice, è la seguente:
Perché “ruolo nel team”? Perché volevamo capire anche l’interesse dei ragazzi. Si tratta di una forzatura, è vero, ma è interessante osservare come i partecipanti si vedono all’interno di una squadra. Alla fine, adattare la scheda porterà ad avere ancora più informazioni utili.
La customer journey
Al termine del percorso introduttivo, dopo aver condiviso il glossario e le idee sul progetto, abbiamo assegnato un lavoro importante ai ragazzi. Fare la customer journey del progetto che hanno in testa. Il compito non è semplice, poiché sarà necessario identificare le problematiche e i requisiti funzionali richiesti per l’applicazione. Ogni task force dovrà creare il “viaggio” dell’utilizzatore, con tanto di cambiamento di umore nei vari momenti e con l’indicazione dei punti più critici e di quelli che danno valore aggiunto.
Unitamente alla customer journey, nel prossimo incontro, andremo a creare la story map di ogni progetto, che utilizzeremo per aggiungere le attività sulla board. Da lì, inizieremo a sviluppare e a gestire ogni task force.
Le cerimonie
Abbiamo identificato un paio di cerimonie ereditate da Scrum, al fine di rendere l’esperienza dei partecipanti interessante anche a livello di rapporti interpersonali ed inter-task force. Il nostro obbiettivo è quello di fare una review dei progetti, per portare quell che in gergo chiamiamo Awareness (consapevolezza), in modo da rendere chiaro a tutti chi sta facendo cosa e come sta affrontando le problematiche. Il fine è quello di condividere anche l’esperienza ottenuta dalla risoluzione delle anomalie e degli impedimenti. Infine, una retrospettiva, per migliorare il processo incontro dopo incontro. A parte queste due, non serviranno “daily meeting” o altri momenti di incontro.
Per tutto il resto, il progetto rimane simile a quello dell’anno scorso. Utilizzeremo Slack, Visual Studio Team Services, e lasceremo la libertà ai ragazzi nella scelta degli strumenti di sviluppo. Saremo Gabriele ed io, anche se, come già indicato in un post precedente, vorremmo seriamente far partire il progetto in altre realtà, per chiunque fosse interessato, professori compresi!
Vedremo come proseguirà.
Come sempre,
Stay Tuned! 

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