Sviluppo ed Esercizio

Nei due articoli precedenti abbiamo trattato due figure professionali fondamentali dell’IT: lo sviluppatore di software (o developer) e l’amministratore di sistema (o sysadmin). Due professionalità molto importanti che in Italia sono spesso anche il ruolo di ingresso nel lavoro, talora punto di inizio di carriere professionali che conducono a posizioni come responsabili commerciali, manager, imprenditori.

In questo articolo esaminiamo invece i processi di cui queste figure sono protagonisti: lo sviluppo del prodotto software e/o del servizio IT cui esso da origine e la fase di esercizio di quel software ovvero del servizio IT su di esso basato.

Apparentemente essi hanno caratteristiche ed esigenze di ottimizzazione opposte e che potrebbero venire in contrapposizione.

Lo sviluppo del software, in special modo quello del software custom, cioè costruito ad hoc per le esigenze specifiche di un cliente è un progetto, è definito, seguendo la terminologia “canonica” del Project Management Institute: “uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un servizio o un risultato unici”, dove temporaneo significa limitato nel tempo.

Il progetto software ha un inizio, che di solito parte con l’analisi, e una fine con un suo esito: il prodotto software viene realizzato e gli errori corretti (in gergo debuggato) o almeno con la maggior parte di essi corretti e consegnato al cliente o rilasciato sul mercato.
Il modello “canonico”, tutt’ora molto usato, è il modello a cascata o waterfall (si veda ). La manutenzione ordinaria ed evolutiva (quindi, con l’aggiunta di nuove caratteristiche) di software come, ad esempio, MS Word ha portato ai cicli di sviluppo, un primo passo verso il passaggio da progetto (attività una tantum) a processo (attività ripetitiva).

Ma, quasi sempre, fino ad anni recenti, il focus manageriale in relazione allo sviluppo software è stato incentrato sul completare la fase di sviluppo e rilasciare il software o la versione X del software, caratterizzata da un certo insieme di caratteristiche funzionali, nel minor tempo possibile, con la migliore qualità possibile (caratteristica essenzialmente letta come “con il minor numero di errori possibile”) e al minor costo possibile. Non sempre queste tre esigenze sono compatibili fra loro. Il fatto che poi il software entra in uso in azienda o presso privati e diventa il componente fondamentale di un servizio IT, che deve produrre un valore per il cliente con il proprio funzionamento non era adeguatamente considerato.

La fase di esercizio di un software a formare un servizio IT è un processo, ossia “un insieme di attività coordinate tra loro atte a produrre un valore per i clienti/utenti del processo stesso e ripetute nel tempo”. Sono quindi attività che si ripetono, in modo più o meno ciclico.

L’ottimizzazione di tali attività ha come obiettivo produrre un servizio misurabile con parametri opportuni, come per esempio la velocità di risposta di un programma gestionale a un’interrogazione dell’archivio clienti, il cui valore si mantiene costante nel tempo con un costo per unità di tempo circa costante nel tempo. Quindi le caratteristiche più apprezzabili sono stabilità e duratività.

In alcuni casi questo ha portato all’estrema conservatività: le persone incaricate dell’esercizio dei sistemi tendevano a voler conservare l’esistente nel corso degli anni, opponendosi addirittura ai cambiamenti nei sistemi stessi, in maniera più o meno evidente.

L’evoluzione temporale dei sistemi informativi e dei loro servizi IT

Entro le aziende o le organizzazioni come la pubblica amministrazione i servizi IT sono un supporto per le attività di business. L’arroccarsi sulla conservazione dell’esistente (“ciò che funziona non si cambia”) si scontra quindi con due esigenze che sono diventate nel tempo sempre più importanti:

1. Disporre di soluzioni software conformi alle esigenze di business dell’azienda; all’inizio dell’introduzione dell’IT in azienda (in Italia, tra gli anni’60 e gli anni ’80) tali esigenze erano stabili o variavano poco nel tempo, consentendo quindi pause di stabilità abbastanza lunghe fra un aggiornamento software ed un altro; oggi, in un mercato instabile, l’azienda deve cogliere tutte le opportunità possibili ed l’IT deve seguire e supportare queste esigenze di business;
2. Ridurre i costi di esercizio: tecnologie proprietarie di aziende vendor, che sino a non molto tempo fa dominavano il mercato oggi sono molto meno frequenti per gli alti costi di esercizio pagati sotto forma di licenze d’uso e canoni di manutenzione di software ed hardware.

