L’ossimoro implicito dell’ortodossia innaturale nel cambiamento stagnante

Quando si parla di cambiamento, è interessante notare come la maggior parte delle aziende ascoltano con interesse ma poi alzano subito una prima barriera dicendo “…eh… sarebbe bello, ma da noi è difficile convincere le persone a cambiare!”.

change resistance

Tale affermazione è supportata da diversi report che, annualmente, aggregano dati di centinaia di aziende a livello globale per capire lo stato di adozione dei diversi approcci ed evidenziare quelli che sono i principali problemi annessi.

change barriers

Al top della classifica c’è proprio la resistenza al cambiamento: organizzativa, culturale e personale. La questione è che, se non si trova il modo di superare questo impedimento primario, l’adozione di nuovi Approcci Culturali come Agile, Lean e DevOps perde di qualsiasi significato, riducendosi all’adozione di alcune pratiche o strumenti che portano un micro beneficio locale senza contribuire in modo sistematico al riassetto generale in funzione del business.

In queste condizioni basta un piccolo intoppo o un cambiamento al vertice per tirare conclusioni del tipo: “Mah… in fondo Agile non è che funzioni poi tanto, torniamo ad un approccio più tradizionale con maggiore controllo su ciò che accade” o anche “Vabbè, ma poi noi manager che fine facciamo in questo nuovo modo di impostare le cose? Forse è meglio attendere”.

Questo atteggiamento è estremamente pericoloso per qualsiasi azienda che voglia essere competitiva sul mercato ed è paradossalmente sbagliato per definizione: ognuno di noi, in quanto Persona, cambia implicitamente in modo costante, giorno per giorno, in relazione alle esperienze, ai problemi, alle opportunità, alle esigenze e così via. Quindi come si fa a dire che una persona non è incline al cambiamento quando lo fa di continuo?

La questione è che quando il cambiamento è esplicitato ed “comandato” dall’organizzazione, le Persone sono portate ad assumere un atteggiamento diffidente e farsi 1000 domande del perché si sta avviando tale processo.

Il tutto è ben rappresentato dal noto diagramma seguente, che trova le proprie origini nella ricerca (1969) effettuata dalla psichiatra svizzera Elisabeth Kübler-Ross in relazione alle reazioni che mostravano i pazienti quando gli veniva comunicata la prognosi di morte (si lo so è decisamente triste la sua nascita).

change acceptance

La curva indica il livello di motivazione ad accettare il cambiamento che la Persona deve “subire” e che non è sotto la sua governance, e, su di essa, sono rappresentati i principali stati (fasi) emotivi in cui viene a trovarsi.

Lo studio originale individuava 5 stati: negazione, rabbia, contrattazione, depressione, accettazione, mentre negli anni le diverse contestualizzazioni hanno portato ad avere i 7 stati indicati nella figura precedente e generalmente accettati oggi:

  • Negazione, non accettazione della novità;
  • Realizzazione, si prende atto che qualcosa è avvenuto e se ne cerca riscontro;
  • Frustrazione, ci si difende implicitamente da quanto sta avvenendo;
  • Accettazione, si assume un atteggiamento rassegnato con scarsa propositività;
  • Sperimentazione, si cerca di capire come posizionarsi nel nuovo contesto;
  • Riflessione, si scava in dettaglio su ciò che il cambiamento sta comportando, integrandosi con esso e aumentando la propria produttività;
  • Integrazione, si è a proprio agio con il nuovo contesto.

Per quanto illuminate, questa curva non risponde però ad una domanda evidente: perché in alcuni casi il cambiamento ha successo ed in altri no? Per rispondere ad essa possiamo utilizzare l’Equazione del Cambiamento (o anche Formula di Gleicher) che descrive in maniera lineare quando scatta il cambiamento:

C = I x V x P > S

Quindi il Cambiamento avviene quando la risultate dell’Insoddisfazione (I), della Vision (V) e dei Primi Passi (P) compiuti nella sua direzione è maggiore dello Status quo (S) attuale. Tali fattori devono sussistere contemporaneamente per portare al cambiamento: se, banalmente, non vivo in modo insoddisfacente la situazione attuale, non c’è leva che mi porterà a cambiare.

Ma come possiamo fare allora a spingere al cambiamento le Persone e l’organizzazione nel complesso? Uno degli approcci più apprezzati è il Change Management Process (CMP) di John Kotter, professore alla Harvard Business School e autore del libro “Leading Change”, che consta di 8 passi:

  • Sviluppare un senso di urgenza
  • Costruire il team che guiderà il cambiamento
  • Creare una visione chiara
  • Comunicare la visione
  • Rimuovere gli ostacoli
  • Creare piccoli successi nell’immediato
  • Non mollare la presa
  • Fare attecchire il cambiamento

Questi passi sono spesso anche alla base anche degli ultimi ritrovati come The Lean Change Method di Jeff Anderson e, probabilmente, ognuno di noi ne ha avvertito la presenza durante una fase di cambiamento che l’ha interessato direttamente. Da essi è possibile estrarre alcuni principi base che gli agenti del cambiamento devono tener presenti nella loro azione di promozione al cambiamento stesso:

  • Awareness, creare una consapevolezza generale del perché è necessario cambiare;
  • Desire, far emergere il desiderio al cambiamento e spinge le persone coinvolte ad avere un atteggiamento proattivo;
  • Knowledge, esplicitare come il cambiamento dovrebbe avvenire;
  • Ability, costruire nuovi modelli organizzativi che supportino il cambiamento in modo naturale;
  • Reinforcement, sostenere e supportare costantemente il cambiamento.

Come affermato da Sun Tzu: “Combatti con metodi ortodossi, vinci con metodi straordinari“… e questo è solo l’inizio….

 

Stay tuned J

La dissonanza dell’effetto Zeigarnik nello spezzatino del tempo

Ogni strategia di business richiede un programma di attuazione che abbina la flessibilità alla chiarezza degli obiettivi da raggiungere, sia in termini di mercato che di profitto. Ciò implica che una fetta, più o meno consistente, della nostra azienda si organizza per concretizzare il programma stesso e far si che esso sia sempre coerente con la Vision e Mission aziendale, contribuendo a raggiungerla.

