Menu

Più produttività e controllo nello Sviluppo Software

Più produttività e controllo nello Sviluppo Software

A guardare i dati sugli investimenti e la crescita del mercato italiano, non si direbbe, ma il Software è divenuto così strategico per il succeso delle imprese che anche McKinsey - che normalmente parla di strategie ai Top Manager - vi ha dedicato un approfondito Report. Vediamone e commentiamone i passaggi essenziali.

Al di là dei problemi strutturali e politici del nostro Paese, che comportano un eccessivo costo del lavoro a fronte di basse remunerazioni del personale e a sprechi di risorse su diversi fronti - burocrazia, tasse, energia... - una delle cause più significative alle quali si può imputare la progressiva perdita di competitività delle nostre imprese sta negli scarsi livelli di investimenti che si fanno nell'area informativa: applicazioni, servizi, sistemi. A questo proposito, i dati consuntivi dell'andamento del 2013 parlano chiaro: siamo drammaticamente indietro su tutti gli indicatori del mercato ICT, a partire dal tasso di crescita che per il terzo anno consecutivo da noi è negativo, mentre nel resto del mondo è in crescita, dall'incidenza degli investimenti in ICT sul PIL, dove siamo parecchi punti sotto le medie di tutti i Paesi evoluti, e persino nel commercio elettronico che sale anche da noi, come in tutto il resto del mondo, ma che in Italia si sviluppa meno che altrove e incide ancora poco sull'intero settore del commercio. Insomma, da qualsiasi parte si voglia guardare, il problema è che siamo indietro, per cui perdono punti le imprese e tutta la società italiana nel suo insieme. Eppure...

Eppure, i segnali che le cose dovrebbero cambiare, nella sostanza e non solo nelle dichirazioni, sono tanti e provengono ormai da qualsiasi fonte. Una di queste, molto autorevole, è la società di consulenza di direzione McKinsey, che normalmente guida il Top Management delle imprese più grandi del mondo, ma anche numerosi Capi di Stato, nelle loro scelte di medio e lungo termine, raramente concentandosi sugli aspetti tecnici e tecnologici, parte integrante ma raramente determinante nei piani di più grande respiro. Proprio ad evidenziare l'importanza che le tecnologie informatiche - prima tra tutte il software - hanno quindi acquisito nell'impostazione e nello sviluppo di qualsiasi iniziativa, lo scorso agosto, i consulenti di McKinsey Michael Huskins, James Kaplan e Krish Krishnakanthan hanno pubblicato il Report Enhancing the efficiency and effectiveness of application development, dal quale qui riporto alcuni dei passaggi cruciali.

Il motivo di tale attenzione è presto detto: il Software è ormai al centro di tutto ciò che ci circonda, non solo delle APPS che animano i nostri telefonini. E' "embedded", ovvero calato all'interno, di tutte le apparecchiature che utilizziamo quotidianamente: telefoni cellulari, automobili, televisori, ma anche nei condizionatori d'aria, negli ascensori o nelle macchine utensili di qualsiasi officina meccanica o fabbrica. Costituisce il cuore dei servizi che utilizziamo, dai treni agli aerei, dalle banche alle assicurazioni, per non parlare di Internet, dei sistemi di logistica, di navigazione, o persino dei servizi meteorologici. E qui si scontrano due fenomeni in totale controtendenza tra loro: da un lato, c'è la continua moria di personale informatoco all'interno delle aziende, nell'insegna che ormai il software non lo sviluppa più nessuno e che gli sviluppatori non servono più, dall'altro una fame sempre più crescente di professionisti in grado di coprire posizioni che restano aperte anche a lungo in aree dove nel passato era difficile trovare analisti e programmatori: Web Agency, società industriali, aziende di commercio elettronico e grande distribuzione, compagnie di trasporto... Un numero su tutti: stando all'US Bureau of Economic Analysis, tra il 1990 ed il 2011, negli Stati Uniti d'America, l'incidenza del Software sul totale dei nuovi investimenti fatti dalle imprese è passata dal 32% al 60%: oltre il doppio in un decennio!

