Le 10 migliori best practice per la gestione delle modifiche

Quando si tratta di bilanciare rischio e velocità, nella gestione delle modifiche non esiste una soluzione universalmente valida. Ogni organizzazione ha una propria cultura, tolleranza al rischio e requisiti normativi di cui tenere conto, e dovrebbe includere queste considerazioni nelle proprie pratiche di gestione delle modifiche.

Comprendere il rischio significa in parte comprendere gli obblighi normativi e di conformità dell'azienda. Quando entra in gioco la regolamentazione, la questione non riguarda più la quantificazione del tempo di inattività che il tuo sistema può sostenere prima di esporsi al rischio di perdita di attività o quale sarà il costo delle risorse se occorre correggere un problema. Ora, è un insieme di regole non negoziabili. Avrai bisogno di determinare approvazioni. dovrai separare i compiti. Alcune normative come SOX e GDPR rendono non negoziabili alcune attività, anche se queste rallentano un po' il processo.

La buona notizia è che questa pianificazione non deve essere statica. Le aziende che scelgono un approccio conservativo con più approvazioni e flussi di lavoro rigidi possono sempre effettuare una rivalutazione nel corso del tempo, adeguando il livello di rigore nei loro processi in modo da trovare un equilibrio con il livello di rischio.

Con Jira Service Management, le approvazioni e i flussi di lavoro possono essere personalizzati in base alle caratteristiche dell'organizzazione. Rendi i processi flessibili o automatici nella misura che preferisci. Per esempio, puoi decidere di automatizzare i processi a basso rischio e proteggere i processi più complessi con le approvazioni.

Il monitoraggio delle metriche, in particolare dei collegamenti tra modifiche e imprevisti, è un elemento di base importante per migliorare le pratiche di modifica. I dati evidenzieranno le tendenze, rivelando i tipi di gestione delle modifiche, i membri del team e i servizi per i quali la probabilità di coinvolgimento in un imprevisto è minore. Queste informazioni possono aiutarti a creare una corrispondenza tra rigore e rischio per diverse richieste di modifica.

Una valutazione intelligente del rischio comporta il fatto che un maggior numero di richieste di modifica possono essere spesso declassate a flussi di lavoro di approvazione meno rigorosi. Come suggerisce il processo di gestione adattiva delle modifiche di Gartner, le organizzazioni possono adoperarsi affinché un maggior numero di modifiche normali vengano classificate come standard, pre-approvate e automatizzate.

Di seguito, abbiamo compilato alcuni passaggi pratici per rendere le modifiche standard la nuova normalità.

1. Rivedi le modifiche apportate negli ultimi mesi
   • Quali sono state le modifiche più comuni?
   • Quali sono le "modifiche standard"?
   • Quali servizi sono interessati?
   • Quali modifiche sono state implementate?
   • Qual è stato il tempo medio di implementazione di queste modifiche?
   • Quali modifiche sono state richieste dai team di sviluppo?
2. Seleziona da tre a cinque modifiche standard come candidati per l'automazione
3. Crea tipi di richieste self-service per le modifiche standard nel software di service management
   • Aggiungi testo per chiarire lo scopo e l'ambito della richiesta di modifica standard
   • Acquisisci campi importanti, ad esempio il sistema, l'applicazione o il servizio oggetto della modifica
   • Crea regole di automazione per approvare in autonomia la modifica e gli stati di transizione, e comunica gli aggiornamenti al personale
4. Prenditi del tempo per istruire e formare il personale IT e i team di sviluppo in merito a questa nuova funzionalità
5. Monitora le prestazioni nel corso dei prossimi mesi
   • Acquisisci informazioni dettagliate per migliorare le tue offerte esistenti
   • Identifica ulteriori modifiche standard da automatizzare

Dopo aver valutato le precedenti pratiche di gestione delle modifiche del tuo team e il rischio di modifiche, può essere utile compilare la documentazione relativa alla valutazione dei rischi in un unico luogo. Grazie all'integrazione Confluence di Jira Service Management, i team possono consultare un'unica fonte di riferimento in un documento relativo al piano di modifica. In questa pagina, i collaboratori possono aggiungere un modello del piano di modifica oltre alle informazioni sulla valutazione dei rischi.

A nessuno piace lavorare più del necessario. Ed è per questo che la gestione delle modifiche è spesso considerata una seccatura. Le pratiche di gestione delle modifiche richiedono alle persone di documentare qualcosa, spesso utilizzando uno strumento con cui non amano lavorare, e di attendere un processo che comporta alcuni passaggi aggiuntivi. Per gli sviluppatori che hanno il compito di rilasciare il codice in tempo reale, queste attività aggiuntive possono sembrare di intralcio al lavoro vero. In questi casi un punto di riferimento centrale, come una pagina Confluence del piano di modifica, può semplificare la documentazione coinvolgendo l'intero team.

La risposta a questa grande sfida è far sì che i processi di gestione delle modifiche siano il più semplice possibile. Dove puoi, riduci al minimo le approvazioni. Scegli strumenti tecnologici che si integrano perfettamente in modo che gli sviluppatori non debbano inserire le stesse informazioni in più sistemi. E automatizza ovunque sia possibile. Queste funzioni all'interno di Jira Service Management offrono ai team la flessibilità di operare secondo i propri ritmi e nel modo che preferiscono.

Quanto più semplice è il processo, tanto più facilmente potrai contare sulla collaborazione e la fedeltà del team.

Nella maggior parte delle organizzazioni IT tradizionali, un CAB (Change Advisory Board) ha il compito di valutare le implicazioni tecniche e aziendali delle richieste di modifica. Il processo tradizionale comporta alcune sfide: rilasci lenti, processi complessi e, talvolta, mancanza di comunicazione e collaborazione. Ecco perché i team con le prestazioni migliori stanno ridefinendo il modello CAB.

