Una software factory (azienda o divisione all’interno di un’azienda) affronta delle fasi riassunte in quella che chiamo “la traiettoria evolutiva”. La traiettoria descrive il percorso di una software factory a mano a mano che cambia e matura. È fondamentale che una volta arrivati a un certo stadio non si torni più indietro al punto precedente.

Secondo la filosofia kaizen (miglioramento continuo) bisogna tenere sempre un minimo di tensione organizzativa orientata al miglioramento altrimenti subentrano l’entropia e le vecchie abitudini, che tornano a fare capolino facendoci retrocedere nella traiettoria evolutiva.

La leadership aziendale deve considerare che la software factory non potrà funzionare sempre allo stesso modo durante la sua vita. Cultura, valore e tecnologia dovranno evolvere perché ciò che ha portato la software factory (e quindi il business) fino a un certo punto comincerà a non essere più ottimale nei punti successivi.

 STORY – Non sta più in piedi

Alessandro è un imprenditore che, insieme a due soci, fonda un’azienda che produce una piattaforma software per il settore delle scommesse sportive. I soci fondatori sono competenti, appassionati e cominciano a costruire l’azienda ispirandosi ai principi agile e DevOps che fanno parte del loro DNA. Dopo qualche anno nel mercato Alessandro si trova ad affrontare un momento di crescita improvvisa: deve passare da 10 persone a circa 40. La mia avventura nell’azienda di Alessandro nasce da una cena:

“Michele, i miei processi non scalano più. Ciò che funzionava per 10 non sta in piedi per 40. Ho bisogno di una persona di fiducia che mi aiuti a ristrutturare certe parti. C’è del casino, ti interessa lavorare con noi?”

Con Alessandro abbiamo un po’ alla volta cambiato il modo di visualizzare il lavoro, introdotto automazione spinta fino alla produzione di documentazione per scopi di compliance legale, automatizzato l’evoluzione dello schema di database e stravolto il processo tecnologico di deployment (citando solo gli aspetti più tecnici). L’azienda ha dovuto evolvere anche nell’assistenza clienti, supporto, reperibilità e molto altro. Ciò che funzionava per 10 persone e le aveva portate fino lì, non era più adeguato.

Sopravvivere

In questa fase iniziale, la Software factory è appena stata creata e il suo obiettivo principale è quello di diventare operativa il più rapidamente possibile. La priorità è rilasciare funzionalità utili per il business, anche a costo di accumulare del debito tecnico che dovrà essere gestito successivamente. L’attenzione è sulla costruzione di una base solida per lo sviluppo, configurando strumenti essenziali e stabilendo politiche iniziali che permettano ai team di lavorare in modo produttivo. È una fase caratterizzata da pragmatismo e velocità, dove si pongono le fondamenta per un sistema che sarà migliorato e raffinato nel tempo. Leadership ed Engineering iniziano a costruire un dialogo che sarà cruciale per il futuro allineamento strategico.

Alcuni segnali di questa fase:

• Definizione iniziale di una piattaforma di gestione application lifecycle management (es. Azure DevOps, GitHub, GitLab).
• Policy di gestione e uso del version control/repository.
• Creazione di linee guida minime per pull-request e revisione del codice.
• Pipeline di build e deployment configurate, anche se con processi manuali parziali.
• Pianificazione a breve termine basata sulle priorità di business immediate.
• Stabilire un minimo di automazione per i processi ripetitivi.
• Dialogo iniziale tra Leadership e Engineering per allineamento sugli obiettivi.

Vivere

In questa fase, il business comincia a vedere una certa prevedibilità nei rilasci, e le dinamiche del team Engineering sono stabilizzate. I processi di base per la gestione del lavoro e delle priorità sono consolidati, permettendo al team di operare con una maggiore consapevolezza e controllo del flusso di lavoro. L’azienda comincia ad adottare pratiche più strutturate, come il testing automatizzato e la gestione del debito tecnico, mentre le retrospettive regolari permettono di identificare opportunità di miglioramento continuo. La leadership e il team Engineering hanno sviluppato un dialogo solido, con una visione condivisa del lavoro da svolgere e delle priorità strategiche. Il focus è ora su miglioramenti incrementali e sulla riduzione degli sprechi nel processo produttivo.

Alcuni segnali di questa fase:

• Processo strutturato per la gestione dei requisiti e del backlog.
• Limitazione consapevole del work-in-progress (WIP) per evitare sovraccarichi.
• Inizio di un approccio formale al testing automatizzato.
• Retrospettive regolari per individuare e pianificare miglioramenti.
• Analisi non strutturata del feedback e della telemetria per decisioni operative.
• Dialogo consolidato tra Leadership e Engineering, con definizione di ruoli e responsabilità chiari.
• Prime pratiche di gestione del debito tecnico.
• Strutturazione di una cultura del miglioramento continuo.