A livello operativo è nomarle creare appositi gruppi di lavoro che pianificano, gestiscono e reagiscono alla risposta del mercato e che sono spesso dedicati in modo quasi esclusivo all’obiettivo complessivo, ritenuto troppo complesso da poter essere gestito in concorrenza. Questo focus diventa fondamentale per permettere al gruppo di tenere sempre presente l’obiettivo generale da raggiungere, andando a contestualizzare il tutto rispetto alla propria organizzazione e al mercato di riferimento. Questi ultimi, come è noto, si influenzano a vicenda.

Nel mondo dell’IT, il focus e la concentrazione su poche attività specifiche, chissà perché, è quasi sempre visto come un limite o una incapacità, se non addirittura una scarsa attitudine al lavoro. Spesso le Persone sono considerate alla stregua di automi da poter allocare su attività multiple per percentuali ridicole di tempo senza neanche rendere chiaro il senso del loro stesso lavoro.

the multitasking myth

Tutti voi condividete con me quanto sia tristemente comune imbattersi in pianificazioni che creano il fantomatico “spezzatino del tempo”: “durante le prossime settimane, Tizio sarà alloca per il 10% sul progetto A, il 25% su quello B, il 50% su quell’altro e il 20 a supporto del precedente”.. ovviamente non ci si accontenta del 100%, ma si abbonda sempre un po’, cosa che ricorda l’esilarante scena in cui Totò diceva a Peppino De Filippo di non risparmiare sull’uso della punteggiatura: “…ma sì, fai vedere che abbondiamo… Abbondandis in abbondandum” (dettatura della lettera in Totò Peppino e la Malafemmena).

La domanda è: serve a qualcosa questo tipo di pianificazione? Si, a far impazzire le Persone e a ridurre drammaticamente la loro Produttività!

crazy productive people

Ma come si può anche solo minimante pensare che una Persona possa esprimersi professionalmente al meglio se la sua attività viene trasformata in una sorta di “zapping” su task disconnessi, costringendolo continuamente a cambiare focus operativo, sia rispetto al prodotto che rispetto alle relazioni che caratterizzano l’ambiente con cui operare.

È empiricamente dimostrato che una persona può seguire al massimo due progetti in contemporanea (non lo dico io, ma diversi studi antropologici): uno principale e uno secondario che serve anche come “distrazione”. Se si comincia a saltellare da un progetto all’altro, aumenta solo l’entropia, incrementando il costo del cambiamento di contesto, e acuendo il poco noto, ma estremamente significativo, effetto Zeigarnik.

Tale effetto (osservato e formalizzato dalla psicologa lituana Bluma Zeigarnik) evidenzia come, tipicamente, quando si lascia incompiuto un compito a cui ci si è dedicati, si sperimentano pensieri intrusivi che rendono difficile concentrarsi su altro: in soldoni ci ricordiamo più facilmente delle cose che non abbiamo portato a termine rispetto a quelle completate.
Questo perché, sembra essere nella natura umana l’indole di finire quanto avviato e, se non riusciamo a farlo, tendiamo a sperimentare una dissonanza.

Quindi, più cose lasciamo in sospeso più la nostra mente cerca di ricordarcele, impedendoci di concentraci su altro.

Morale della favola: diamo alle Persone la possibilità di portare a termine, al meglio, le proprie attività, evitando di impegnarle in decine di progetti differenti solo perché “così si utilizza al meglio la risorsa”: avvaliamoci della professionalità dei nostri collaboratori senza avere la presunzione di volerne gestire il tempo.

Stay tuned J

L’esponenziale negativo dell’equazione lineare

Lavorando con aziende di medie e grandi dimensioni, mi capita spesso di imbattermi in discussioni riguardanti l’outsourcing dell’IT e di come esso rappresenti spesso una strategia utilizzata dal top management per tagliare idealmente i costi.

Sicuramente, finché esiste un buon bilanciamento tra IT interno ed outsourcing, la strategia può effettivamente rilevarsi vincente, il problema è quando si passa all’outsourcing estremo: “l’IT è esclusivamente un centro di costo, per cui lo metto fuori e pago solo per i servizi che richiedo”.

In linea teorica, questa soluzione potrebbe sembrare la panacea di tutti i mali, tanto che i costi potrebbero essere teoricamente rappresentati da una comune equazione lineare:

oustourcing cost eq lineare

costi = Δ * TCF

con TotalCostFactor (TCF) = costo servizio * n. servizi richiesti

ragionando su un costo unitario medio uguale indipendentemente dalla tipologia di servizi.

Il Δ è un valore minore o uguale ad 1 (mediamente tra 0.8 e 1) che diminuisce all’aumentare dei servizi richiesti e rappresenta lo sconto che tipicamente si chiede quando la quantità di servizi richiesti aumenta (giornate).
In realtà questa pia illusione di risparmio comincia ben presto a scontrarsi con diversi problemi:

  • Perdita del know-how;
  • Perdita della sinergia tra strategia e operatività;
  • Riduzione della capacità di reazione rispetto alle esigenze del mercato;
  • Scarsa evidenza dei rischi e delle problematiche tecnico/tecnologiche.

che formano un insieme che definiremo “Independent Debt”.

Il “Debito di Indipendenza” spesso inizialmente sfugge anche alle più attente valutazioni del management, diventando con il tempo un boomerang per l’organizzazione che può venirsi a trovare letteralmente in balia dell’outsourcer e quindi soggetta al rischio che il potere contrattuale passi proprio nelle mani di quest’ultimo.

In tale scenario, i costi, forse inizialmente più bassi perché il fornitore voleva entrare nelle “nostre grazie”, cominciano a crescere (per inteso: le richieste possono essere legittime, non dettate da pigra furbizia) e si sommano a quelli dovuti all’impatto negativo dell’insieme dei problemi di cui sopra.

outsourcing cost

Ciò trasforma la nostra equazione lineare in una equazione esponenziale in cui i costi cominciano a salire in modo rilevante senza che si abbiano più gli strumenti per contrastare il fenomeno.