A partire da fine anni’90 in poi questo ha prodotto, nelle piccole e medie imprese, il passaggio ad architetture più aperte (spesso basate sui PC), con costi di acquisto e manutenzione molto minori e la scoperta successiva di un costo non considerato, legato alla minore qualità di esercizio: il tempo di fermo macchina, in cui l’azienda subisce il danno della impossibilità, da parte degli operatori, di usare le risorse IT nel proprio lavoro.

Negli anni, trend di mercato tesi a riportare indietro le cose a soluzioni più “centralizzate” e in apparenza più controllabili, si sono alternati a ondate di decentralizzazione, spesso in entrambi i casi pilotati abilmente dagli uffici marketing delle grandi aziende di informatica interessati a vendere.

Questo ha prodotto, in molte aziende, soprattutto in Italia, una sfiducia generale nell’IT, vista come “un male necessario” e non uno strumento di innovazione. In molti casi, tale visione ha scavato un solco sempre più profondo fra le posizioni degli sviluppatori o dei responsabili degli applicativi da un lato e quelle dei sistemisti dall’altro. Questo, sia nel caso in cui gli sviluppatori siano esterni all’azienda che usa il software sia, spesso a maggior ragione, nel caso in cui siano interni.

Estremizzando, secondo gli sviluppatori i sistemisti sono spesso “conservatori sino all’eccesso, si oppongono a tutte le novità, hanno bisogno che gli si scriva tutte le informazioni relative ad un software perché non sono capaci di arrivarci da soli e sono pigri”.

Dall’altra parte, secondo i sistemisti, gli sviluppatori “lavorano male, non fanno adeguate verifiche, non ci danno le informazioni necessarie per installare e gestire i software che, quasi sempre, sono pieni di errori e dobbiamo essere noi a correggere e fare funzionare”.

Queste posizioni, in apparenza inconciliabili, stanno venendo superate, come è necessario che sia. In diverse mie attività di consulenza e coaching aziendale ho operato proprio in questo senso: la prima azione necessaria è stato applicare le tecniche di coaching per fare superare la diffidenza reciproca ai reparti.

La soluzione: gestire tutto il ciclo di vita

Per superare le problematiche il primo stadio è stato l’avvento di modelli di gestione riguardanti tutta la fase di vita di un prodotto software, dal momento in cui questo viene concepito, come evoluzione di sistemi precedenti o ex-novo, al momento in cui entra in esercizio e per tutta la durata dell’esercizio, sino a versioni successive o alla sua dismissione (si veda anche ).

Un esempio di ciclo è rappresentato nella figura sottostante:

Il modello forse più diffuso è quello del ciclo di vita del servizio del framework ITIL, ripreso poi nello standard ISO20000 e descritto in questo articolo.

Essenzialmente un ciclo di questo tipo si può suddividere in 5 fasi:

1. Azione strategica (in ITIL: Service Strategy), in cui viene deciso, in funzione delle esigenze di business se un servizio o un software deve essere realizzato o evoluto e quali obiettivi esso dovrà raggiungere, oltre che quale budget dedicare al progetto di realizzazione e/o evoluzione; corrisponde ai blocchi di definizione strategica del ciclo in figura;
2. Azione progettuale (in ITIL: Service Design), in cui vengono raccolti i requisiti di dettaglio, compiuta un’analisi funzionale completa e svolta la progettazione, pianificato il lavoro di realizzazione e svolta l’implementazione (blocchi raccolta requisiti, analisi, design, pianificazione e implementazione in figura);
3. Azione di installazione (in ITIL: Service Transition), in cui il prodotto realizzato viene verificato, collaudato e installato (blocchi test, collaudo, avvio);
4. Azione di esercizio (in ITIL: Service Operation), in cui il servizio IT basato sul prodotto realizzato funziona normalmente ed eroga il valore per cui è stato creato al business;
5. Azione di monitoraggio e valutazione necessità di cambiamento (in ITIL: Continual Service Improvement), in cui periodicamente si valuta la rispondenza del servizio ai bisogni presenti del business e le eventuali necessità di modifica e/o evoluzione.

