Introduzione

Nel precedente appuntamento dedicato a Disciplined Agile 2 abbiamo descritto i quattro approcci al delivery contemplati dal framework [1]. In questo nuovo appuntamento andremo a completare la trattazione degli elementi cardine di Disciplined DevOps, concentrandoci sui cinque process blade di riferimento:

• Program Management
• Release Management
• Operations
• Support
• Data Management

Program Management, the whole system and not the singularity

La governance dei prodotti è un elemento essenziale, soprattutto nelle medie e grosse realtà in cui le strategie di business danno vita ad una serie di azioni (Program) da dover poi declinare e armonizzare in funzione delle reali capacità di assolvimento dell’azienda.

“It’s the Whole System, not the singularity” potremmo esprime così la “regola del 95/5” di Deming che enfatizza l’importanza del sistema aziendale — formale e, soprattutto, informale — rispetto al singolo, e che ritroviamo nella First Way di DevOps, ossia System Thinking [2].

Program Coordinator

DA2 contempla, nell’area di Delivery, la specifica funzione di Program Management, meglio assimilabile come Program Coordinator anche se quest’ultima denominazione è meno comune e potrebbe portare a dover attuare una transizione semantica che è meglio ottenere progressivamente con l’adozione diretta.

Lo scopo di questo blade è quello di coordinare le attività di più team impegnati su uno stesso prodotto, coinvolgendo anche aspetti trasversali non strettamente tecnico-tecnologici (sales, market, financial, customer care e così via). Si va così a mitigare il rischio che la crescita spinga a una burocratizzazione dei processi e alla creazione di macro-team che diventano incapaci di auto-organizzarsi e di adottare un approccio di Continuous Improvement.

Strategie per il dimensionamento dei team

Il blade di Program Management sfrutta una serie di strategie per far sì che al crescere della complessità della soluzione, i team possano rimanere di dimensioni ottimali:

• Reorganize the problem into a collection of smaller problems. I team possono concentrarsi su specifici boundary all’interno del contesto complessivo sotto la governance del PgMO ( è il Program Management Office, da non confondere con PMO che è Project Management Office).
• Reduce the problem. Se i problemi non sono riferiti a quadro d’insieme ma a specifici Goal/Feature, è possibile gestirli in modo più efficace, eventualmente rivedendo le priorità o rimuovendone gli elementi costituenti.
• Address your organization’s culture. Non basta “fare Agile” ma bisogna “essere Agile”, il che significa realizzare un profondo cambiamento culturale e… gestirlo!
• Organize the large team into a collection of smaller teams. Come evidenziato, meglio piccoli team dinamici e collaborativi che un unico grande team burocratizzato.

Il Program Management Office (PgMO)

Ma come costituiamo il nostro Program Management Office? Come sempre nessuna soluzione è universalmente corretta, anche se un valido approccio è quello di creare un board composto dai singoli Product Owner responsabili dei sotto-prodotti — indicando con sotto-prodotti la suddivisione Goal-Driven del sistema complessivo — che, più o meno democraticamentel, eleggono il “chief”, anche a rotazione.

Si tratta di una scelta tutto sommato “naturale”: essendo il PgMO un gruppo di coordinamento e allineamento, chi meglio dei singoli Product Owner può renderlo efficace? Essi infatti hanno, per ognuno dei propri team, la rispettiva visione d’insieme di quanto realizzato, e sanno dove occorre spingersi.

Questo vale anche anche in relazione alle principali attività di cui il PgMO si occupa:

• Allocate work
• Prioritize work
• Organize teams
• Coordinate teams
• Coordinate Schedules
• Scheduling solution releases
• Negotiate functional dependencies
• Negotiate technical dependencies
• Govern the program

Quindi il PgMO diviene il nodo centrale di una fitta rete di relazioni tra le diverse funzioni aziendali, definito da DA2 come Program Mangement External Workflow, con “external” a indicare la non diretta appartenenza all’ambito IT.

Resta un ultimo ma delicatissimo punto da evidenziare, ossia quello relativo all’assegnazione dei bonus e dei premi aziendali. Nell’approccio tradizionale, le aziende sono portate a riconoscere un bonus maggiore ai manager che gestiscono team grandi e un numero maggiore di persone. Risulta quindi evidente che, per spingere un Program Manager Officer (PO o altra figura che sia) a non legare le proprie azioni ai desideri estrinsechi [3], bisogna rivedere questa politica seguendo una logica “Achieved Goal based” o “Aware Contribution”.