outsourcing cost eq esponenziale

costi = e^TCF  

con TCF = (Δ aumento dei costi servizi * costo servizio * n. servizi richiesti) + costo del Debito di Indipendenza

Nel momento in cui il peso non sarà più sostenibile, all’azienda resterà una sola cosa da fare: riportare tutto l’IT all’interno e… ricominciare da capo!

Questo comporterà un investimento che sicuramente annullerà e supererà tutti i benefici eventualmente ottenuti con la politica di outsorcing estremo.

 

Stay tuned J

DevOps e l’ecosistema Microsoft, parte 6: Conclusioni

Questa serie di articoli ci ha permesso di raccontare come la filosofia DevOps viene ottimamente supportata dalla piattaforma Visual Studio Team Services (VSTS, on-prem con TFS) con il supporto anche di altri applicativi a corredo, sempre Microsoft o di terze parti.

Per comodità si riporta la big picture generale da cui siamo partiti, andando nuovamente a sottolineare la centralità delle quattro aree di cui si è discusso.

ms devops philosophy

DevOps on Microsoft Platform

La cosa interessante è che VSTS è una piattaforma lineare in cui le diverse funzionalità sono messe ad incastro per supportare in modo logico le fasi di delivery e le azioni specifiche della delivery pipeline annessa.

others delivery pipeline

Delivery Pipeline

Da circa due anni, VSTS è diventata la piattaforma di riferimento per operare in modo organico in ottica DevOps (Magic Quadrant for Enterprise Agile Planning Tools, 27 aprile 2017), anche grazie alla sua totale indipendenza da framework di sviluppo proprietari e all’apertura sempre più convita e consolidata al mondo open source.

others gartner2017

Magic Quadrant for Enterprise Agile Planning Tools

Sia i dev, che gli ops, che il management, possono avere una visione d’insieme di quanto sta accadendo durante tutte le fasi di realizzazione della soluzione, intervenendo direttamente e dando suggerimenti laddove dovessero ravvisare potenziali problemi.

Utile sottolineare che la disponibilità delle dashboard di progetto consentono di “disegnare” viste opportunamente pensate per il management, che può, in tal modo, avere visione di quanto sta accadendo ed intraprendere azioni a supporto nel caso ci siano degli scostamenti rispetto alle attese di pianificazione e di business.

Operativamente, resta sempre e comunque indispensabile partire da un’azione di transformation che faccia prendere coscienza all’azienda dei suoi punti di forza e debolezza, andando ad agire sulle cinque leve evidenziate dal framework CALMS:

  • Culture, gestire il cambiamento focalizzandosi sulla collaborazione e la comunicazione;
  • Automation, rimuovere le azioni manuali lungo la catena del valore;
  • Lean, utilizzare i principi Lean per velocizzare, standardizzare e rendere efficienti le attività;
  • Metrics, misurare qualsiasi cosa, utilizzando i risultati per rifinire costantemente le attività;
  • Sharing, condividere le esperienze di successo e di fallimento per una crescita diffusa.

others calms

 CALMS, Damon Edwards e Jez Humble

Questo per evitare che si abbia l’illusione che il solo adottare VSTS significhi “essere DevOps” tranne poi risvegliarsi con una situazione deludente nonostante le grandi aspettative. Le cinque leve di CALMS devono essere contemplate ad ogni step di miglioramento con l’obiettivo di livellarne la maturità nel proprio contesto.

Si chiude qui questo intenso approfondimento. Sperando di avervi dato interessanti spunti sia su DevOps che su VSTS, vi saluto e vi invito ad inviarmi i vostri feedback.

 

Post precedenti della serie:

Sapevatelo VSTS: Variable group nelle build

Indubbiamente il build system di VSTS / TFS è una delle parti che sta introducendo molte innovazioni, soprattutto dopo la completa riscrittura iniziata oramai due anni fa. Una delle funzionalità più interessanti, e che è ancora poco conosciuta sono i gruppi di variabili, descritti qui.

In poche parole potete generare un insieme di variabili e dargli un nome, per poter poi riutilizzare questo inisieme di variabili in qualsiasi build del progetto.

In questo modo l’amministrazione delle build risulta molto semplificata, soprattutto in quei casi in cui abbiamo molte build con serie di passi simili (CI, SonarQube, Package, etc). Grazie ai Variable Groups possiamo generare un gruppo di variabili valido per tutto il progetto ed usarlo semplicemente in tutte le build di cui abbiamo bisogno.

Happy VSTS.

DevOps e l’ecosistema Microsoft, parte 5: Monitor and Learn

Con la build in produzione, diventa fondamentale avere un’appropriata strategia di monitoraggio, sfruttando le informazioni ottenute per fornire rapidamente feedback al team di delivery. Grazie ad una piattaforma integrata come VSTS è possibile applicare le pratiche di IT Intelligence (così come contemplate da Disciplined Agile 2) per capire, con dati aggiornati in tempo reale, il modo in cui il team di delivery opera, come si migliora e, soprattutto, quanto è realmente allineato con gli obiettivi di business.

ms devops 4

 Monitor and Learn

Su questo fronte, la risposta di Microsoft si concretizza in Application Insight, basato su Azure, e orientato a monitorare e misurare una serie di parametri vitali del nostro servizio: Disponibilità, Performance, Utilizzo, Errori, Dipendenze. Esiste anche una specifica estensione per VSTS, dal nome omologo, che consente di aggiungere una tile nella dashboard di progetto e visualizzare una sintesi dei dati.

azure application insight

Application Insight

In realtà, gli strumenti offerti da Azure analizzano anche altri aspetti più tecnici come, ad esempio, il traffico http in tempo reale, utili per intervenire in modo puntale direttamente alla radice del problema, in perfetta chiave Root Analysis.

azure http analisys

Analisi in tempo reale del traffico HTTP