Funzionare

In questa fase, la Software factory ha trovato un ritmo stabile e produttivo. Le pratiche fondamentali sono ben radicate nella mentalità aziendale, e i team operano in modo autonomo, mantenendo un costante allineamento con gli obiettivi di business. La suite di testing automatizzato è robusta e ben strutturata, e l’azienda inizia a fare uso più intensivo di dati e telemetria per prendere decisioni informate, fin dalla fase di requisiti. Il debito tecnico è monitorato e ridotto, e il focus si sposta su una pianificazione di medio termine. L’attenzione è rivolta alla formazione continua del personale e agli investimenti in ricerca e sviluppo, con l’obiettivo di migliorare le capacità aziendali e di esplorare nuove opportunità di innovazione.

Alcuni segnali di questa fase:

• Team autonomi e allineati agli obiettivi strategici del business.
• Suite di testing automatizzato ben strutturata, con copertura significativa.
• Assistenza clienti strutturata, con feedback diretto al team di sviluppo.
• Collaborazione attiva tra Marketing e Engineering per integrare feedback utente nelle roadmap.
• Decisioni basate su dati provenienti da telemetria e analisi avanzate.
• Sicurezza e telemetria considerati già dalla fase di definizione dei requisiti.
• Debito tecnico monitorato e ridotto secondo priorità.
• Pianificazione a medio termine, con roadmap chiara e scadenze realistiche.
• Programmi di formazione e aggiornamento continuo per il personale.
• Investimenti regolari in ricerca e sviluppo, con sperimentazione di nuove tecnologie.

Prosperare

A questo punto, la Software factory è una realtà matura e leader nel suo settore. I processi sono fluidi e l’interazione tra i vari dipartimenti è ottimizzata per minimizzare gli sprechi e massimizzare la consegna di valore agli utenti finali. La fase di prosperità è caratterizzata da forti investimenti in ricerca e sviluppo, pratiche avanzate come chaos engineering e red-teaming per garantire la resilienza dei sistemi, e un focus costante sul miglioramento della sicurezza e della compliance attraverso DevOps. I team operano con efficienza, grazie a una cultura aziendale che promuove il benessere del personale e una mentalità orientata all’innovazione continua. L’organizzazione è agile, adattabile e in grado di sperimentare con nuove tecnologie e pratiche per mantenere la sua posizione di leadership.

Alcuni segnali di questa fase:

• Forti e continui investimenti in ricerca e sviluppo, con focus sull’innovazione.
• Politiche di wellbeing strutturate e mirate al mantenimento del benessere del personale.
• Esperimenti avanzati e sistematici di A/B testing per la validazione delle feature.
• Implementazione di pratiche di chaos engineering per testare la resilienza dei sistemi.
• Team di red-teaming dedicati alla sicurezza e alla simulazione di attacchi.
• Implementazione di team SRE (Site Reliability Engineering) per la gestione proattiva delle operazioni.
• Integrazione di DevOps nei processi di Compliance e audit.
• Cultura aziendale orientata all’eccellenza, con flusso di lavoro ottimizzato tra i dipartimenti.
• Capacità di adattamento rapido alle esigenze del mercato e innovazione continua.

Quando iniziai a lavorare nel 2010, il manifesto Agile stava compiendo 9 anni. Pubblicato nel 2001 diede inizio a una nuova era nell’approccio alla gestione dei progetti software. Scrum e Kanban, le principali implementazioni ispirate ai principi Agile, si stavano diffondendo a macchia d’olio (soprattutto la prima).

Ma, già da qualche anno, in vari angoli del mondo, si stava sperimentando l’adozione dei principi Lean del mondo manifatturiero nei contesti di sviluppo software. Nella comunità DevOps ci si riferisce a questo periodo come “La convergenza DevOps”.

Da quel periodo sono passati svariati anni e si può empiricamente affermare che quegli esperimenti hanno avuto successo. Le pratiche che permettono a una software factory di essere come definita in questo libro si basano profondamente su queste ideologie.

Ancora prima, nei primi anni 2000, era XP (Extreme Programming) una delle metodologie Agile più diffuse con le sue pratiche di Test-Driven-Development e Continuous Integration: concetti che saranno poi fondamentali per arrivare al movimento DevOps.

Usare un framework oppure un altro fa davvero tutta questa differenza? Su cosa dobbiamo concentrarci davvero per capire se la nostra Software factory sta funzionando bene? E cosa significa farla funzionare bene?