Metrologia e contratti - a cura di Luigi Buglione, GUFPI-ISMA

s

Rubrica a cura di Luigi Buglione – GUFPI-ISMA

LA

MISURA

DEL

SOFTWARE

Metrologia e Contratti

Parte 11 – Una Stima non è (e non può essere) una Misurazione

METROLOGY AND CONTRACTS – PART 11: ESTIMATION IS NOT (AND CANNOT BE) A MEASUREMENT Eleventh paper based on the new GUFPI-ISMA guidelines on the proper use of “Principles, Assumptions and Contractual Best Practices” (vol.1, 2016), it deals with estimation, too often managed in a trivial way more than it could be useful.

RIASSUNTO

Undicesimo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di “Principi, Assunzioni e Best Practice Contrattuali” (vol.1, 2016), riguarda gli aspetti di estimation, troppo spesso banalizzati e semplificati più di quanto possa essere invece utile.

Nel mondo “quotidiano” leggere la pagina di un ricettario sembrerebbe ba - nale, ma in fondo contiene tutto ciò che ci servirebbe per effettuare una stima. Dagli ingredienti e relative quantità (asset management), proporzionate su un dato numero di commensali (capacity management), si illustra anche la difficoltà nella preparazione del piatto (risk management), il tempo di preparazione e cottura (effort/duration), i passi da seguire per cucinare (processo/procedura) e gli eventuali abbinamenti (requisiti non-funzionali)... Insomma, ci sarebbe di tutto anche nei progetti ICT se ci fossero database e repository altrettanto “mat uri” da racchiudere anni di esperienza, utili ad affinare una stima iniziale effettuata in modo analogico/espe rienziale [2]. Ma analizzando le practice delle organizzazioni, da quel le più grandi a quelle più piccole, sembra sempre che non ci sia tempo (o budget) per poter operare in questo modo, con il risultato

di sovra/sotto-stimare quantità, effort e costi e quindi non ottimizzare in ogni caso la gestione di un progetto: una sotto-stima comporterebbe una minore percezione del valore di un progetto da parte dei clienti/utenti con possibili richieste di modifica in corso d’opera; una sovra-stima invece bloccherebbe un numero di asset maggiori del ne - cessario, che potrebbero invece essere più profittevolmente utilizzati in altri progetti. Ma qual è il corretto trade-off da applicare e soprattutto come poter “indovinare” una stima minimizzando l’errore?

INTRODUZIONE

Undicesimo 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” GUFPI-ISMA 2016 [1]. Il mestiere di un misuratore è quello di creare maggiore confidenza nel proporre stime che siano il più possibile vicine al valore finale determinato al termine di un progetto. E per poterlo fare servono almeno alcuni punti di attenzione, tra cui: – aver perimetrato il corretto scope (ambito) progettuale; – non aver sottovalutato i possibili rischi e imprevisti, sia di prodotto/servizio che di progetto; – disporre di dati storici, possibilmente i propri, per un’analisi non solo analogico/esperienziale. Una stima non è una misurazione, altrimenti nessuno si sbaglierebbe mai e l’errore di stima sarebbe pari allo 0%... eppure tutti vorrebbero ottenere un risultato positivo senza spendere tempo, energie e conoscenze per conseguirlo ... Come poter accorciare i relativi tempi e costi? Analizziamo ora uno scenario

tipico in un contratto ICT e quali spunti migliorativi potrebbero essere inseriti.

PARTIRE DALLE ATTIVITÀ QUOTIDIANE PER IMPARARE NELL’ICT...

IL CONO (O L’IMBUTO) DELL’INCERTEZZA: QUANTO ERRORE È AMMESSO?

La Fig. 1 illustra il c.d. “cono” (o “im - buto”, se si ruotasse in senso orario di 90°) dell’incertezza e illustra come anche raccogliendo dati sugli errori commessi si possa in modo iterativo imparare a migliorare le prossime stime, affinando il margine di errore nel tempo. Maggiore (e migliore) la capacità d’imparare e non ripetere un errore, maggiore la riduzione della curva verso un range di errore ammissibile: anche nel mondo fisico i metrologi hanno una guida all’incertezza sulle misure e si propone altresì una taratura periodica degli strumenti di misurazione proprio per minimizzare gli errori, che per natura non possono non esistere [5]. Ma che possono (ovviamente) essere limitati sapendo e avendo contezza del motivo per il quale li avremmo commessi in passato.

Presidente GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org

T_M N. 1/19 ƒ 59

LA

MISURA

DEL

SOFTWARE