Grazie al Continuous Monitoring si è in grado di acquisire una serie di informazioni che consentono di intervenire rapidamente in caso di problemi (si pensi ad un picco di utilizzo del nostro servizio in occasione di un evento particolare), reagendo prontamente e rendendo le relative azioni di risoluzione standard/automatizzate in modo che il problema possa essere gestito in anticipo o, come detto, risolto all’origine. Questo significa, ad esempio, creare una serie di test automatizzati specifici che siano in grado di riprodurre le particolari condizioni di operatività e verificare che le contromisure adottate siano efficaci. I miglioramenti ottenuti devono sempre essere misurabili oggettivamente, cosa fattibile con una serie di indicatori. Tra i più rilevanti, il cui controllo deve essere sempre un must, si evidenziano: il Mean Time To Detect (MTTD) e il Mean Time To Repair (MTTR).

ms devops 4b

Continuous Monitoring

Oltre a garantire l’affidabilità della soluzione, è indispensabile sfruttare al meglio le informazioni per cominciare a pensare al “next step”, ovvero capire se il tutto è in linea con quanto atteso dagli utenti e se si sta effettivamente creando Valore per loro e per la propria azienda.

Risulta quindi evidente la necessità di non perdere per strada le Retrospettive e le Review, tante care al mondo Agile. Si tratta dei momenti in cui il team e i diversi stakeholder si confrontano, analizzano cosa è accaduto durante l’ultimo ciclo di sviluppo e si pongono obiettivi di miglioramento raggiungibili per il successivo.

Per supportare queste attività, ad oggi, VSTS non dispone di elementi specifici e anche il marketplace ne è sprovvisto. Quello che si può fare è adottare un workaround come l’estensione Wiki che, aggiungendo un wiki al progetto, consente di memorizzare differenti tipologie di informazioni più o meno strutturate, tra cui, ad esempio, il resoconto della Retrospettiva e gli obiettivi di miglioramento identificati.

extension wiki

L’estensione Wiki

I feedback ottenuti dagli utenti (o dai key stakeholder) durante i diversi momenti di allineamento si tramutano in input per il Grooming del Backlog e quindi vengono gestiti implicitamente dalla (ri)organizzazione delle Feature e delle User Story. Il suggerimento è quello di riportare, sempre, i punti salienti delle discussioni e a tale scopo potete nuovamente sfruttare il wiki.

Con questo quinto appuntamento ci avviamo alla conclusione della serie di articoli dedicati a DevOps e l’ecosistema Microsoft. Nel prossimo ed ultimo post andremo a trarre un quadro riassuntivo di quanto detto e faremo delle considerazioni operative a riguardo.

 

Post precedenti della serie:

La defezione dello scopo elementare

Non so voi ma io sono veramente frustrato da come i cosiddetti professionisti dell’informatica continuano a creare prodotti che hanno una usabilità pari a quella del manuale di istruzioni per il montaggio di una centrale atomica, laddove ne esistesse uno. Tutto ciò ti fa letteralmente sentire un demente (non importa quanti diplomi, lauree, master o… computer hai a casa) e ti spinge alla ricerca di una società con servizi che abbiano più a cuore i propri utenti.

Il mondo dell’IT è pieno di soluzioni di merda!

Partiamo da qui per essere onesti e per poter capire dove intervenire e cominciare a migliorare una situazione che sembra peggiorare continuamente.

panic

Ma come si fa: siti web in cui non si trova mai quello che serve, messaggi di errore tecnici o generici che rimandano ad un call center che non risponde mai se non dopo minuti di attesa e con soluzioni generiche del tipo “ma lei è sicuro di aver inserito l’email con il simbolo della chiocciola?…” a cui ti viene voglia di rispondere stizzito: “Certo che no! L’ho inserita scrivendo la parola “chiocciola””… ma che domanda è ?!?!!!

Non parliamo dei sistemi di autenticazione: username fatte da decine di caratteri, tanto che non basta un post-it per contenerle, password che scado ogni 30giorni e che devi obbligatoriamente cambiare senza poter riutilizzare le ultime 3-4, in aggiunta token e sms di ogni tipo…. e poi ci si prende anche il lusso di bloccare gli account dopo “pochi” tentativi con la scusa “eh… ma è per vostra sicurezza!” Ma che diamine significa?!!

Il risultato è che ognuno di noi ha obbligatoriamente un foglio, o uno strumento digitale, in cui ha annotato le informazioni dei 15-20 account che mediamente abbiamo. Non è umanamente possibile ricordarsi sta roba!

E le App mobile…. oh le App mobile.. un universo in cui tutto è concesso!

Un mondo strano, in cui si fa la corsa a chi ne ha di più (al liceo i giochi erano ben altri J), ma poi, quando le si usa, fanno giusto due cosine e rimandano al sito web, ovviamente non progettato minimamente per una user experience accettabile su mobile… e sottolineo user experience e non “responsive”… parola tanto cara, ma che in soldoni “ridimensiona” il sito per i diversi dispositivi, tenendo inalterato, nel migliore dei casi, il modo di utilizzarlo.

Basta!!!!!!!!!

Vi prego, tiriamo tutti un bel sospiro e contiamo fino 10 prima di iniziare il nostro prossimo progetto! Si, perché è nostra responsabilità, quali professionisti, aiutare e indirizzare chi ci chiede di realizzare una soluzione a supporto del proprio business. Non importa quale tra il milione di titoli che accompagnano il nostro settore (con una predominanza di “chief”, capi di qualcosa che non c’è) abbiamo: si tratta di una nostra responsabilità, punto e basta!

Quando il committente ci parla, non pensiamo “quale linguaggio di programmazione userò per la mia App”, piuttosto chiediamogli “fammi passare il tempo necessario con gli utenti potenziali in modo da rendere l’utilizzo della soluzione semplice e funzionale alle tue esigenze e a quelle dei tuoi utenti”.

Sedendovi in un’auto, cosa vi aspettate di fare: inserire la chiave, accenderla e iniziare il vostro viaggio. Non è un plus, è il motivo per cui l’avete comprata. Perché quando si usa un software questa deve essere una “speranza”, mettendo già in conto che lo stesso farà cose strane e che si è fortunati se si riesce almeno ad utilizzarlo, quasi lo facciate solo perché siete obbligati e non perché potete averne un vantaggio.