La grande trasformazione sta quindi proprio nel radicale cambiamento di ruolo del Software: dall'Amministrare e Documentare, il Software è divenuto centrale per il Fare ed il Decidere, cambiando così fisionomia, interlocutori e soprattutto priorità: fatturare in ritardo di un giorno può, infatti, essere un problema - ma non grave - mentre sbagliare nel tracciare una rotta di volo, nell'alimentare una catena distributiva, nell'acquistare o vendere titoli in Borsa può portare al successo o al fallimento dei suoi utenti. E per limitarsi ad un caso molto più semplice e sotto gli occhi di tutti, basti pensare che ogni giorno le Direrzioni Marketing delle compagnie telefoniche si inventano nuove promozioni e criteri di tariffazione per incrementare la propria competitività o per reagire alle iniziative della concorrenza, trovando il principale ostacolo nelle loro dinamiche operative proprio nella difficoltà di tradurre in applicazioni automatiche la gestione dei nuovi modelli di vendita.

Il problema dell'efficienza? Sta nei meccanismi di misurazione

La tesi dei tre consulenti di McKinsey è molto semplice: perché nonostante ormai oltre cinquant'anni di esperienze e tentativi i risultati nella conduzione dei progetti software continuanuo ad esser tutto sommato deludenti? Semplice: perché ne vengono misurati indicatori poco significativi, perdendo di vista l'attenzione sugli aspetti più cruciali dell'attività.

Ben lontano dagli aspetti relativi la produzione di Software, anche Jeremy Rifkin si è espresso su questo tema, partendo da un altro punto di vista per arrivare a conclusioni analoghe. La sua tesi è infatti collegata al concetto stesso di produttività. La produttività - sostiene infatti Rifkin - è un parametro che si addice alle macchine, non al lavoro creativo o a quello intellettuale. Potremmo mai chiedere a Michelangelo mentre scolpisce la Pietà "quanti metri cubi di marmo ha lavorato oggi"? E la produzione di Software è un puro lavoro intellettuale, dove possiamo affidare alle macchine - ovvero ai Tool - alcune operazioni, mentre il suo vero valore va cercato nella qualità delle soluzioni adottate e non unicamente nell'efficienza con la quale si realizzano. Inutile quindi misurare l'Output materiale dei progetti di sviluppo - dalle ormai antiche linee di codice, ai più moderni Function Point - mentre risulta molto più conveniente valutare gli incrementi di produttività - e non solo - che scaturiscono dall'utilizzo del software steso.

A peggiorar la situazione ci sono i fattori di comparazione degli Output ottenuti che normalmente vengono correlati al costo orario degli sviluppatori o ad altri elementi quali gli scostamenti dai piani iniziali in termini di costi o date di consegna. Metriche utili per misurare alcuni micro-fenomeni operativi, ma non in grado di attribuire al Software il suo vero valore in termini aziendali. Metriche che per di più sono onerose da rilevare e che spesso non forniscono risultati comparabili in modo affidabile in quanto presuppongono l'utilizzo di processi e strumenti standard, cosa difficilmente riscontrabile all'interno di una stessa azienda e ancor meno quando si ragiona in termini trasversali tra organizzazioni eterogenee.

Combinare Use Case e Use Case Point

Per superare tali limiti, Michael Huskins, James Kaplan e Krish Krishnakanthan propongono di combinare l'impiego degli Use Case per la determinazione dei requisiti del Software ad un nuovo parametro di misuca chiamato Use Case Point (UCP) che misurano le funzionalità create, dando così maggior e miglior significato aziendale alle attività di sviluppo Software. Strada che può esser abbastanza facilmente seguita dalle aziende che già hanno adottato gli Use Case all'interno delle proprie pratiche di sviluppo, mentre che ne richiede l'introduzione per chi non lo avesse ancora fatto. D'altronde, vista la qualità dei risultati che le metodologie di determinazione dei requisiti basate sull'impiego di Use Case sono in grado di assicurare, qualora un'azienda non le avesse ancora fatte proprie diverrebbero la priorità assoluta del 2014!

