Formazione scritta DevOps

Come favorire il flusso di lavoro DevOps?

In DevOps il flusso è l'intera catena di produzione del software, dall'idea al codice in esecuzione nei sistemi di produzione. Tu e i team DevOps avete la responsabilità di creare e mantenere un flusso affidabile, coerente e rapido per raggiungere e superare gli obiettivi dell'organizzazione e battere gli altri prodotti e servizi nel vostro mercato.

Definisci una missione per la trasformazione DevOps

Una volta formato il team DevOps, il passo successivo è definire una missione. Solo con una missione comune il team potrà lavorare bene. Senza di essa non saprà stabilire le priorità del lavoro critico né distinguere gli ostacoli bloccanti dalle incombenze. La missione deve essere ambiziosa e significativa, ma raggiungibile entro un periodo definito.

La missione va adattata al tuo team DevOps. Si basa sulle caratteristiche, sulle difficoltà e sugli obiettivi dell'organizzazione e serve i clienti interni ed esterni che interagiscono con il team.

Ecco alcuni esempi di missione con cui avviare la trasformazione DevOps:

• Ridurre del 75% in 3 mesi il lead time medio dal check-in del codice alla messa in produzione.
• Ridurre del 33% in 6 mesi il lead time medio dalla richiesta alla messa in produzione.
• Ridurre del 50% in 12 mesi il numero di incidenti in produzione.

Che cos'è un flusso di valore e chi vi partecipa?

Per migliorare il lavoro devi conoscere il flusso di valore. Nei sistemi informatici, un flusso di valore è una sequenza di attività necessarie per progettare, costruire e gestire un determinato prodotto e servizio software. Definisce anche le persone, le competenze, le risorse di servizio e i materiali che consentono al flusso di procedere.

In una struttura organizzativa complessa nessuno è in grado di individuare da solo l'intero flusso di valore. Per questo è importante coinvolgere tutti i membri del team DevOps, i portatori di interesse, i fornitori, i rappresentanti dei clienti e, se possibile, i clienti stessi.

Mappa il flusso di valore per individuare le possibilità di miglioramento

Una mappa del flusso di valore permette a te e al tuo team DevOps di visualizzare come si svolge un'attività tipica nell'organizzazione di sviluppo e rilascio del software. Non serve documentare in modo esaustivo ogni singolo passaggio. L'obiettivo è capire abbastanza bene il flusso abituale per individuare le principali inefficienze, i vincoli, i problemi e gli sprechi di tempo e risorse.

Quando gli ingegneri dello sviluppo e delle attività operative si riuniscono per la prima volta per creare una mappa del flusso di valore, spesso chi si occupa delle attività operative capisce per la prima volta gli effetti negativi che i server di database mal configurati e privi di tablespace hanno sui team di sviluppo. Analogamente, chi sviluppa software vede spesso per la prima volta le conseguenze del rilascio di software privo di funzioni integrate di monitoraggio, disponibilità, testabilità e configurazione.

Elimina il maggior numero possibile di passaggi di consegne, vincoli e sprechi

I passaggi di consegne, gli sprechi e i vincoli sono tra i fattori di efficienza più importanti e trascurati. Il trasferimento di un'attività da un team all'altro richiede notifiche, richieste, pianificazione, definizione e revisione delle priorità e risoluzione dei conflitti.

Ogni passaggio di lavoro da un team all'altro comporta perdita di informazioni e incide negativamente sul lead time complessivo del flusso di valore.

Per superare questi problemi:

• Metti in discussione il tempo necessario per ogni passaggio di consegne. Nell'esempio sopra, per esempio, occorrono 80 ore prima che il team di deployment prenda in carico il codice che ha superato i test. Perché? Non potremmo automatizzare il processo? Certo che possiamo.
• Elimina gli sprechi causati dai passaggi di consegne ripetitivi. Nell'esempio, il team di test rimanda al team di sviluppo il 65% delle funzionalità. Le correzioni di alcuni difetti devono essere consegnate fino a 3 volte prima di essere approvate dai tester. Potremmo accelerare queste iterazioni con una migliore integrazione tra i team di sviluppo e test? L'elevato numero di difetti indica inoltre che qualcosa non funziona bene nel team di sviluppo. Occorre individuare e risolvere le cause di questi problemi di qualità.
• Metti in discussione i passaggi di consegne ed eliminane il più possibile. Nell'esempio, dopo aver precisato una richiesta, servono 320 ore perché chi ha l'autorità di approvarla la esamini. Perché serve questa figura? Che valore apporta al flusso? Ha informazioni e una visione sufficienti per decidere bene? Perché non entra a far parte del team che precisa le richieste? Conoscerebbe molto meglio ciò che approva e si eliminerebbe un passaggio di consegne che richiede 320 ore. Se non rimuovi i vincoli e le barriere che rallentano il flusso, non puoi aspettarti molto da DevOps.