Ricordiamoci sempre che le soluzioni software sono strategiche per il business e vanno realizzate con tale obiettivo… il resto è noia… come diceva un noto cantante del Bel Paese.

Stay tuned J

DevOps e l’ecosistema Microsoft, parte 4: Release

Completato lo sviluppo del codice e dei test di unità annessi alla specifica Storia (ovviamente gli unit test devono essere “green”, ossia superati ;-)), la build intraprendere il suo viaggio verso i sistemi di produzione attraversando una serie di ambienti (environment) atti a comprovarne specifici aspetti funzionali e qualitativi.

ms devops 3

Release

Si entra così nel mondo della Continuous Delivery (e Continuous Deployment se si arriva fino in produzione), le cui azioni interessano almeno quattro ambienti primari: quello per i test funzionali (o di accettazione), quello per i test di integrazione e security, quello per gli stress test e l’ambiente di produzione stesso. È importante evidenziare come per test di integrazione si intendano i test dell’integrazione con gli ambienti e i servizi terzi a supporto (come l’istanza del DB in produzione, i servizi di piattaforma, ecc) che prima erano stati sostituiti con dei mock-up per consentire di concentrarsi sulla verifica esclusiva della soluzione in sé, senza che la stessa fosse condizionata da fattori esterni. I test di integrazione del codice sviluppato sono, come abbiamo visto, eseguiti nel processo di Continuous Integration.

ms devops 3b

Continuous Delivery

Lo strumento principe per gestire tali aspetti in VSTS è Release, il cui cuore operativo è rappresentato dalla Release Definiton che consente di impostare le azioni annesse ad ogni singolo ambiente coinvolto nel processo di rilascio della nuova build.

vsts release

Release

Idealmente, gli ambienti possono essere visti come Work Center (Lean Manufactoring) da attraversare per far si che la build divenga “ready to release” e possa essere dispiegata (più o meno in modo automatizzato) sugli ambienti di produzione.

vsts release environments

Gestione degli Ambienti e dei Task di delivery

È fondamentale sottolineare come il provisioning (attivazione) degli ambienti dovrebbe avviene il più possibile in modo automatizzato, sfruttando l’approccio Infrastructure as a Service. Questo perché l’obiettivo da perseguire è quello di rendere del tutto autonomi i dev nella creazione/distruzione degli ambienti di test, mentre gli ops si occupano della gestione dell’infrastruttura e dei tool a supporto, oltre a scrivere a due mani, proprio con i dev, i diversi script afferenti. Tra le soluzioni relative “made in Redmond” troviamo Azure Release Management (ARM), che consente di attivare risorse “on-demand” sul cloud Azure.

Con ARM la configurazione dell’infrastruttura a supporto avviene attraverso script che sfruttano la notazione JSON, andando a creare un vero e proprio “artefatto” il cui ciclo di vita può essere gestito esattamente come avviene per il codice sorgente della soluzione in sviluppo.

azure rm template lifecycle 1

azure rm template lifecycle 2

IaaS Lifecycle

Una vota creato lo script ARM, per eseguirlo è possibile inserire nella gestione di Release lo specifico task, andando ad attivare le risorse in esso descritte sulla specifica sottoscrizione Azure.

vsts arm task

ARM tasks

Il dispiegamento sull’ambiente di verifica funzionale è fondamentale per consentire l’esecuzione degli User Acceptance Test (UAT) da parte del team di Quality Assurance (o del team stesso di sviluppo se il progetto è di piccole dimensioni e lavora, ad esempio, in Scrum) ma, soprattutto, da parte dell’utente finale, che può fornire feedback preziosi. Tale ambiente è quello che può, ad esempio, essere sfruttato durante l’Iteration/Sprint Review, e lasciato poi a disposizione dell’utente finale per test e feedback successivi, se non si decide di andare subito in produzione.

In particolare, è possibile invitare gli utenti a verificare specifici elementi della soluzione tramite una richiesta esplicita di feedback.

vsts feedback 1 vsts feedback 2

Feedback request

Inviata la richiesta, l’utente riceve una mail con tutte le istruzioni per avviare (o installare se non presente) Microsoft Feedback client che permette di seguire le diverse fasi di verifica fino all’invio delle osservazioni in merito.

vsts feedback 4

Feedback

Successivamente, i feedback ricevuti possono essere visualizzati dal team di delivery tramite una semplice query, creando anche elementi personalizzati sulla dashboard per evidenziarne aspetti particolari.

vsts feedback 5

Feedback Query

Lato Quality Assurance il processo può essere proficuamente gestito attraverso appositi Test Plan, andando a definire passo passo tutte le verifiche da effettuare e raccogliendo strutturalmente i risultati.

vsts test plan

Test Plans

vsts test plan execution

 Esecuzione di un Test Plan

Se l’environment di riferimento è quello dedicato ai test di carico, ovvero alla verifica dell’affidabilità dei servizi in condizioni di carico specifico o particolare, il test stesso potrà essere configurato sfruttando gli appositi task che consentono di gestire questa tipologia di validazioni e catturarne l’esito.

vsts web test

Quick Web Performance Test LoadTest

Si tratta di un’azione molto simile a quanto realizzato con i progetti Web Performance and Load Test di Visual Studio IDE, andando però a sfruttare le risorse Cloud per simulare in modo più realistico un utilizzo intensivo dei servizi.

Release si presta a numerose personalizzazioni ed estensioni, tra cui Octopus Deploy e, il già discusso, LaunchDarkly [rollout]. Octopus Deploy è una piattaforma di Continuous Delivery/Deployment che si integra con VSTS in modo da diventare “un’appendice” dell’azione di Continuous Integration e sostituire la parte proprietaria di Release. Octopus si è ritagliato un’interessante spazio nel mondo DevOps Microsoft-related, anche se l’integrazione diretta di Release in VSTS/TFS (precedentemente Release Management era un tool a parte) ha reso disponibili nativamente molte delle sue caratteristiche.

Tornando invece a LaunchDarkly, i relativi task di rollout (da collegare alla definizione degli step di delivery sui vari ambienti) consentono di gestire proprio l’azione di rollout, ovvero bilanciare il numero di utenti che avranno accesso alle nuove funzionalità.

