In che modo i team condividono i ruoli e le responsabilità della gestione delle modifiche

Responsabile/coordinatore delle modifiche

I responsabili delle modifiche, a volte noti anche come coordinatori delle modifiche, hanno in genere il compito di gestire tutti gli aspetti delle modifiche IT. Assegnano priorità alle richieste di modifica, ne valutano l'impatto e accettano o rifiutano le modifiche. Documentano anche i processi di gestione delle modifiche e i piani delle modifiche. Soprattutto, si preparano per le riunioni CAB, che organizzano e presiedono. Il successo di un responsabile delle modifiche viene in genere valutato in base al rispetto degli obiettivi di tempistica e budget.

Autorità/approvatori delle modifiche

Un'autorità di modifica è una persona che decide se autorizzare o meno una modifica. A volte si tratta di una sola persona, ad esempio un responsabile o un dirigente. A volte è un gruppo di persone in un CAB (Change Advisory Board) o un responsabile di peer review. Secondo ITIL 4, "Nelle organizzazioni high velocity è prassi comune decentralizzare l'approvazione delle modifiche, facendo della peer review un importante fattore predittivo di prestazioni elevate".

I responsabili delle modifice in genere lavorano a stretto contatto con l'autorità di modifica per approvare le modifiche e farle avanzare all'interno di un'organizzazione. In alcuni casi, in particolare nelle piccole organizzazioni, il responsabile delle modifiche è l'autorità che ha il potere di prendere queste decisioni senza coinvolgere altre persone o team.

Stakeholder aziendali

Gli stakeholder aziendali sono spesso coinvolti nella gestione delle modifiche e possono essere chiamati a intervenire nel processo di autorizzazione. Ciò accade sempre più spesso, considerata l'importanza fondamentale dei servizi software per la maggior parte delle aziende.

Ad esempio, se una modifica influisce sulla connessione tra il software di monitoraggio dei pagamenti del team finanziario e il CRM del team di vendita, potrebbe essere necessario coinvolgere gli stakeholder di tali team nelle riunioni CAB e nelle decisioni finali prese in merito a una modifica.

Ingegneri/sviluppatori

I team di sviluppo in genere inviano le modifiche per l'approvazione e ne documentano la necessità. Una volta approvata una modifica, nelle aziende che hanno adottato un approccio You Build It, You Run It, questi team distribuiscono la modifica, la monitorano e spesso rispondono a qualsiasi imprevisto o problema correlato alla modifica. In altri casi, il team di gestione degli imprevisti responsabile degli eventuali imprevisti causati dalla modifica potrebbe essere diverso rispetto al team di sviluppatori che implementano la modifica.

Agenti del Service Desk

Gli agenti del service desk possono offrire una prospettiva unica e in prima linea degli imprevisti e dei ticket di assistenza più comuni che possono essere causati da una modifica.

Responsabili operativi

Dal momento che hanno il compito di mantenere l'operatività quotidiana dei sistemi, i responsabili delle operazioni hanno un ruolo nell'ambito del rischio e delle dipendenze.

Responsabile delle relazioni con i clienti

Per rappresentare la voce del cliente, i responsabili delle relazioni possono fornire conoscenze sulla mentalità, sulle loro frustrazioni e sulle esigenze in continuo cambiamento dei clienti.

Responsabili della sicurezza delle informazioni e ingegneri di rete

Gli esperti in sicurezza di rete e infrastruttura cloud forniscono informazioni importanti su minacce e vulnerabilità.

Che cos'è un CAB?

Convocando coloro che hanno le responsabilità sopra descritte, i CAB (Change Advisory Board) sono gruppi che hanno il compito di valutare i rischi di ciascuna richiesta di modifica e di approvarli (o di non approvarli). In genere, un CAB tiene riunioni regolarmente programmate per esaminare tutte le modifiche imminenti proposte e coinvolge degli esperti, in base alle esigenze, che spieghino, difendano o valutino la modifica insieme a loro. I CAB tradizionali sono noti come entità di controllo del rilascio delle modifiche.

Per questo motivo, oltre che per le noiose riunioni, i lunghi backlog di richieste di modifica e la distanza dal lavoro stesso, i CAB sono spesso visti con disprezzo. Fortunatamente, molti CAB si stanno evolvendo per consentire una migliore distribuzione Agile del software, assumendo un ruolo di consulenza più strategico. I CAB si stanno trasformando in consulenti che hanno la responsabilità di monitorare le tendenze delle modifiche, consigliare pratiche in grado di gestirle e offrire ai team strumenti migliori per fornire valore ai clienti e ridurre i rischi.