s

N. 01ƒ ; 2019

I “TRE DELTA”

Figura 1 – (a) cono dell’incertezza [3]; (b) imbuto (funnel) dell’incertezza [4]

un progetto (analisi/disegno, realizzazione, test e collaudo) e quelle che erogano un servizio in esercizio (poggiandosi su un sapiente mix di aspetti e tecniche Agili, Lean e di IT Service Management). Raccontare DevOps con lo schema “1-2-3” di GUFPI-ISMA può aiutare a comprendere meglio la visione temporale di un progetto che è di norma scomponibile in tre parti: – lo sviluppo iniziale (DEV-Development); – l’esercizio dei prodotti/servizi (OPS-Operation);

Per far ciò sarebbe opportuno ragionare sulla raccolta dei “tre Delta” [6], ovverosia dei tre gap tra le coppie dimensione/effort che si potrebbero raccogliere: Delta 1: tra stima (partendo dai requisiti utente) e primo conteggio (determinato usando le specifiche funzionali e tecniche); Delta 2: tra primo conteggio e consuntivo finale (al momento del collaudo e rilascio); Delta 3: tra la stima e il collaudo/rilascio. Storicizzando tali valori, si rende possibile a una prossima stima applicare un fattore correttivo (in genere a crescere), imputato però a partire dai propri dati storici e dal modo di derivare i requisiti utente iniziali per quel tipo di progetti, con lo stile di quel dato committen - te. Facciamo un esempio: se misurassimo la di mensione funzionale con i Function Point (FP) e ci fosse un Delta 1 mediano del 20%, alla prossima stima su progetti di pari caratteristiche e con quello stesso stile di scrittura stringato nell’esprimere dei requisiti funzionali utente (FUR – Functional User Requirement) sa rebbe ragionevole poter considerare sul valore stimato in FP aggiungere un +20% così da stringere la forbice. Motivo? Molti contratti purtroppo fissano il tempo/costo di un progetto al momento della determinazione degli UR e non a consuntivo e in ogni caso va stimata la “giusta” quantità di asset (persone/FTE, tempo, logistica, costi, ...) fin dall’inizio per poter organizzare il progetto stesso. Pertanto minore è il gap tra stima e consuntivo, migliori sono la gestione del progetto e la bontà dei

Figura 2 – Fasi di un Ciclo di Vita e i c.d. “tre Delta”

risultati conseguiti e percepiti da tutti gli stakeholder, a partire dagli utenti. Altro elemento parte della soluzione: realizzare una reale UX (User eXperience), troppe volte sbandierata nei contratti e nelle presentazioni e poche volte implementata.

Tra l’altro coinvolgendo gli utenti finali (end user) di una data soluzione/servizio alla stesura dei requisiti, si ridurrebbe il loro possibile livello d’insoddisfazione con una conseguente riduzione dei costi di gestione del pro getto stesso... in somma, per dirla semplice: due piccioni con una fava!

DEVOPS: UNA NUOVA “BUZZWORD” O UNA REALE OPPORTUNITÀ?

A partire dal 2009 si è sviluppato un movimento culturale e professionale denominato DevOps [7] – crasi dei termini Develoment e Operation a indicare rispettivamente le persone delle fasi “alte” di un ciclo di vita di

– (ma soprattutto) la manutenzione continuativa (SVC – Service) per tenere aggiornato il prodotto/servizio nel tempo tramite le opportune change request (CR)/request for change (RfC) che ne allungherebbero la vita utile, cioè il proprio “valore” nel tempo a vantaggio dei propri stakeholder. Se potessimo sfruttare la c.d. regola di Pareto, quella dell’80-20, in questo caso l’applicheremmo al contrario, dicendo che in genere in un’ottica di medio-lungo termine i tempi/costi per le attività di tipo DEV rappresenterebbero c.a. un 20% contro l’80% di quelle di tipo OPS/SVC laddove, come indicato dalla norma ISO 14764 [9], la manutenzione assume varie forme e tipologie, come mostrato in figura 3.

T_M ƒ 60

N. 01ƒ ;2019

LA

MISURA

DEL

SOFTWARE

n

Figura 3 – Lo Schema 1-2-3 GUFPI-ISMA [8]

