Il Change Freeze: la finestra di rilascio che nessuno rispetta

Narratore: Alcune voci di questo episodio sono generate sinteticamente. Siamo in sala riunioni. È la riunione di chiusura sprint. In squadra nessuno ha ancora finito i test, ma tutti hanno già finito le forze.

Security: Prima di chiudere, un avviso. Da lunedì parte il change freeze trimestrale. Nessun rilascio in produzione per due settimane. È nella policy aggiornata, la trovate nel portale.

Junior Developer: Due settimane intere? E se scopriamo un bug in produzione?

Security: Per quello ci sono i fix di emergenza. Ma servono approvazione formale, motivazione scritta, e firma di chi ha la delega.

Junior Developer: Ok. Ma come si definisce un'emergenza, esattamente?

Security: È un'emergenza quando impattare il business o la sicurezza. Nel dubbio, compilate il modulo di richiesta e lo valutiamo.

Junior Developer: Ok, ma fammi un esempio concreto. Se martedì un cliente non riesce più a scaricare le fatture, è un'emergenza? E se non riesce a vedere il nuovo grafico della dashboard?

Senior Developer: Le fatture è emergenza. Il grafico dipende da chi guarda la dashboard. Se lo guarda il direttore, è emergenza.

Security: Non è del tutto sbagliato. La policy chiede una valutazione dell'impatto. Il problema è che la valutazione la fa chi ha bisogno del rilascio.

Senior Developer: Nel dubbio. Quindi è un'emergenza tutto ciò che qualcuno con la firma decide che sia un'emergenza.

Junior Developer: Quindi il modulo serve più a chi rilascia che al freeze. Un po' come il cinturino che si allaccia solo quando scatta la telecamera.

Narratore: Entra il Product Owner. Entra con quel passo veloce di chi ha già una notizia che qualcun altro avrebbe preferito non ricevere.

Product Owner: Scusate, so che è l'ultima mezz'ora di sprint, ma il cliente ha chiesto una cosa: la nuova funzione deve andare live prima del freeze. La sua direzione deve mostrarla a un comitato la settimana prossima. Non posso passare al comitato con una demo locale, serve produzione.

Senior Developer: E come fa la sua direzione a saperlo, adesso, un comitato?

Product Owner: Boh, ma mi ha scritto il referente stamattina e ora il commerciale aspetta una data. Se non diamo la data oggi, loro la danno loro, e sappiamo come va a finire.

Junior Developer: Ma il freeze inizia lunedì. Se rilasciamo la funzione venerdì, il freeze arriva il giorno dopo. Non ci spostiamo di due giorni e resta tutto a posto?

Security: Rilasciare venerdì pomeriggio, poche ore prima di entrare in un freeze in cui non si potrà più toccare nulla, è l'operazione meno difendibile del trimestre. Se qualcosa va storto, lo scopriamo quando non possiamo più intervenire.

Product Owner: Lo so, lo so. Ma se dimmi che va storto al settanta per cento, io domani non ho una risposta per il cliente. Dimmi solo che la data va bene e a quel punto il rischio diventa di tutti. Il cliente vuole che la funzione sia live quando il freeze parte. Così in comitato può dire che l'ha fatta rilasciare prima del congelamento. Ha un valore di racconto.

Senior Developer: Quindi la regola serve a qualcuno solo se la rispettano sopra. Bene, venerdì pomeriggio. Esattamente il momento peggiore dell'intera settimana, forse dell'intera civiltà. E ricordo una cosa: l'ultima release fatta in corsa è diventata l'hotfix del weekend. Eravamo in tre in call la domenica mattina. Io c'ero.

Junior Developer: Aspetta, ma quel deploy era del venerdì come questo? Quindi tra due settimane potremmo essere di nuovo in call la domenica.

Product Owner: Lo so, e nessuno vuole rifarlo. Ma la data è già comunicata al cliente. Se la spostiamo, il problema diventa mio.

Narratore: Alla riunione si aggiunge il Chief Technology Officer. Nessuno lo aveva convocato, ma la riunione era ancora aperta.

Chief Technology Officer: Ho visto il calendario del freeze, complimenti. Questo è un segnale di maturità operativa, la board lo apprezzerà. Due settimane di disciplina, l'organizzazione che dimostra di poter frenare. È trasformazione vera.