La sfida dei CAB

Gli stereotipi sulle riunioni inutili si applicano anche ai CAB. Tendiamo a criticarli perché rappresentano una perdita di tempo, non sono abbastanza produttivi, coinvolgono troppe persone a caso e ed esistono quando "sarebbe bastata un'e-mail". Ciò è dovuto in parte al modo in cui i CAB tradizionali sono stati caricati di eccessive responsabilità.

Per illustrare la sfida, ecco una metafora presa dal mondo dell'aviazione. Possiamo immaginare il CAB come una torre di controllo in un aeroporto, che ha il compito di comunicare agli aerei quando possono atterrare. Alla torre di controllo non verrebbe mai chiesto di valutare se gli aerei sono strutturalmente sicuri o se il pilota è qualificato, perché questi fattori sono già stati confermati dalla FAA e da altre organizzazioni.

Troppi CAB riuniscono una varietà di stakeholder e hanno il compito di prendere decisioni di sicurezza generali su tutti i tipi di modifiche diverse. E questo accade spesso alla fine della settimana, quando le persone, già stanche, non vedono l'ora di partire per il weekend. Il CAB, semplicemente, non ha le caratteristiche giuste per essere popolare.

Inoltre, spesso i CAB si preoccupano principalmente del rischio che le modifiche causino imprevisti. Questo è, ovviamente importante, ma bisogna anche soppesare il rischio di ritardare modifiche preziose. Muoversi troppo lentamente può danneggiare i clienti e questo, in un mondo Software as a Service estremamente competitivo, può affossare un'organizzazione.

È possibile elevare e focalizzare il ruolo del CAB. Implementando le pratiche giuste, molte modifiche potrebbero essere automatizzate. In questo modo, il CAB può diventare un consulente importante, monitorare le tendenze e collaborare con i team per individuare dei modi attraverso i quali accelerare le modifiche a vantaggio dei clienti.

Come posizionare il CAB in qualità di consulente strategico

Per riposizionare il CAB è necessario innanzitutto smentire l'idea che una gestione delle modifiche complessa produca risultati positivi. I dati dello State of DevOps Report 2019 hanno rilevato che i processi che richiedono l'approvazione di un CAB hanno avuto un impatto negativo sulle prestazioni di consegna del software e che per gli intervistati che hanno seguito questi processi la probabilità di avere prestazioni basse era di 2,6 volte maggiore. Inoltre, non c'erano prove a sostegno del fatto che un processo di approvazione formale fosse associato a tassi di fallimento delle modifiche inferiori!

Per questo motivo, i team moderni stanno adottando le seguenti misure allo scopo di migliorare i propri CAB.

Smettere di trattare le richieste di modifica seguendo un unico approccio

Ogni richiesta di modifica offre un'opportunità di monitorare e raccogliere informazioni. Possiamo conoscere le percentuali di successo, gli imprevisti correlati e i relativi fattori. Nel corso del tempo, con l'applicazione dei dati, dovrebbe essere possibile pre-approvare e automatizzare un numero sempre maggiore di modifiche. Solo le modifiche con maggiori conseguenze e più rischiose dovrebbero richiedere l'approvazione di persona.

Ridurre il divario tra gestione delle modifiche e gestione dei rilasci

Nell'approccio tradizionale, i rilasci venivano raggruppati e lanciati tutti insieme contemporaneamente. Ai CAB veniva quindi lasciato il doloroso compito di esaminare e approvare scrupolosamente pacchetti di modifiche. Questo approccio può esporre a imprevisti gravi e rendere più difficile risalire all'origine dei problemi che dovessero presentarsi. Inoltre, rallenta la velocità con cui i team possono offrire valore ai propri clienti. Ciò significa anche che i responsabili delle modifiche e dei rilasci possono dedicare meno tempo alle attività di gestione dei progetti.

Usare rilasci progressivi per i test e le iterazioni

Effettua distribuzioni progressive di tipo canary or del flag delle funzioni su un piccolo sottoinsieme di utenti per testare e dimostrare la stabilità prima della distribuzione completa. Questo limita l'ambito di un potenziale imprevisto e dimostra il successo di una distribuzione prima di eseguirne l'implementazione in tutti gli ambienti.

Utilizzare l'automazione e gli strumenti per semplificare la gestione delle modifiche