L’insieme dei prodotti (deliverable) di ogni fase diventa poi l’ingresso della fase successiva.

Da un punto di vista manageriale, seguire il modello significa sia gestire perfettamente ogni fase (garantendo che il prodotto relativo sia il migliore possibile) che, soprattutto, gestire il coordinamento del passaggio di consegne tra le fasi.
Tipicamente, infatti, le persone coinvolte operativamente nel ciclo sono impegnate solo in una delle diverse fasi, mentre tra i prodotti di ogni fase deve essere realizzata e condivisa la documentazione necessaria alla trasmissione di ogni informazione necessaria. Questo rende indispensabile la presenza di un manager che sovraintende a tutto il ciclo.

Il problema legato alla implementazione pratica e operativa di tutto ciò è la scarsa percezione del valore delle documentazioni: se non c’è il passaggio delle informazioni necessarie tra le fasi tutti i problemi sopra descritti riemergono con forza.

L’evoluzione: l’approccio Agile e il DevOps

L’evoluzione progressiva ha portato prima all’introduzione delle metodologie Agili (si veda ) e in particolare del metodo SCRUM, che segmenta un macro progetto in tante fasi di durata limitata, ciascuna delle quali deve produrre un risultato significativo per il business, con un rischio basso.

E poi all’adozione dei processi di Continuous Development , ossia un insieme di tecniche per permettere lo sviluppo iterativo continuo delle applicazioni che formano i servizi IT.

Le fasi di ogni iterazione sviluppo-collaudo-rilascio sono ben codificate e coordinate in modo da ridurre la necessità di passaggio di informazioni al minimo indispensabile. Ove possibile, inoltre, le azioni ripetitive come le installazioni vengono automatizzate mediante ampio uso di strumenti software appositi, governati con opportuni linguaggi di vera e propria programmazione.

L’evoluzione ulteriore ha condotto al DevOps (Development and Operations), una metodologia di implementazione pratica della gestione del ciclo di vita, in particolare del passaggio dallo sviluppo alla messa in produzione. DevOps enfatizza al massimo la collaborazione, la comunicazione e l’integrazione tra sviluppatori software e professionisti IT (sysadmins, DBA, etc.).

Lo scopo di questa metodologia è mettere un’organizzazione in grado di fornire prodotti e servizi software in tempi rapidi, evitando i “conflitti” descritti sopra.

DevOps, non a caso, è nato nel contesto di aziende come Twitter ed Amazon, dove cioè il servizio IT e le sue componenti software sono parte fondamentale del business e dove il business stesso evolve rapidamente per seguire le necessità commerciali, così che il software deve essere in grado di stare al passo.

Questo significa che gli sviluppi e i rilasci in produzione (con sostituzioni di componenti precedenti) diventano una necessità globale, magari con più cambiamenti in una stessa giornata di lavoro.

Come mostrato nella  figura, infatti, DevOps prevede l’integrazione globale fra i tre pilastri dei sistemi informativi rappresentati in figura: sviluppo, qualità (test, verifiche, collaudo) e operations. Quindi coordinamento tra i reparti è la soluzione. Arrivare a questo obiettivo prevede un grande cambiamento dentro le aziende, possibile con vere e proprie azioni di coaching per i team.

Per chiudere un commento personale: ho vissuto sul campo la prova pratica di tutto ciò anche in ambito universitario. Alcuni anni fa ho infatti partecipato come relatore di tesi al progetto svolto sul tema di un brillante studente lavoratore che è poi diventato responsabile sviluppo presso l’importante portale Web di servizi dove già lavorava.

L’introduzione del DevOps in questo caso ha portato alla riduzione del 40% della durata di ogni ciclo di sviluppo, con contemporanea riduzione a meno della metà degli errori riscontrati nei software prodotti a formare un servizio IT fondamentale per l’azione di tutto il portale.

Bibliografia

Giulio Destri e Corrado Lombardi – I processi di sviluppo software: la storia
https://www.slideshare.net/giuliodestri/d06-storia-svilupposoftware

Corrado Lombardi e Giulio Destri – I processi di sviluppo software: l’evoluzione agile e il DevOps
https://www.slideshare.net/giuliodestri/i-processi-di-sviluppo-software-levoluzione-agile-ed-il-devops