s
LA MISURA DEL SOFTWARE
Rubrica a cura di Luigi Buglione – GUFPI-ISMA
Metrologia e Contratti Parte 15 – DevOps e le Linee Guida Contrattuali GUFPI-ISMA METROLOGY AND CONTRACTS PART 15: DEVOPS AND GUFPI-ISMA CONTRACTUAL GUIDELINES Fifteenth paper based on the new GUFPI-ISMA guidelines on the proper use of “Principles, Assumptions and Contractual Best Practices” (vol.1, 2016) is about the mapping between measurement-related DevOps elements and GUFPI-ISMA Contractual Guidelines main topics.
RIASSUNTO Quindicesimo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di “Principi, Assunzioni e Best Practice Contrattuali” (vol.1, 2016), relativo alla mappatura del paradigma tra gli aspetti DevOps legati alla misurazione e i principali lemmi delle Linee Guida Contrattuali GUFPI-ISMA. INTRODUZIONE
Quindicesimo appuntamento con la disamina dell’applicazione di buoni principi di misurazione ai contratti (ICT e non), relativo agli aspetti di corretto censimento delle misure e loro utilizzo in un piano di misurazione, altro spunto incluso nelle “linee guida contrattuali” GUFPIISMA 2016 [1]. Stavolta parliamo del collegamento tra questo documento e DevOps, un movimento culturale e professionale che negli ultimi dieci anni sta cercando di ottimizzare la gestione progettuale stringendo le maglie del lavoro dei gruppi DEV e OPS, in estrema sintesi rispettivamente chi lavora prima e dopo il rilascio di un deliverable. Il documento PABCP (Principi, Assunzioni & Best Practice Contrattuali) tratta della misurazione e della misurabilità a 360°, seppur dedicando un’attenzione particolare dagli aspetti legati ai prodotti software. Ma vediamo meglio di cosa si tratta... DEVOPS: COSA È E CHE VALORE PUÒ GENERARE
DevOps (termine derivato dalla fusione di “Development” e “Operation”) T_M
N.
1/20
64
viene definito genericamente come “un movimento culturale e professionale che sottolinea l’importanza della comunicazione, collaborazione e integrazione tra sviluppatori software e professionisti IT dell’Operation” [2] e nasce come serie di valori, principi e best practice nel 2009, a valle dei primi DevOps Days, incontri informali tra professionisti IT. L’obiettivo era (ed è) quello di eliminare il cosiddetto “muro della confusione” tra coloro che pensano e producono un deliverable in un progetto (DEV – Development) e chi invece lo gestisce durante la fase di erogazione/esercizio (OPS – Operation). In un contesto IT, quindi, il DEV viene visto tipicamente come l’insieme (tra gli altri) degli analisti, programmatori, tester mentre l’OPS come un gruppo che include il Service Desk, i sistemisti, e tutti coloro che aiutano gli utenti a “usare” in operatività una soluzione IT (o basata sull’IT). La collaborazione più stretta tra i due macro-gruppi può portare ovviamente a considerevoli risparmi e a un maggior valore per i diversi stakeholder coinvolti. In Fig. 1 si presenta a sinistra la tipica situazione di molte organizzazioni che vedono i due macro-gruppi ben distin-
ti, con un impegno lavorativo descritto dai triangoli blu. L’obiettivo è di tendere sempre più verso la distribuzione dell’effort rappresentata nella figura di destra, laddove quelli dell’OPS potrebbero supportare i colleghi del DEV quali co-analisti/realizzatori a una migliore gestione delle modifiche (change) sulla base dell’esperienza lavorativa e quelli del DEV potrebbero ricevere un coaching dai colleghi dell’OPS utile a future (ri) progettazioni e realizzazioni più attagliate ai fabbisogni reali degli utenti di un dato sistema/servizio. Le fasi del ciclo di vita descritte in azzurro sono quelle proposte da ITIL v3 (2011), ovverosia Service Design (progettazione), Service Transition (realizzazione, test & collaudo) e Service Operation (erogazione e supporto all’esercizio). Gli aspetti di misurazione e monitoraggio sono cross, spalmati sull’intera attività e descritti nella fase trasversale di CSI (Continual Service Improvement). Perché parlare di DevOps in questa rubrica? Perché diversi capitolati e bandi di gara (pubblici e privati) stanno inserendo l’adozione di tale paradigma nelle risposte richieste ai fornitori quale elemento di gestione del valore nei nuovi contratti ICT [4, 5]. DEVOPS: VALORI, PRINCIPI E PRATICHE
DevOps non è una metodologia “organica”, né un modello con processi predefiniti, ma un insieme di valori, princi-
Presidente GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org