I team high-velocity stanno iniziando a ridefinire i modelli di approvazione precedenti. Invece di affrontare un lungo backlog di richieste di modifica in una riunione settimanale di persona, è possibile utilizzare la collaborazione virtuale. Può essere semplice come l'invio di un'e-mail che riporta in dettaglio le richieste di modifica in modo che possano essere esaminate prima di una riunione del CAB. In altri casi, elementi come i ticket Jira e le pagine Confluence possono offrire ai revisori delle modifiche il contesto necessario per collaborare in modo asincrono e approvare le modifiche. Utilizzando Jira Service Management, i team possono collaborare in questi modi, ma anche partecipare a una videoconferenza o creare un canale Slack dedicato. Indipendentemente dal modo in cui il tuo team preferisce rimanere in contatto, il luogo resta invariato per garantire che tutti siano sempre sulla stessa pagina.

Con gli strumenti ITSM legacy è difficile per i team di infrastruttura, operazioni e sviluppo inviare una richiesta di modifica. L'automazione e il software moderno possono ridurre l'onere di inserire manualmente le informazioni sulle modifiche. L'ultima cosa che uno sviluppatore vuole fare è compilare i ticket in un sistema pesante e separato, se quell'attività può essere monitorata automaticamente. All'interno di Jira Service Management, i team possono sfruttare l'automazione per semplificare il processo di modifica, limitare al massimo i rischi e ridurre il tempo di inattività.

Adottare un approccio "shift left" (test e convalida precoci) e ridurre la distanza tra gestione delle modifiche e professionisti

Una delle strategie più comuni che spesso sostituisce o riduce le approvazioni CAB è la peer review, che assegna la responsabilità di identificare i problemi nel codice a coloro che lo comprendono meglio. Secondo ITIL 4, "Nelle organizzazioni high velocity è pratica diffusa decentralizzare l'approvazione delle modifiche, facendo della peer review il migliore fattore predittivo di prestazioni elevate". Allo stesso modo, il report 2019 State of DevOps ha raccomandato alle "organizzazioni di adottare un approccio "shift left" (test e convalida precoci) dell'approvazione basata sulla peer review durante il processo di sviluppo".

Per mantenere la conformità alle normative, questo approccio deve essere meticolosamente documentato, ed è qui che entrano in gioco sistemi come Bitbucket, che monitorano automaticamente autori e peer review, e impediscono che le modifiche vengano pubblicate in assenza del processo richiesto.

In Atlassian, la peer review è una componente fondamentale del nostro processo di approvazione. Come spiega uno dei nostri esperti di rischi e conformità IT: "Tutto il codice Atlassian è archiviato in Bitbucket. Quando uno sviluppatore desidera apportare una modifica, controlla il codice da Bitbucket e sul proprio laptop. Quando lo controlla nuovamente nel repository di Bitbucket, invece di aggiornare il codice, il sistema è configurato per richiedere una peer review. Solo dopo che la revisione è stata completata e approvata, il codice viene reinserito nel repository. E se il codice non riceve l'approvazione? Viene inviato di nuovo allo sviluppatore originale con le note del responsabile della peer review. Lo sviluppatore corregge i problemi e lo sottopone a un'altra peer review".

Convocare esperti per mettere in campo buone pratiche

Man mano che la complessità delle organizzazioni aumenta, è sempre più cruciale facilitare il flusso di informazioni e il coordinamento tra i team. Invece di approvare singole richieste di modifica, i CAB possono spostare la loro attenzione sul miglioramento delle pratiche. In questo paradigma, possono cercare di fornire raccomandazioni per il miglioramento delle pratiche, implementare funzionalità migliori, e fornire risorse e strumenti che si traducono in un miglioramento delle prestazioni. Ciò estende l'ambito di competenza del CAB alla gestione del rischio di un'eccessiva lentezza nell'immissione di valore sul mercato.

Anche nelle organizzazioni IT più tradizionali, il CAB può diventare uno spazio in cui proporre soluzioni creative. In un caso, un'università avversa al rischio che utilizzava gli strumenti e le pratiche ITSM legacy aveva la necessità di capire come fare per informare gli studenti riguardo a un servizio importante che non era disponibile. Il CAB è diventato un forum per il brainstorming di nuove tattiche di comunicazione. È stata presa la decisione di distribuire caramelle e poster nell'ambito di una campagna che si è rivelata efficace nel ridurre il numero di richieste in arrivo riguardanti un upgrade di sistema pianificato.