Product Owner: Perfetto, allora confermo al cliente che venerdì pomeriggio la funzione va live. Cioè, prima del freeze.

Chief Technology Officer: Venerdì pomeriggio? Mmm. Ok, qui propongo una cosa: eccezione gestita. Il freeze non è un muro, è una cornice. Le eccezioni formali, approvate, tracciate, dimostrano che il processo funziona. Questa release diventa la prima eccezione ufficiale del nuovo processo.

Security: Vale a dire che la prima volta che usiamo il processo, lo violiamo. Per dimostrare che funziona.

Chief Technology Officer: Esatto. Un'eccezione ben documentata è anche compliance. Nel report trimestrale la mettiamo come pilota del nuovo framework di rilasci.

Junior Developer: Quindi nel report trimestrale, alla voce rilasci durante il freeze, il numero sarà zero?

Security: Sarà zero, più una sezione a parte con le eccezioni. Che crescendo di trimestre in trimestre, diventerà la statistica più interessante del documento.

Junior Developer: Scusate se faccio la domanda ingenua. Se la prima applicazione del processo è una deroga, il processo non funziona già? O funzionerà solo dopo?

Chief Technology Officer: Ottima domanda. Proprio il tipo di domande che portano avanti la cultura dell'organizzazione. Te ne parliamo in retro.

Security: Intanto serve la richiesta formale. Formulario di eccezione: motivazione, impatto, rollback, e tre approvazioni.

Junior Developer: Tre approvazioni. Per rilasciare una cosa che il freeze doveva impedire di rilasciare.

Senior Developer: Approvazioni le prendiamo tutte e tre. L'ultima volta che nessuno approvò una cosa, andò in produzione lo stesso.

Narratore: Due settimane dopo. Il change freeze è ufficialmente in corso. Il Senior tiene un registro personale dei rilasci effettivamente avvenuti.

Senior Developer: Giovedì, hotfix urgente, approvato. Venerdì, correzione al report, marcata hotfix di stabilizzazione. Lunedì, configurazione, passata come mitigazione. E giovedì ancora, il report richiesto dal cliente. Urgente per una sola persona: quella che lo ha approvato.

Junior Developer: E il fix di configurazione di lunedì, perché era urgente? Quello non l'ho capita.

Security: Perché il modulo diceva impatto sul business. Chi lo ha compilato non ha specificato quale. La motivazione scritta c'era, una riga. Nessuno ha chiesto la seconda.

Junior Developer: Quindi sono stati passati sei rilasci in due settimane. Tutti come emergenze.

Senior Developer: Sei rilasci, cinque moduli compilati dopo il rilascio, e una sola persona che ha approvato tutto. Il processo regge, guarda. Nessuno osa guardarlo troppo da vicino.

Security: Evidenza: non ci sono stati incident gravi durante il freeze. Da log, gli interventi sono tutti stati classificati come fix di emergenza con approvazione. Quindi la policy è stata applicata correttamente.

Chief Technology Officer: Perfetto. Il freeze va dichiarato un successo. Zero incident gravi, e il framework delle eccezioni già rodato. Esattamente il percorso evolutivo che avevamo immaginato.

Senior Developer: Un successo. Va bene. Lo scrivo anche io, nel registro personale, a pagina nuova.

Chief Technology Officer: Perfetto, e il prossimo trimestre facciamo ancora meglio. Obiettivo: zero eccezioni. Ce la possiamo scrivere già sulla presentazione di kickoff, così poi misuriamo il passo avanti.

Product Owner: Zero eccezioni. Perfetto, appunto. Se il prossimo trimestre il cliente chiede un'altra cosa in freeze, la chiamo io, eccezione gestita, e il numero parte da zero comunque.

Junior Developer: Un successo. Che è durato due settimane e ha avuto sei eccezioni.

Senior Developer: Benvenuto nel processo. Da qui in poi te lo raggiungi da solo.

Narratore: La settimana seguente, la policy del change freeze viene aggiornata con una nuova sezione dedicata alle eccezioni. Secondo le statistiche di accesso del portale, è la parte più letta del documento.