Autore: Steve McConnell (Construx)
Editore: Microsoft Press
ISBN: 0735605351
Pagine: 308
Lingua: Inglese
Anno: 2006
Categoria: Stime Software, Best Practices
Online: Safari BOL - Gorilla – Amazon

In questo libro Steve McConnell (per chi non lo conoscesse, si tratta di uno degli scrittori più autorevoli del settore, tanto da essere stato nominato dai lettori del magazine “Software Development” nel 1998 una delle persone più influenti nell’industria del software, insieme a Bill Gates e Linus Torvalds) parla delle tecniche per migliorare l’affidabilità delle stime sui tempi di sviluppo dei software, un argomento molto delicato dato che sulla base di esse, in genere, vengono presentate le offerte ai clienti (ed è quindi collegato direttamente con i fatturati della ditta), ma che spesso viene affrontato con troppa superficialità, adottando metodi non ottimali, se non addirittura basandosi sull’intuito.

Nell’introduzione, la cui lettura è consigliata in quanto riassume molto bene gli obiettivi del libro, l’autore spiega che ci sono due approcci per poter effettuare le stime del software: quello scientifico, utilizzato dalle organizzazioni che vogliono contenere i margini di errore delle stime entro il 5-10% e/o trattano progetti di grandi dimensioni (oltre 1.000.000 di linee di codice), e che per ottenere ciò debbono ricorrere a complessi sistemi matematici, ed il metodo dell’”arte della stima”, costituito da molte regole pratiche, suggerimenti e tecniche alla portata anche di chi non ha una laurea in matematica o non esegue stime come professione principale, e che si adatta a tutte le ditte che in genere cercano di ridurre il più possibile un margine di errore che, altrimenti, potrebbe essere facilmente superiore al 50-100%.

Come si evince dal titolo, l’autore utilizza l’approccio dell’”arte della stima”, creando un testo di riferimento che si adatta comunque alle esigenze della maggior parte delle organizzazioni, in cui in genere non ci si affida a persone che svolgono come professione principale quelle di stimatori, e che non di rado si ritrovano ad affrontare situazioni non piacevoli a causa di stime errate.

Grazie alla presenza di molti riferimenti ad altri testi che trattano delle tecniche in modo più approfondito, il libro rappresenta comunque un ottimo punto di partenza anche a chi poi vorrà trattare il tema seguendo metodi più scientifici.

Data inoltre la natura dell’argomento, che non riguarda solamente i tecnici (sviluppatori, ...) ma anche gli executive (commerciali, manager, capi-progetto…) ed il cliente finale, l’autore ha adottato un taglio molto pratico, in modo da dare la possibilità anche a queste categorie di poter leggere il libro; ad esempio, sono presenti molti suggerimenti e regole pratiche (ben 118), messi in evidenza e riepilogati alla fine del testo, contro solo 18 formule matematiche, concentrate in poche delle tecniche analizzate; inoltre, il testo è di breve - media lunghezza (circa 250 pag. effettive), se paragonato con la norma dei testi del settore informatico di 800-1000 pag.

L’unica pecca può essere rappresentata dalla mancanza (almeno al momento della scrittura di questa recensione) di una versione in lingua italiana, cosa che sarebbe gradita a persone non tecniche, in genere poco inclini ad affrontare una lettura in lingua inglese.

Il testo è suddiviso principalmente in tre parti; nella prima si viene introdotti nella tematica delle stime sul software, illustrando vari termini come stima, target e commitment, che spesso vengono confusi dai soggetti coinvolti, ottenendo dei conflitti che potrebbero essere risolti molto più facilmente avendo ben chiare le loro differenze (tra l’altro, l’autore dimostrerà che il significato di stima nel mondo del software è ben diverso da quello classico, da dizionario).

Sono poi indicati i motivi per cui è utile una stima corretta (nonché la differenza tra una stima precisa ed una accurata) e quali sono le conseguenze di progetti sovrastimati e sottostimati (vedi anche la Legge di Parkinson e la “Sindrome dello Studente” di Goldratt a riguardo), dimostrando che un grosso ruolo è giocato dai fattori psicologici, più che da quelli matematici.

