DevOps: La condivisione

Nel nostro viaggio nelle organizzazioni DevOps, ci occupiamo dell’ultima iniziale dell’acronimo CALMS (Culture, Automation, Lean, Measurement e Sharing); ci occupiamo dello Sharing.

Per ridurre il time-to-market, procedere per piccoli step e correre meno rischi, il programmatore ha bisogno di introdurre nuove modifiche al software, il che significa rilasciare spesso e frequentemente. Il sistemista, invece, ricerca l’affidabilità, ovvero sistemi stabili e senza interruzioni di servizio.

Apparentemente, quindi, rilasciare spesso è in contrapposizione con le responsabilità dei sistemisti. Questa tensione può essere superata creando uno spazio condiviso e di fiducia, dove sia i sistemisti sia i programmatori possono discutere e pianificare gli interventi con adeguata coordinazione.

Organizzarsi per team cross-funzionali, come abbiamo visto, è il primo passo, il secondo è iniziare a essere corresponsabili.

Definire il confine della responsabilità

Per adottare DevOps è indispensabile mettere da parte le barriere e costruire un clima positivo e di collaborazione.

La differenza principale che introduce DevOps rispetto ai metodi tradizionali è la corresponsabilità tra Dev e Ops nei confronti del prodotto in produzione che, per anni, è stata delegata principalmente ai sistemisti.

Con DevOps gli sviluppatori hanno accesso all’infrastruttura di produzione, viceversa i sistemisti hanno accesso al codice sorgente dei prodotti.

Oltre al ritmo dello sviluppo di funzionalità, c’è quello dell’operatività ordinaria, che significa servizio senza interruzione, following the sun. Molte organizzazioni affiancano un programmatore ed un sistemista reperibili come secondo livello di escalation.

Quando un problema sconfina in un territorio in cui il team non ha competenze o capacità adeguate, si fa riferimento ai piani di escalation, ossia di incremento dell’urgenza di un problem o di un incident che vengono affidati alla responsabilità di un apparato organizzativo con maggiore potere decisionale.

I metodi per comunicare

I metodi Agili, così come il movimento DevOps, privilegiano la comunicazione faccia a faccia come prima scelta.

L’espressione “mostra, non dire” racchiude lo spirito di eliminazione della retorica che non è strettamente necessaria al messaggio. D’altronde Confucio, in una famosa massima, diceva: “se sento dimentico, se vedo capisco, se faccio imparo”.

Risulta determinante uno stile di management che incoraggi il confronto e lo scambio di informazioni. Il patrimonio di informazione persistente in un team è in fondo la sua storia e costituisce parte del suo valore.

Adottare strumenti di collaboration che incentivino la videoconferenza e consentano di memorizzare le informazioni in un punto comune e sotto gli occhi di tutti, permette la diffusione della conoscenza. Conoscere dove poter reperire le informazioni, mette i membri del team nelle condizioni di procedere autonomamente senza dover attendere i tempi della comunicazione diretta.

Spazi condivisi del team come directory , wiki o blog si rivelano allora culturalmente indispensabili.