extension launch darkly 2

LaunchDarkly rollout work item

extension launch darkly 3 rollout

LaunchDarkly rollout release task

La build, una volta validata ed avviato il processo di rollout, verrà dispiegata in produzione e, da quel momento in poi, sarà necessario attivare una serie di servizi e strumenti di supporto e monitoraggio applicativo.

Questo sarà l’argomento del prossimo post in cui approfondiremo l’area di Monitor and Learn e vedremo come essa produca un output che, a sua volta, diventa uno degli elementi di input per la nuova fase di Planning.

 

Post precedenti della serie:

DevOps e l’ecosistema Microsoft, parte 3: Develop and Test

La nuova iterazione di sviluppo segue il già citato Iteration Planning in cui sono state individuate le Storie da realizzare in funzione degli obiettivi da raggiungere. Se lavorate in chiave Kanban/Lean potreste non avere un concetto esplicito di “Iterazione”, ma comunque avrete dei momenti in cui considerate l’Increment attuale “ready to…” e passerete ad identificare un goal successivo scegliendo le Storie annesse.

Quando parliamo di sviluppo intendiamo sia la scrittura del codice sia i relativi test di unità annessi: nel mondo DevOps/Agile nessuna Feature/Storia può essere ritenuta completata se non adeguatamente corredata dei relativi Unit Test.

ms devops 2

Develop and Test

Lo strumento centrale di VSTS per seguire le attività di sviluppo è l’Iteration Backlog, annesso alle iterazioni definite in modo esplicito attraverso le relative impostazioni:

vsts iterations

 Iterazioni

Una volta settate le iterazioni di riferimento, si procede con l’assegnazione specifica dei work item da realizzare, andando contestualmente a identificare i task di lavoro specifici. Il consiglio è di farlo solo per l’iterazione in partenza, e al massimo la successiva, in modo da evitare di spendere tempo su cose che potrebbero essere successivamente profondamente riviste.

vsts board sprint

Sprint Board

Se durante la pianificazione dell’iterazione si utilizza un approccio basato sulle stime in Story Point e si tiene d’occhio la Velocity, è possibile sfruttare l’estensione Easy Estimation che consente di eseguire il Planning Poker direttamente online in VSTS.

extention easy estimation

Easy Estimations

L’andamento delle attività di sviluppo può essere monitorato grazie al Cumulative Flow Diagram (qui un precedente approfondimento a tema), alla Velocity e all’Iteration/Sprint Burndown. Si tratta di strumenti molto utili che devono, però, essere utilizzati in un’ottica di Continuous Improvement e non di controllo delle attività da parte del management.

vsts diagram cfd

Cumulative Flow Diagram (CFD)

vsts diagram burndown

Iteration/Sprint Burndown

vsts diagram velocity

Velocity diagram

Analogamente, gli strumenti di Forecasting (previsione) e di Capacity (allocazione del team), possono essere utili per i team Agili alle prime armi, ma già dopo 4-5 iterazioni hanno una utilità meno incidente nel processo di miglioramento ai diversi livelli operativi.

Va detto che in perfetta sintonia con il secondo valore del Manifesto Agile (SOFTWARE FUNZIONANTE più che la documentazione esaustiva), lo scopo primario di questa fase è quella di scrivere software funzionante e diversi sono gli strumenti MS che agevolano tale attività: Visual Studio IDE, il Version Control System, il Sistema di Building e di Continuous Integration di VSTS. Tutti rappresentano un insieme di soluzioni estraneamente efficaci che aiutano gli sviluppatori, e non solo, a raggiungere proficuamente i propri obiettivi.

Come già ribadito, il codice deve sempre essere corredato dai relativi Unit Test automatizzati, e l’utilizzo di MSTest, o di una delle implementazioni di xUnit, consente di assolvere egregiamente a questo compito, andando a creare per ogni progetto della nostra solution un progetto parallelo di testing che ne raccoglie la relativa batteria di test automatizzati.

vs unit testing

Unit Testing Project

Dopo la sua elaborazione, tutto quanto afferisce alla soluzione viene salvato nel Version Control System di riferimento, Team Foundation Version Control (TFVC) o Git, entrambi gestiti in modo nativo da VSTS ed integrati nella console di gestione dell’IDE. L’evidenza delle motivazioni che portano a scegliere l’uno o l’altro esula dallo scopo di questo approfondimento, anche se è importante evidenziare che, nelle soluzioni enterprise, Git è diventato uno standard de facto. Questo perché consente di lavorare in modo più flessibile in un ambiente organizzativo ampio e distribuito, favorendo diverse politiche di branching. La scelta di Git abilita, inoltre, alla possibilità di utilizzare le Pull Request, un importante strumento di code review che può essere sfruttato per chiedere un parere sul codice scritto, ricevendo suggerimenti in merito e discutendo delle ultime modifiche apportate. Se alla fine della review la pull request viene accettata, il codice viene unito (merge) al resto della base line. Per completezza bisogna evidenziare che una funzionalità similare, chiamata Code Review, è disponibile anche per chi utilizza TFVC.

vsts pull request

Pull Request

Nel caso quanto realizzato sia affetto da anomalie, o si riscontrino difficoltà operative, si può ricorrere ai work item di tipo Bug ed Incident per tracciarne la presenza (di cui si è parlato nel post precedente). Da un punto di vista operativo, per migliorare la qualità del codice, oltre a sfruttare le Pull Request/Code Review, è possibile utilizzare una serie di strumenti specifici messi a disposizione dall’IDE Visual Studio: Code Analysis, che consente di validare il codice in funzione di un set di regole personalizzabili, Code Metrics, che fornisce tutta una serie di metriche di valutazione (linee di codice, complessità ciclomatica, accoppiamento e la profondità dell’ereditarietà) e Clone Code Analysis, per cercare codice clonato e/o ripetuto.