DevOps ti chiede di porti domande simili per cambiare lo status quo. Naturalmente non tutti nell'organizzazione saranno felici di sentirle, ma tu sei già pronto.

Rendi visibile il flusso a tutti

Per far sì che il lavoro proceda da sinistra a destra e che l'organizzazione DevOps raggiunga i suoi obiettivi, servono strumenti e meccanismi che rendano visibile il flusso. Nell'IT basta un clic per assegnare un'attività da un team all'altro nel flusso di valore. Tuttavia, a causa di lavoro incompleto, dipendenze incoerenti e malintesi, capita ogni giorno che le attività rimbalzino tra i team, facendo «un passo avanti e due indietro». Il lavoro procede troppo lentamente, ammesso che proceda.

È quindi importante che il flusso sia visibile a tutti, anche oltre il proprio team. DevOps usa il Product Backlog, il backlog per la pianificazione dello sprint e le lavagne Kanban per visualizzare i flussi. Questi strumenti devono mostrare sia le attività del team DevOps sia l'intero flusso, dall'ideazione dei prodotti e servizi alla manutenzione operativa e alla dismissione. Quando il lavoro si ferma, tutti potranno accorgersene rapidamente. Rimuovere gli ostacoli che impediscono al lavoro di procedere in modo continuo diventa responsabilità di tutti.

Limita le dimensioni dei lotti e il lavoro in corso

Una ricerca condotta da Stanford University ha rilevato che il multitasking è meno produttivo che fare una sola cosa alla volta. I ricercatori hanno anche scoperto che chi riceve regolarmente molteplici flussi di informazioni elettroniche fatica di più a concentrarsi, ricordare informazioni o passare da un lavoro all'altro rispetto a chi completa un'attività alla volta.

Che cosa significa per il team DevOps? Che serve ridurre il lavoro in corso e limitare le dimensioni dei lotti di codice rilasciato. Ad esempio, il team può limitarsi a un massimo di 6 attività di sviluppo in corso per evitare continui cambi di contesto e concentrarsi sul lavoro da svolgere. In alternativa, puoi stimare ogni attività in story point con valori della sequenza di Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, ...) e il team DevOps lavora fino a un certo numero totale di story point (velocity) in un periodo stabilito (sprint).

Oltre a migliorare qualità e produttività, limitare le dimensioni dei lotti ti permette di individuare e risolvere più in fretta le cause alla radice dei problemi. Quando un'attività è completata, esegui il check-in nel repository condiviso, la convalidi con la piattaforma di integrazione continua e poi la distribuisci in produzione. Con un lotto piccolo è più facile individuare i problemi in produzione dovuti alla distribuzione del codice e gli eventuali rollback sono più semplici. Inoltre, rilasciando di continuo in produzione, il team è costantemente orgoglioso di contribuire alla missione dell'organizzazione. Sta a te confrontare questo modo di lavorare con il morale, la motivazione e le difficoltà tecniche di team che scrivono codice per 8 mesi senza distribuirne una sola riga in produzione.

Usa il 20% del tempo per ridurre il debito tecnico

Quando l'organizzazione non riserva tempo alla riduzione del debito tecnico e continua a sovrapporre soluzioni di ripiego, arriverà al punto in cui tutti gli ingegneri passeranno tutto il tempo a risolvere problemi. Per usare un'analogia finanziaria, l'organizzazione pagherà soltanto gli interessi sul debito.

CONCLUSIONE

In questo capitolo abbiamo spiegato che cosa sono il flusso di valore e il flusso in DevOps, perché sono importanti e che cosa puoi fare per far avanzare il lavoro nel flusso di valore.