Release Management: il graduale assorbimento da parte del team

Il processo di Release Management (RM) è estremamente delicato perché orientato a “consegnare” al cliente quanto realizzato in modo da soddisfare le sue necessità e creare un valore reciproco. Le diverse metodologie Operational-oriented contemplano direttamente diverse declinazioni del Release Management — si pensi ad ITIL — mettendolo spesso al centro delle proprie azioni, e DA2 non è da meno, prevedendolo in modo esplicito anche se border-line rispetto all’approccio più olistico di Disciplined DevOps.

Questa scelta diventa estremamente chiara se ci si ricollega alle strategie di adozione [1] di DevOps all’interno della propria organizzazione, rispondendo anche all’implicita domanda: “ma a cosa serve un’azione di RM se faccio DevOps?”.

Release Management e strategie di deployment

Come abbiamo più volte avuto modo di sottolineare, la cultura DevOps va costruita progressivamente e contestualizzata, richiedendo, tipicamente, strumenti che consentano di gestire il cambiamento senza incidere sui SLA (Service Level Agreement) offerti ai propri clienti. In particolare, un’azione di RM, affidata a uno specifico team di riferimento, consente di supportare il deployment attraverso una serie di strategie specifiche in riferimento al contesto operativo:

• Complex operational infrastructure. Quando la propria catena di deployment è particolarmente complessa e laboriosa — si pensi alla presenza di diversi stack tecnologici o a configurazioni d’ambiente particolarmente fantasiose — il rischio che qualcosa non vada a buon fine è estremamente alto, rendendo indispensabile una corretta programmazione delle fasi di release.
• Many delivery teams working in parallel. Quando la soluzione è composta da più progetti, ognuno affidato a team diversi, ogni specifica azione di team-deployment va correlata agli artefatti complessivi, valutando gli impatti contingenti. Chiaramente, maggiore è il numero di team coinvolti, maggiore è il rischio che qualcosa possa andare male.
• IT delivery teams needs help. Questa condizione si verifica spesso quando il team di delivery è poco esperto, o di nuova formazione, e necessita di essere supportato nella comprensione e nell’attuazione della catena di deployment. In questo caso, il Release Management team si comporta da coach trasferendo know-how e collaborando per rivedere il processo anche in funzione delle specialità delle nuove risorse.

Se si esclude l’ultimo punto, legato più a un fattore di crescita di team che al contesto operativo, gli altri due punti sussistono anche se l’IT adotta un approccio full DevOps. La complessità può essere ridotta investendo nel “pagamento” del relativo debito tecnico, mentre la gestione multi-team è difficilmente abbattibile se la soluzione è estremamente articolata e complessa.

In generale la funzione di Release Management in un contesto DevOps viene progressivamente assorbita dal team stesso, ma è estremamente utile avere un supervisor di coordinamento per le situazioni multi-team, in modo da evitare spiacevoli problemi e frequenti condizioni indesiderate.

Data Management e IT intelligence

L’azione di Delivery enfatizza quasi sempre un’attenzione primaria sul codice (build), relegando gli aspetti afferenti al mondo dei dati in posizione secondaria, quasi accessoria.

Eppure la gestione e la persistenza dei dati sono fondamentali, in quanto aspetti che appartengono alla sfera dell’Enterprise Architecture, ossia dell’architettura informativa a supporto del business. Il motivo è presto detto: un accesso efficiente ed efficace ai dati, in funzione delle diverse aree e dei diversi servizi in esercizio, consente di avere prontezza della validità delle diverse assunzioni strategiche effettuate, sia di business che organizzative.

Le strategie del Data Management

DA2 evidenzia tutto ciò in modo esplicito, prevedendo il process blade di Data Management e specializzandolo su tre strategie primarie.