Quando il codice e i test hanno raggiunto il “done state” e il tutto è salvato nel VCS di riferimento del progetto, si passa alla Gestione delle Build e all’azione di Continuous Integration. Entrambe sono gestiste in modo estremamente lineare da VSTS, a partire dalla build definition che permette di definire tutti i passi specifici nei minimi dettagli, consentendo, anche, di creare azioni personalizzate in funzione delle proprie esigenze.

vsts build definition

Build Definition

L’azione di Continuous Integration viene attivata abilitando il relativo trigger che scatena una nuova build ad ogni commit. Va specificato che esistono comunque anche “soluzioni aggreganti” per evitare di sovraccaricare inutilmente gli agent relativi.

vsts ci

Continuous Integration

La presenza di validi test, come più volte ribadito essenziali per attuare concretamente l’azione di Continuous Integration, consente di evidenziare velocemente i problemi sugli ambienti di riferimento e non solo sulle workstation dei dev (“ma sulla mia macchina funzionava”), intervenendo rapidamente in caso di problemi. Ciò evita che questi ultimi si sommino tra loro, rendendo difficile individuarne la fonte e risolverli, e portando ad un aumento del Debito Tecnico.

ms devops 2b

Full Continuous Integration actions

La qualità di quanto realizzato può essere ulteriormente analizzata sfruttando l’integrazione (a livello di Build/CI) con SonarQube, che estende le funzionalità di verifica all’intero codice facente parte della build. Si tratta di uno strumento molto potente, che si integra con VSTS in modo diretto e consente di scandagliare tutto il codice alla ricerca di problemi e percorsi critici noti.

extension sonarqube build integration

SonarQube Build Tasks

Da evidenziare che i task di integrazione fanno parte del nuovo modello di estensione gestito direttamente da Sonar e che i precedenti in-bundle, realizzati da Microsoft, sono ora marchiati come deprecati e verranno rimossi nei prossimi aggiornamenti.

Sempre in ambito testing, ma di tipo A/B o Canary, è interessante segnalare LaunchDarkly che consente di abilitare e disabilitare specifiche funzionalità direttamente da una console di controllo. L’obiettivo primario può essere di due tipi: testare le nuove Feature da un punto di vista funzionale, ossia verificare che facciano quanto previsto, e validarne l’effettiva utilità (in chiave Lean Startup). In pratica, se si considerano due popolazioni (insieme di utenti) diverse, A e B, che utilizzano il servizio, e quella A, alla quale sono state attivate le nuove Feature, non mostra alcun interesse in esse, probabilmente le stesse non sono particolarmente utili.

others ab testing

A/B Testing

L’utilizzo di LaunchDarkly prevede di inserire all’interno del proprio codice poche istruzioni (vi consiglio caldamente di utilizzare un design basato su Dependency Injection) che poi consentiranno di controllare l’attivazione/disattivazione delle funzionalità da un comodo pannello di controllo web-based.

extension launch darkly 1

LaunchDarkly Dashboard

L’azione di Build può concludersi con la creazione di un Container, e in VSTS non poteva mancare il supporto nativo a Docker, o anche con la pacchettizzare della soluzione per poter essere gestita con i più comuni package manager, NuGet in primis.

Chiudiamo la trattazione dell’area Develop and Test facendo un rapido richiamo a due applicativi dell’ecosistema Office 365 particolarmente interessanti. Il primo è Planner, che consente di gestire le attività ad un livello di pianificazione generale, sempre in chiave Kanban/Visual Management.

office planner

Office 365 Planner

Il secondo è Teams, integrabile con VSTS, che consente di comunicare in modo meno formale e più efficace con i membri del team di progetto. In Teams è possibile utilizzare dei Bot che consentono di analizzare le informazioni e offrire suggerimenti, oltre a creare implicitamente una knowledge-base basata sulle discussioni.

office teams

 Office 365 Teams

 

Post precedenti della serie:

DevOps e l’ecosistema Microsoft, parte 2: Agile Planning

Continuiamo il nostro viaggio alla scoperta di DevOps attraverso l’ecosistema Microsoft (qui la prima parte).

ms devops 1

Ogni nuova idea, prima di poter diventare un prodotto ed avere allocate le risorse per realizzarlo, deve necessariamente passare per la relativa validazione di sostenibilità (spesso indicata come Inception) analizzandone i contorni, valutandone i rischi e le relative opportunità di mercato.

In generale, per la prima fase di approfondimento si preferisce usare i cosiddetti Canvas, ovvero una serie di panel che permettono di esplicitare i diversi elementi strategici che andranno a caratterizzare l’azione di mercato del nuovo prodotto, oltre alle caratteristiche del prodotto stesso.

canvas

Canvas

I Canvas più noti sono: Vision Board Canvas, Business Model Canvas/Lean Canvas e Product Canvas che, nell’ordine esplicitato, vanno dalla visione annessa al nostro prodotto fino a quello che è una sorta di primo draft con i diversi elementi specifici.

Allo stato attuale, VSTS non offre un supporto diretto ai Canvas, per cui può essere utile sfruttare servizi terzi come Canvanizer per rappresentarli in modo digitale e collegarli tramite link a specifiche Epic del prodotto.

canvas canvanizer

 Canvanizer

Resta, chiaramente, sempre valida l’opzione di usare dei panel materiali (stampe) dei Canvas, fotografarli e gestirli tramite il repository documentale associato al prodotto, ad esempio SharePoint. In particolare, tramite il Product Canvas si vanno ad esplicitare diversi elementi di liftoff gestiti direttamente da VSTS:

  • Name, il nome del prodotto;
  • Goal, gli obiettivi;
  • Metrics, il modo in cui il raggiungimento dei goal viene misurato;
  • Target Group, le Personas che lo utilizzeranno;
  • Big Picture, gli elementi fondamentali che descrivono il prodotto: Scenari, Mock-up, StoryBoard, ecc.;
  • Product Details, gli item da realizzare: epic, feature, user story (anche se più di rado).

canvas product

The Product Canvas

Come accennato, tali elementi sono effettivamente “mappati” e rappresentati direttamente in VSTS:

  • Name, è il nome stesso del Team Project;
  • Goal, è possibile utilizzare delle estensioni del Marketplace come “Product Vision” per esplicitarli nella Dashboard;
  • Metrics, utilizzando l’estensione di “Application Insight” si può visualizzare una tile con le informazioni rilevanti direttamente nella dashboard;
  • Target Group, è possibile sfruttare l’estensione del marketplace “Personas”.

