Disciplined DevOps è la visione di Disciplined Agile 2 (DA 2) per quello che riguarda il Continuos Deployment di una nuova soluzione o di una nuova release già in erogazione.
Disciplined DevOps
Di DevOps abbiamo analizzato diversi aspetti, sia da un punto di vista Culturale, che di Relazione e di Automazione, ma perché DA 2 aggiunge la parolina magica “Disciplined”? cosa si cela dietro essa?
Sicuramente è utile riportare la specifica definizione di Disciplined DevOps:
“Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.”
che si avvicina moto a quella presa a riferimento nei precedenti post:
“DevOps è un approccio Culturale in cui l’intera Line of Business si assume la responsabilità della creazione di Valore per il cliente. In tale scenario, Developers e Operations sperimentano continuamente nuovi modi di lavorare insieme, andando a standardizzare e padroneggiare i processi attraverso la ripetitività e la pratica.”
Non solo i Dev e gli Ops sono quindi chiamati a collaborare per il successo di una iniziativa di business, ma lo è l’intera Line Of Business. Questo è un aspetto fondamentale: ogni attività, progetto, elemento, deve essere sempre facilmente collegabile ad una specifica iniziativa di business! Se ciò non è possibile, allora bisogna fermarsi e riflettere se ciò che si sta realizzando non sia un “tecnoware”, ovvero un’attività fine a sé stessa.
DA 2 suggerisce di estendere gradualmente l’approccio DevOps alle varie funzioni aziendali, in modo da far maturare progressivamente nel proprio contesto la Cultura necessaria a tale cambiamento.
Estendere gradualmente DevOps
Come è facile immaginare, il punto di partenza è proprio quello più immediatamente collegabile a DevOps, ovvero l’abbattimento dei Silos e delle barriere che separano Dev e Ops. Per fare ciò ci vengono, ancora una volta, in aiuto le “Three Ways” di Gene Kim, che possono essere collegate ad una serie di pratiche di riferimento:
System Thinking
- Utilizzare un singolo Repository per codice e ambienti;
- Tenere sotto version control tutti gli artefatti, sia di Dev che di Ops;
- Creare un processo di release deterministico;
- Preparare gli ambienti di Dev, Test e Produzione prima dell’inizio dello sviluppo, tenendoli consistenti;
- Sottoporre il codice a commit giornaliero;
- Dotarsi di test di regressione automatici;
- Rilasciare le feature in produzione su base giornaliera;
- Abbattere il Lead-Time e aumento del Cycle-Time in chiave «pull».
Amplify Feedback Loops
- Revisionare alla «Pari» il codice e i cambiamenti agli ambienti;
- Utilizzare i test automatici per consentire ai team di lavorare e collaborare proficuamente;
- Monitorare proattivamente gli ambienti di produzione;
- Risolvere rapidamente i difetti e i problemi di sicurezza;
- Incentivare una Cultura basata sulla fiducia;
- Aumentare la sinergia tramite comunicazione e coordinamento;
- Incentivare la produttività individuale, di team e cross-team.
Culture of Continual Experimentation and Learning
- Dedicare una parte consistente delle attività (15-20%) al pagamento del Debito Tecnico;
- Iniettare volontariamente «bug e fault programmati» per testare la resistenza del sistema;
- Fare quanto è possibile per alzare l’asticella della produttività;
- Condividere le esperienze di successo e di fallimento, in modo da imparare da esse e aumentare la competitività sul mercato.
Il tutto è meticolosamente pensato (lasciando alla specifica realtà di adattarlo e contestualizzarlo) per ridurre al minimo il Value Canyon, ossia il gap che divide lo sviluppo dall’erogazione della soluzione.
Value Canyon
Ricordate sempre: finché la soluzione non è nelle mani del cliente, il valore prodotto è pari a 0!
Stay tuned!