L'obiettivo è mantenere il valore che queste board aggiungono ai nostri processi IT, consentendo le comunicazioni e bilanciando l'esigenza di effettuare le modifiche con i rischi che tali modifiche comportano, affinché il tipico processo CAB diventi più Agile e strategico. Questo in genere significa:

• Richiedere l'approvazione CAB solo per le modifiche più rischiose (e utilizzare strumenti comprovati come la peer review, le checklist virtuali e l'automazione per gestire le modifiche meno rischiose)
  
• Assegnare ai CAB il compito di definire la strategia e aiutare i team a sviluppare pratiche che riducono i rischi e il carico di lavoro della gestione delle modifiche attraverso le efficienze e l'automazione dei processi
  
• Trasformare i CAB in riunioni virtuali e in tempo reale invece di attendere le riunioni di persona per rispondere a modifiche importanti o a domande sui processi

L'aspetto chiave è uno spostamento verso la strategia. Invece di agire come entità di controllo, il nuovo CAB ha il compito di abilitare la modifica. Invece di diventare un collo di bottiglia, il nuovo CAB è una risorsa strategica. La revisione del codice e l'accesso alle problematiche tecniche sono riservate alle peer review e alle persone più adatte a rilevare errori nel codice, mentre il CAB può concentrarsi sui processi e le strategie, e supportare la continuous delivery.

Nell'approccio tradizionale, i rilasci venivano raggruppati e lanciati tutti insieme contemporaneamente. Ciò che molti di noi ora sanno è che questo approccio si presta a imprevisti gravi e rende più difficile risalire all'origine dei problemi che dovessero presentarsi. Rilasci più piccoli e più frequenti possono limitare l'ambito di un potenziale imprevisto. 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.

Organizzare rilasci più piccoli e controllati è più semplice quando i team possono coordinare questi rilasci in una programmazione delle modifiche. In questo modo, gli sviluppatori evitano le aree di conflitto o identificano le date di interruzione più facilmente. Le funzioni di gestione delle modifiche di Jira Service Management consentono ai team di accedere a una programmazione centralizzata con le informazioni di cui hanno bisogno per eseguire questi rilasci frammentati.

L'ITIL a volte ha una cattiva reputazione. Viene visto come restrittivo e obsoleto, ma la verità è che ha molto da offrire ai team IT, compresi quelli che hanno adottato una cultura DevOps. Il problema non risiede nell'eccessiva rigidità dell'ITIL, ma nel modo in cui interpretiamo le sue linee guida.

Se l'ITIL viene visto come una serie di regole rigide, sembrerà, naturalmente, restrittivo. Se viene visto come una serie di linee guida fondamentali su cui la tua azienda può fare affidamento, ti sembrerà uno strumento utile per sviluppare la tua pratica di gestione delle modifiche.

Questo vale per ogni framework e approccio culturale. ITIL, Lean, DevOps, Agile, CD... nessun framework, per quanto apprezzato, potrà risolvere tutti i tuoi problemi in un colpo solo. Troppo spesso, ci affidiamo a un framework o uno strumento per risolvere i problemi interni quando invece dovremmo guardare alla cultura del team.

Dai CAB ai gruppi DevOps, i team leader nel settore stanno adottando la collaborazione, l'apertura e gli aggiornamenti in tempo reale. La gestione delle modifiche esiste per consentire ai team di coordinarsi. Modifiche, imprevisti e problemi hanno effetti a catena su più team, un aspetto che diventa più evidente man mano che aumenta la complessità della tua organizzazione.

Una gestione delle modifiche efficace semplicemente non può avvenire nei silos. Le organizzazioni che si adoperano per favorire una collaborazione più aperta sono quelle che hanno una maggiore probabilità di migliorare la propria pratica di gestione delle modifiche.

Ogni funzione di Jira Service Management ha lo scopo di unire i team per aiutarli a raggiungere i propri obiettivi più velocemente (in questo caso specifico, attuare le modifiche più rapidamente e senza imprevisti). Alla base di ogni team coeso e high-velocity c'è la collaborazione. Una piattaforma trasparente dotata di strumenti come Confluence, chat e videoconferenze integrate e flussi di lavoro personalizzabili consente a tutti di partecipare nel modo che preferiscono, con il contesto completo.

L'ingegneria del caos è una pratica recente incentrata sulla verifica della resilienza attraverso la suddivisione o la disattivazione dei componenti di un prodotto o servizio. Allo stesso modo, l'ingegneria della resilienza applica deliberatamente tutti i possibili fattori di stress su un sistema per verificarne la capacità di restare operativo, ad esempio esponendolo a un elevato carico di lavoro dovuto a un traffico intenso a un elevato numero di utenti.

Entrambe le pratiche servono a identificare i problemi e le modifiche che devono essere applicate per evitare imprevisti futuri. Questo approccio preventivo sta offrendo molto valore ai team di gestione delle modifiche e consente ai team di gestione degli imprevisti di ottenere un notevole risparmio in termini di tempo, budget e stress da avvisi.

I processi di gestione delle modifiche efficaci dovrebbero essere integrati nei vari strumenti utilizzati dagli sviluppatori. Chiedere ai team di apprendere un nuovo strumento, inserire informazioni in più strumenti o gestire uno strumento sconosciuto e scomodo in genere ne rallenta l'adozione, compromettendo la tua capacità di fornire aggiornamenti preziosi ai clienti.

In Atlassian, monitoriamo le modifiche utilizzando Jira Service Management. La piattaforma Jira riunisce facilmente i team di sviluppo e operativi, fornendo trasparenza e contesto tracciabile prima ancora che gli sviluppatori inizino a programmare fino a quando le modifiche vengono distribuite in produzione.