Big Picture e Product Details necessitano di un maggiore approfondimento.

Partiamo da Big Picture. Qui si sfruttano strumenti come le StoryBoard di PowerPoint per produrre i mock-up del prodotto, consentendo al potenziale utente (Personas) di navigare le diverse schermante e fornire feedback agli sviluppatori in modo che possano essere allineati con le sue aspettative.

Una volta realizzato il mock-up, si potrà collegarlo direttamente ad un Product Backlog Item (PBI) e gestirlo come elemento di dettaglio della relativa realizzazione direttamente da VSTS.

office powerpoint storyboard

Story Board con Power Point

La sezione del Canvas “Product Details” si trasforma negli elementi di Planning tipici del mondo Agile, vale a dire Epic/Feature/User Story, che VSTS utilizza in modo intensivo per consentire di coordinare le attività di realizzazione del prodotto.

vsts agile items

VSTS Agile Items

I diversi item possono essere personalizzati ed estesi, e ne possono esserne creati di nuovi per adattare al meglio VSTS alle proprie esigenze. In generale, il consiglio è sempre quello di cercare di sfruttare al massimo quanto offerto di default con lo specifico process template e solo se veramente indispensabile effettuare specifiche personalizzazioni. Ciò riduce il rischio che futuri aggiornamenti possano invalidare quanto personalizzato o non funzionare correttamente.

A livello management gli item afferenti al IT Portfolio Management, ovvero le Epic e le Feature, vanno a definire le iniziative annesse al singolo prodotto e sono gestiti principalmente attraverso specifiche Kanban Board.

vsts board epic

Epic Kanban Board

 

vsts board feature

Feature Kanban Board

Le Kanban possono essere completamente personalizzate, consentendo di aggiungere, ad esempio, la specifica Definition of Done per singola colonna e il relativo Work in Progress Limit.

vsts board kanban personalize

 Personalizzazione della Kanban Board

Sia le Epic che le Feature dispongono di specifici dettagli che consentono di caratterizzarli in funzione sia degli obiettivi di Business che delle esigenze tecnico/tecnologiche. Non andremo ad analizzare i dettagli nello specifico perché ciò richiederebbe una trattazione specifica che esula dallo scopo dell’approfondimento in corso. Inoltre, molte informazioni a riguardo, sono presenti nell’ottima documentazione ufficiale a riguardo [Backlog and Work Items].

vsts epic details

Epic Details

Fondamentale, invece, è sottolineare come VSTS (in chiave Agile) sposi l’organizzazione a Feature Teams, dove i membri del team stesso possono organizzare e gestire il proprio (Team) Backlog, composto primariamente da Story, Task e Bug.

vsts board team

Team Backlog

Anche in questo caso la gestione tramite Kanban consente di sfruttare al meglio la logica di Visual Management e avere sempre una fotografia aggiornata dello stato di avanzamento delle attività.

Per chi preferisce utilizzare una Kanban/Scrum Board “fisica” e vuole evitare di dover lavorare su entrambe, aggiornandole di conseguenza, può sfruttare una utile estensione del marketplace chiamata Agile Cards.

extension agilecard

Agile Cards

Una volta definiti i Product Backlog Item (PBI) è possibile stampare le relative card, utilizzarle su una Kanban/Scrum Board “fisica”, fotografarne i cambiamenti e lasciare che VSTS si aggiorni di conseguenza! La “magia” avviene tramite una serie di “tag” posti su ogni singola card.

Nel caso il prodotto contempli più progetti e, quindi, più team specifici, il relativo lavoro può essere organizzato in modo che gli stessi abbiano in comune il Product Backlog ma al contempo lavorino su specifici Team Backlog correlati ad esso. Qui si entra nel campo dell’Agile Scaling dove troviamo framework metodologici come: Scaled Agile Framework (SAFe), Disciplined Agile 2 (DA 2) e LeSS.

others multi team

Agile Scaling

Per adattare VSYS a questo scenario, è necessario creare più Feature Team ed associare ad ognuno di essi specifiche Work Area (derivate da quella base del progetto). In tal modo gli item identificati durante planning, in funzione a specifici goal, potranno essere associati ai diversi team coinvolti in modo esclusivo.

vsts feature team

Multi Feature Team

Le attività di sviluppo dei diversi team afferenti allo stesso prodotto possono essere visualizzate e ottimizzate tramite l’estensione Delivery Plans, consentendo di avere un quadro a livello Program, così come inteso dal framework Scaled Agile Framework.

extension plans

Delivery Plans

All’interno dei Project Template Agili (ovvero dei modelli di processo predefiniti, uno generico per Agile e uno più specifico di Scrum) oltre agli item di sviluppo evolutivo visti fin ora, sono presenti anche il già citato Bug e l’item di Impediment, che rappresenta un problema bloccante e come tale, ovviamente, non viene riportato nel Product Backlog non essendo un elemento di pianificazione. Entrambi sono estremamente importanti per consentire al team di attivare azioni di miglioramento, potendo, ad esempio, misurare il numero di problemi in ogni increment o i diversi impedimenti che si riscontrano durante le attività giornaliere. In particolare, è utile applicare la regola dell’80/20 (validata in modo empirico) che spinge il team a dedicare il 20% del proprio tempo a ottimizzare quanto realizzato, riducendo costantemente il Debito Tecnico.

Prima di chiudere la trattazione dell’area Agile Planning, è utile evidenziare che la pianificazione avviene al livello minimo indispensabile per dare il là alle prossime attività di sviluppo, in perfetto stile Agile/Lean. Questo perché la stessa viene rivista, approfondita ed estesa ad ogni iterazione o al raggiungimento dei goal specificamente settati per le attività in corso.

 

Nel prossimo appuntamento ci concentreremo sull’area Develop & Test, andando a vedere come VSTS e VS IDE supportano egregiamente le attività operative di realizzazione concreta della soluzione.

 

Stay tuned :-)