Nei contratti ICT di oggi spesso lo scenario tipico prevede un affidamento unico di servizi per un periodo pluriennale includendo attività sia di tipo 1 (DEV) che 2 (OPS) e 3 (SVC) invece che gestire contratti separati secondo il semplice e logico principio del divide-et-impera. L’effetto è quello di avere un impianto metrico con un nu - mero di misure e indicatori significativo ma che non coglie spesso le relazioni causa-effetto tra le parti 1-2-3. Un esempio: non collegare il numero di maggiori incidenti in produzione a una possibile analisi e progettazione che non distingue i requisiti funzionali e non-funzionali ma gestire separatamente i due fenomeni rischia di non incentivare un corretto processo di testing, poichè si rischierebbe di non controllare la proporzione tra test case di diversi tipi (black box vs white/gray box), per una corretta gestione del valore sia verso il business (committente) che verso gli utenti finali di quel prodotto/servizio. E via dicendo. Osservare “the big picture” (il progetto di servizio) gestendo però le tre parti (DEV-OPS-SVC) in modo separato sebbene coordinato è il passo successivo verso una maggiore e migliore maturità e capacità delle organizzazioni. La semplificazione (vedere il progetto di servizio come un unicuum) non corrisponde necessariamente a migliorare i processi e le performance aziendali: serve (con un po’ di buon senso) misurare “q.b.” ricordando sempre che “a plan of measure is not a measurement

plan”. Le misure individualmente valgono (e costano) di più di quanto non accada usandone me - no (in numero) ma coordinate e legate in modo causale tra di lo - ro, restituendo un valore informativo superiore a un costo più basso.

ALCUNE CONCLUSIONI...

Misurare è un processo a supporto del project management, come suggerito da molti modelli di processo, quali ad esempio CMMI e SPICE. Ma tale processo prevede diversi livelli di dettaglio: l’attività di estimation non è e non dev’essere vissuta come una “black art” bensì come un’attività da ingegnerizzare attraverso la raccolta di dati storici, sia qualitativi che quantitativi, che permettano a un’organizzazione di affinare nel tempo i “delta” verso un valore finale a consuntivo. “Conoscersi per migliorare” è fondamentale. Una misurabilità in ottica DevOps prevede sempre più di costruire piani di misurazione integrati, come suggerisce lo standard ISO 15939 [10], tra le tre parti di cui si compone un progetto di servizio (DEV-OPS-SVC). Non serve misurare tanto (o troppo), ma usare un numero adeguato di misure e indicatori tale da poter rispondere agli obiettivi informativi del progetto. Nei prossimi numeri continueremo a commentare ulteriori aspetti derivati dall’analisi delle nuove “linee guida contrattuali” GUFPI-ISMA [1] (in Fig. 5 gli argomenti trattati nel documento), cercando di evidenziare come una corretta applicazione degli aspetti di misurazione permetta a un decisionmaker di disporre di dati, informazioni e conoscenze (trend) il più possibile oggettivi utili prendere decisioni consapevoli che tengano in debito conto anche dei rischi da individuare, gestire e possibilmente prevedere in un progetto.

Figura 4 – Principi, Assunzioni e Best Practice Contrattuali (PABPC), Vol.1 [1]

“To estimate the time it takes to do a task: estimate the time you think it should take, multiply by two and change the unit of measure to the next highest unit. Thus, we allocate two days for a one hour task”

(Westheimer’s Rule from the ‘Murphy’s Laws’)

RIFERIMENTI BIBLIOGRAFICI

[1] GUFPI-ISMA, Principi, Assunzioni & Best Practice Contrattuali (Vol.1), Feb 2016. [2] Buglione L., Organizzare l’esperienza per stimare l’effort di progetto, Forum ISIPM, 20/06/2006. [3] McConnell S., Software Estimation: Demistifying the Black Art, Microsoft Press, 2006, ISBN 9780735605350. [4] Thomsett R., Radical Project Management, Prentice Hall, 2002, ISBN 9780130094865. [5] JCGM, JCGM 100:2008 GUM 1995 with minor corrections Evaluation of measurement data – Guide to the expression of uncertainty in measurement, 2008, Joint Committee for Guides in Metrology/Working Group 1, URL: https://goo.gl/bnyjyJ. [6] GUFPI-ISMA, Stato dell’Associazione, Presentazione, 01/12/2016. Kim G., Behr K., Spafford G., The Phoenix Project: A novel about IT, DevOps and Helping Your Business Win, 2018, ISBN 978- 1942788294. Buglione L., “123” e “ABC”: Interpretare DevOps per misurare bene (e meglio) i progetti, PMexpo2017, Roma, 28/10/2017, URL: https://goo.gl/JSqupV. ISO/IEC, IS 14764:2006, Maintenance Process. ISO/IEC, IS 15939:2017, Measurement Process.

T_M ƒ 61