Uno dei contributi maggiori dati dagli Use Case sta nell'assicurare un elevato allineamento tra i requisiti dettati dagli utenti e le priorità di sviluppo del Software, riducendo al minimo - talvolta azzerando - i cambiamenti dell'ultima ora, spesso responsabili principali degli incrementi di costo e degli allungamenti nei tempi dei progetti, che possono anche raddoppiare senza controllo.

Giusto per dare un esempio di cosa siano gli Use Case a chi non li conosce ancora, supponendo di dover sviluppare una nuova applicazione, se ne descriverà lo scenario ed il contesto di partenza nel quale l'utente si troverà ad operare, riproducendo tutti i passi del processo, sia sul fronte dell'utente che della sua interazione con l'applicazione. In pratica, si elencano gli attori coinvolti nel processo e le azioni che ciascuno di essi è chiamato a svolgere, con tutte le potenziali varianti. In fase di sviluppo si tratterà poi di tradurre queste dinamiche in funzionalità e maschere di interfaccia, avendo sempre ben presente l'obiettivo aziendale che si sta perseguendo.

Gli Use Case Point, come il loro stesso nome fa presumere, derivano pertanto in modo diretto dagli Use Case, analogamente a quanto avvenne per i Function Point che erano strettamente correlati alle funzionalità sviluppate in seguito alle precedenti fasi di determinazione dei requisiti. Si sta quindi agendo a livello più alto nell'ambito del ciclo di vita di sviluppo del Software (ALM - Application LifeCycle Development).

Gli UCP rappresentano il numero delle transazioni eseguite dall'applicazione ed il numero degli attori che vi sono coinvolti operativamente in fase di utilizzo. I valori vanno poi ponderati in base alla complessità tecnica del contesto e dell'applicazione stessa.

I membri di un Team di sviluppo ormai ben abituato all'impiego degli Use Case hanno calcolato gli UCP di 12 loro progetti terminati. In parallelo ed in modo del tutto indipendente, il Project Manager del gruppo, che conosceva bene i contenuti di ciascun progetto, ha calcolato le funzionalità rilasciate in corrispondenza di ciascun progetto.

McKinsey-Migliorare-Sviluppo-Software

Il grafico mostra che tra i due parametri è stata rilevata una grande attinenza di risultati, con valori omogenei nell'80% dei casi, segno che gli UCP possono esser considerati altamente attendibili, ma con un valore nettamente migliore per quanto riguarda le possibilità di comparare i risultati di Team diversi e di correlare quanto realizzato alle effettive esigenze degli utenti e dell'azienda. Il che vuol dire che gli UCP possono esser considerati come un nuovo indice di produttività, legato però al valore del Business e non all'entità degli sforzi prodotti e delle risorse impiegate. 

C'è poi un altro vantaggio da sottolineare: per il calcolo degli UCP non servono né competenze, né strumenti particolari: anche nei casi dei progetti più grandi, la loro misurazione si riduce ad un lavoro completabile in meno di una giornata e svolgibile sin dalle prime fasi dello sviluppo. Ogni successiva variazione di requisiti potrà poi esser facilmente preventivata sia in termini di costi che di effetti sullo sviluppo del progetto.

Infine, dal momento che gli UCP sono collegati agli Use Case e non alle successive metodologie di sviluppo, possono essere impiegati indifferentemente sia nel caso si utilizzino processi standard del passato - o di alcuni attuali contesti - come il Waterfall, sia con le più moderne Metodologie Agili.

Ultima modifica ilMercoledì, 01 Gennaio 2014 13:18

Aggiungi commento


Codice di sicurezza
Aggiorna

Torna in alto