• Data and information guidelines. Si tratta di avere una serie di linee guida da seguire nella creazione, nell’accesso e nella gestione dei differenti dataset. Tutto ciò va automatizzato il più possibile in modo da ridurre inefficienze e problemi. Si pensi, solo per citare un esempio classico, alle policy di backup.
• Quality data source. La continua richiesta di cambiamento nei sistemi, dettati dalle nuove esigenze dei clienti e del mercato, si riflette in modo diretto anche sulla strutturazione dei dati e dei relativi repository. Per poter supportare il tutto in modo efficace, è necessario che i dataset possano essere aggiornati e fatti evolvere facilmente, reprimendo la tentazione di creare continui workaround per supportare le nuove richieste: queste “pezze”, questi “stratagemmi” portano rapidamente a un aumento esponenziale del debito tecnico, rendendo la soluzione ingestibile nel medio-lungo periodo.
• IT intelligence. Dati di qualità consentono di poter effettuare tutta una serie di analisi trasversali, spesso grazie al supporto di strumenti di Business Intelligence che permettono di analizzare l’andamento del proprio business. Ma l’IT intelligence sposta questo focus sull’analisi di quello che è il miglioramento della propria divisione IT, mettendo a fattor comune i dati derivanti dai tool per la gestione integrata di una valida e robusta azione ALM (Application Lifecycle Management).

Risulta estremamente evidente, quindi, come i dati rappresentino una variabile fondamentale nel nostro processo DevOps, consentendo di creare opportune metriche di valutazione. Si pensi, solo per fare un esempio estremamente semplice, alla possibilità di visualizzare il numero di build di successo in relazione alla crescente confidenza del team con l’Agile. Con dati alla mano, il team può adottare opportune azioni migliorative laddove si dovessero verificare problemi di qualità.

Solution Support, a customer oriented activity

Una volta dispiegata, la soluzione è pronta per essere utilizzata dal cliente. Ma lo stesso deve poterla “digerire” ed è altamente probabile che richiederà un supporto diretto, sia funzionale sia per la risoluzione delle eventuali anomalia riscontrate. DA2 esplicita questo aspetto grazie all’omonima azione, incentrata su una serie di strategie specifiche.

• Online information. Si tratta di impostare le opportune risorse online che consentono di evitare il noioso e costoso TAGRI (They Ain’t Gonna Read It), ossia il dover ripetere più e più volte le stesse cose. FAQ, manuali online, video training sono alcuni esempi di risorse che rientrano in questo ambito.
• Online discussion forums. Viene istituito un forum ufficiale in cui discutere delle problematiche che poi è tipicamente supportato e moderato dai dev stessi e dai “power user” afferenti alle diverse aree. Attenzione a tenere sotto controllo il forum e all’impegno indiretto/atteso di risolvere prontamente i problemi segnalati.
• Asynchronous support. Classico supporto su richiesta tramite email o l’utilizzo di una pagina sul sito web ufficiale. Normalmente la richiesta viene presa in carico da un sistema di ticketing ed elaborata anche in relazione agli eventuali SLA garantiti al cliente.
• Synchronous support. Si tratta del supporto in tempo reale operato tramite telefono, sistemi di messaggistica istantanea o videochiamata. Il vantaggio è che l’utente viene supportato immediatamente, anche se i costi per l’azienda sono rilevanti e il risultato non è sempre dei migliori, soprattutto se il servizio viene appaltato in outsourcing.
• Support alerts. Si tratta di un servizio legato all’eventuale processo di self-recovering grazie al quale il sistema è in grado di auto-rilevare eventuali problemi, evidenziarli all’utente e lasciargli la possibilità di entrare in contatto con il supporto dedicato.
• Developer-led support. Il supporto viene effettuato direttamente dal team di DevOps responsabile dell’applicazione.

Ambiente per la risoluzione dei problemi

L’attuazione delle diverse strategie richiede che sia disponibile un ambiente in cui riprodurre le problematiche evidenziate e sperimentare le possibili soluzioni. In quest’ottica è possibile utilizzare diversi approcci.

• Production. Se non sussistono problematiche di sicurezza o di altro tipo che impediscono di effettuare le prove direttamente sugli ambienti di erogazione, si possono anche usare proprio questi per lo scopo. Tale opzione consente di operare sullo stesso sistema utilizzato dall’utente finale.
• Pre-production test sand-box. Il team di supporto può sfruttare l’ambiente di pre-produzione per le proprie attività. Se da un lato questo mette al riparo da eventuali rischi per l’ambiente di produzione, dall’altro si basa comunque su un ambiente diverso che potrebbe anche non essere allineato.
• Support sandbox. È possibile infine creare un ambiente apposito per eseguire quanto necessario a supporto delle differenti azioni di help-desk. I problemi sono, chiaramente, gli stessi del caso si pre-produzione, cui si aggiunge il costo — in termini di infrastruttura e di tempo — di dover gestire un ambiente ad-hoc.