Sono inoltre illustrati i vari fattori che influenzano le stime (tecnologia usata, impiego di processi di sviluppo sequenziali o agili, composizione del team,…) e le cause che possono portare a degli errori, indotte sia dall’ambiente circostante a chi le effettua, sia interne al soggetto stesso, come i pregiudizi o il basarsi su convinzioni errate, oppure dal non considerare nella stima attività come il deploy dei programmi, che comunque qualcuno dovrà effettuare ad un certo costo.

Per un assaggio, in questo sito è presente un “particolare” test tratto dal secondo capitolo, che dimostra l’influenza di alcuni fattori psicologici sui risultati delle stime: test e risultati.

La seconda parte del libro illustra molte tecniche per ottenere delle stime migliori, e per ognuna di esse viene indicato:

• l’obiettivo della stima (si può voler stimare la grandezza del progetto, il numero di features che possono essere consegnate entro una certa data, i mesi che occorrono per lo sviluppo,…)
• la categoria di grandezza del software per cui è applicabile (piccolo, medio, grande)
• in quale step delle attività è applicabile la tecnica (es. all’inizio della pianificazione o in uno stato medio - avanzato dello sviluppo, in questo caso la tecnica può essere utilizzata per verificare se la stima iniziale è ancora corretta)
• se utilizzabile con metodologie sequenziali o iterative (agili)
• il livello di accuratezza che ci si può attendere da quella particolare tecnica.
• Le tipologie di tecniche sono molto varie, alcune sono dei semplici accorgimenti che possono comunque migliorare il lavoro di chi effettua la stima (magari a livello intuitivo alcune vengono utilizzate senza sapere della loro esistenza, come la T-Shirt sizing), altre sono più complesse e possono richiedere la collaborazione di più persone all’interno della ditta (es. quelle che poi andranno effettivamente a sviluppare il software), di dati storici prelevati dai precedenti progetti o di tool appositi, come quello offerto gratuitamente dalla ditta dell’autore, Construx Estimate.

L’autore espone anche la sua opinione (molto interessante) riguardo l’utilizzo di tecniche controverse, come il conteggio delle righe di codice, oppure sulla diatriba riguardante l’impiego di più persone all’interno del team di sviluppo in modo tale da velocizzare lo sviluppo del software.

Infine, nella terza parte, ed in particolar modo negli ultimi due capitoli, il discorso si concentra sul rapporto tra i vari soggetti, in particolar modo tra chi ha effettuato le stime, gli executive ed il cliente finale: ad esempio, vengono illustrate varie tecniche per presentare i risultati delle stime in modo comprensivo anche per chi non è un tecnico, e sono discussi i punti di vista delle varie parti in causa, in modo tale da farle dialogare al meglio tra loro. In particolare, a riguardo, l’autore indica di vedere questa fase non come una negoziazione in cui un soggetto vince e l’altro perde (non c’è nessuna torta da spartirsi), bensì come un dialogo in cui le parti stanno tutte nello stesso tavolo, e vincono o perdono insieme (ed in questo, McConnell indica esplicitamente di aver cambiato opinione rispetto a quanto affermò in un suo precedente libro, “Rapid Development”).

In conclusione, si tratta sicuramente di un libro molto interessante da leggere, in particolare per chi non ha mai letto testi dello stesso genere, ed in questo caso aiuta a mettere in chiaro anche certi concetti di cui magari si intuiva la natura, ma che non sono stati mai approfonditi.

Oltre ai soggetti che si occupano della parte tecnica, la lettura di un testo su questo argomento dovrebbe essere “obbligatoria” anche per gli executive, ai quali spettano molte responsabilità e possono essere causa di errori molto gravi dovuti anche a comportamenti superficiali e facilmente evitabili.

Anche se, molto probabilmente, a causa della particolare natura dell’argomento delle stime software, nessuna delle tecniche sarà illuminante e definitiva (anzi, l’autore consiglia in genere di adottarne più di una nello stesso progetto, in modo tale da vedere se i risultati convergono o meno), in generale il testo saprà dare una maggiore sicurezza su questi temi e consapevolezza su ciò che può portare a commettere errori che saranno poi pagati a caro prezzo.