Evidenziate le diverse strategie verticali per il supporto a DevOps, ci avviamo verso la conclusione di questa serie di post dedicando gli ultimi due a quelle orizzontali, ovvero General e Teaming Strategies.

Le General Strtegies si occupano di definire le strategie complessive di un approccio Disciplined DevOps:

• Collaborative work. Uno dei pilastri della cultura DevOps è l’abbattimento dei silos che separano, almeno dell’implementazione base, Dev e Ops. Non meraviglia quindi come la collaborazione sia un aspetto fondamentale nella rimozione di tali barriere e nell’ottimizzazione del processo di delivery nel complesso, considerando gli uni stakeholder degli altri. Come mostrato precedentemente, Disciplined DevOps fa un passo avanti, contemplando anche stakeholder non tecnologici, come per esempio quelli annessi al marketing;
• Automated dashboards. Si tratta di rendere facilmente fruibili i dati provenienti dall’IT Intelligence (Data Management Strategies) creando appositi Information Radiator che consentano di avere un monitoraggio costante del valore corrente delle metriche di riferimento per le diverse componenti della pipeline di delivery;
• Integrated configuration management. Dev e Ops hanno quasi sempre una visione diversa in merito alle attività e ai contenuti di configuration management (CM): i Dev vedono la CM in relazione allo specifico progetto (o attività di sviluppo), mentre gli Ops in relazione ai diversi asset IT nel complesso. In questo caso sono più i Dev a dover estendere la propria azione di comprensione, gestione e allineamento, per meglio supportare le attività complessive, multi progetto e multi prodotto, di delivery;
• Integrated change management.  Questa strategia punta ad eliminare, o comunque ridurre fortemente, i problemi annessi ad un’evoluzione non coordinata, e focalizzata sui singoli progetti dai singoli team, dell’infrastruttura IT (software ed hardware). Tipicamente ogni team tende a far evolvere la propria infrastruttura in modo autonomo, scontrandosi poi con il fatto che in fase di delivery sugli stessi ambienti debbano coesistere stack tecnologici diversi, in versione e in tecnologie. Una forte interazione tra Dev e Ops, basata sulle strategie precedenti, è fondamentale per comprendere gli impatti che una nuova scelta tecnologica “locale” avrà sul quella di riferimento;
• Training, education, and mentoring.  Essendo DevOps prima di tutto un cambiamento culturale, non meraviglia che le persone debbano essere supportato nell’approntamento dei relativi valori, principi e pratiche;
• Continuous Improvement.  L’apprendimento “assistito” lascia successivamente il posto ad un approccio di Continuous improvement, dove i team, e le persone di riflesso, si migliorano castamente per trovare la propria specializzazione di DevOps;
• One team. La strategia più ambiziosa è, chiaramente, quella di eliminare completamente ogni differenza tra Dev e Ops, puntando ad avere un unito team che ragioni come tale ed operi in chiave “you build it, you run it”, ovvero sia responsabile dell’intero ciclo di vita del prodotto.

Quest’ultima strategia porta a concretizzare il concetto “forte” di Agile, abbattendo il Value Canyon e creando uno stream che porta la soluzione direttamente nelle mani dell’utente in modo iterativo ed incrementale.

Say tuned!