Lean IT Operation Mindset

Le azioni di Operation sono fondamentali per garantire una continuità dei servizi e quindi supportare adeguatamente le necessità di affidabilità e cambiamento che ogni moderna organizzazione deve poter soddisfare.

DA2 descrive un “mindset”, una mentalità di riferimento da poter adottare per supportare tale obiettivo.

• Run a trustworthy IT ecosystem. Si tratta della strategia fondamentale che, al livello minimo di adozione, si traduce in “keep the lights on”, ossia nel garantire che il servizio sia fruibile. Passo immediatamente successivo è quello di garantire che il servizio risponda agli opportuni SLA in termini di sicurezza, affidabilità, performance, usabilità e accessibilità.
• Focus on the strategic (long-term) over the tactical (short-term). Chiunque sia coinvolto negli aspetti IT, non solo operational, deve sempre bilanciare le esigenze/opportunità a breve termine con quelle a lungo termine. In tal modo si abbattono i rischi di trasformare un’innovazione tecnologica in un incubo da un punto di vista della sostenibilità generale. Per mitigare ciò, le diverse scelte impattanti devono avvenire in relazione all’Enterprise Architecture e devono essere condivise con gli obiettivi di business perseguiti dal Program Management.
• Streamline the overall flow of work. Ragionare in termini di “flusso di lavoro” è alla base di una moderna azione del deployment in chiave DevOps, quindi non soltanto una responsabilità di Operations, ma di tutti coloro che sono coinvolti nel processo. In particolare, comunque, il compito di Operations è quello di supportare adeguatamente contesti di continuous delivery, riducendo il value canyon e scrollandosi di dosso l’aura di “collo di bottiglia”, derivante dalla necessità di rispettare procedure rigide per garantire l’affidabilità degli ambienti.
• Help end-users succeed. Non importa quanto la soluzione sia scritta bene: se l’utente non riesce a utilizzarla adeguatamente… risulterà comunque deficitaria. Questo è il motivo per cui Operations, in congiunzione con Support ed eventuali altre figure necessarie, deve essere preparato a rispondere prontamente alle richieste di supporto del cliente;
• Standardization without stagnation. La giusta tendenza a standardizzare i processi annessi alle proprie attività IT — che è alla base della riduzione degli errori e dell’eliminazione degli sprechi — non deve minare la capacità di essere innovatori e di far evolvere il tutto per supportare le nuove opportunità in carico al Program Management e adeguatamente accolte dall’Enterprise Architecture.
• Regulate releases into production. Le attività di Operations devono rispecchiare le esigenze delle diverse soluzioni in esercizio, e dei diversi team per ognuna di esse. È fondamentale quindi chiedersi qual è il WIP limit complessivo (Work In Progress), ossia quello relativo alle richieste di tutto l’ecosistema da gestire, senza cadere nella tentazione di focalizzarsi sulla presunta “soluzione/team più importate”. In quest’ottica è d’aiuto capire quali azioni sono supportate dall’attuale infrastruttura e quale strategia di Release Management sia più opportuno adottare.
• Sufficient documentation. Per quanto la si voglia ridurre ai minimi termini, il proprio ecosistema IT è sempre descritto da una specifica documentazione, che include, generalmente, una overview della propria infrastruttura, dei processi di release e degli aspetti critici più rilevanti. Anche nel caso in cui si raggiunga una totale automatizzazione del delivery, la documentazione può avere la sua rilevanza: si pensi alla certificazione di qualità. È opportuno gestirla in un sistema di Configuration Management control (CM).

Dovrebbe essere evidente come il Lean IT Operation Mindset coinvolga tutte le figure chiave dell’approccio disciplinato a DevOps, rappresentando una sorta di sigillo di garanzia alla corretta operatività delle soluzioni realizzate e quindi uno strumento fondamentale di Customer Satisfaction.

Conclusioni

Terminiamo così l’approfondimento dedicato all’area Disciplined DevOps, cuore pulsante di DA2 e centro nevralgico delle azioni di delivery delle diverse soluzioni strategiche che caratterizzano le attività aziendali.

Nel prossimo appuntamento, andremo ad esplorare l’area Disciplined Growth e le relative funzioni a supporto della creazione di una cultura in linea con gli aspetti portanti di Management 3.0 [3].

Come sempre vi invito a contattarmi per feedback, chiarimenti e approfondimenti.