Introduzione

In questo articolo accennerò ad alcuni aspetti dello “stato dell'arte” nel campo della stima dei tempi necessari per lo sviluppo del software e concluderò con un semplice metodo che ho introdotto in Kiwifarm per contenere questo annoso problema.

Qualche cenno dalla letteratura

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Tom Cargill, Bell Labs (Ninety-ninety rule)

Come sa chiunque svolga questa professione, stimare correttamente il tempo necessario per lo sviluppo di un software è molto difficile e questa difficoltà cresce con le dimensioni del progetto perché si fa sentire l'effetto più che proporzionale dato dalla somma di diversi fattori, quali per esempio:

1. i requisiti raccolti, che praticamente sempre ricadono in quattro grandi famiglie: incompleti, inutili, errati e contraddittori;
2. vari fattori umani come pensiero illusorio, anchoring, planning fallacy e dissonanze cognitive, per non parlare di faziosità volontarie, pressioni del “commerciale”, malafede del committente e altro ancora.

Partendo quindi dall'immancabile pagina Software development effort estimation di Wikipedia e sorvolando sulla descrizione dei vari metodi formali, si possono estrarre alcuni dati interessanti:

• pur essendo complesso raccogliere scientificamente informazioni in questo campo, sembra che gli sviluppi software vengano mediamente sottostimati del 30% e che questa percentuale non si riduca con il tempo;
• in media, se un esperto di sviluppo software è sicuro al 90% di aver incluso la stima del lavoro necessario all'interno di un intervallo “minimo-massimo”, la frequenza rilevata di reale inclusione è solamente del 60-70%;
• i metodi di stima si suddividono principalmente in basati sull'esperienza e sui formalismi: tra gli appartenenti al primo gruppo, il più recente tra i metodi citati nella pagina è il Planning Poker o “Scrum Poker” e ne suggerisco l'approfondimento al lettore;
• la combinazione di più metodi di stima migliora mediamente la qualità della stima stessa: il problema è che spesso non c'è il tempo per una così raffinata analisi preliminare dei requisiti.

Come osservano Magne Jørgensen e Stein Grimstad in The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates: A Randomized Controlled Field Experiment:

It's easy to estimate what you know.
It's hard to estimate what you know you don't know. (known unknowns)
It's very hard to estimate things that you don't know you don't know. (unknown unknowns)

Nel nostro piccolo

“Ocean waves rippling at Kavourotrypes Beach” di Anastasia Taioglou / Unsplash

Nei colossali progetti aerospaziali o militari, ambiti nei quali ha proposperato a lungo il vecchio modello Waterfall, la fase di stima dei tempi necessari per degli sviluppi software così mastodontici e dirigistici poteva tranquillamente durare anni-uomo.

In Kiwifarm, gli sviluppi software per i quali ci viene chiesta una stima non sono neanche lontanamente simili a quegli scenari, né per dimensioni del progetto, né per quantità di informazioni o tempo a nostra disposizione: tipicamente, si tratta di progetti equivalenti ad alcuni mesi-uomo o, più raramente, a pochi anni-uomo, quindi la stima deve essere elaborata in una manciata di ore. Inoltre, spesso il cliente non è un informatico e questo significa che, pur potendo essere nel suo campo persino un autentico scienziato, non di rado ritiene che stimare il tempo per lo sviluppo di un software personalizzato sia di una complessità paragonabile a quella necessaria per valutare un tappeto in un Suq (سوق), trattativa sul prezzo inclusa. 😃

Il mio contributo

In Kiwifarm ho introdotto quindi un semplice metodo empirico con miglioramento in retroazione, come direbbe un ingegnere “controllista”. 😃

Quotidianamente, ogni sviluppatore, per ciascun progetto, registra in un archivio collettivo le ore dedicate: al termine del progetto, la differenza di ore tra quelle preventivate e consuntivate andrà a modificare una percentuale di correzione relativa a tutti i progetti degli ultimi tre anni. Questa media mobile verrà applicata - per i progetti futuri - come fattore correttivo nelle stime, a valle sia della stima netta che di un precedente fattore di correzione per il project management.

Utilizzando una formula in pseudocodice, potremmo riassumere in:

giorniProssimaStima =
    giorniStimati *
    (1 + percentualeProjectManagement) *
    (1 + percentualeCorrezioneMediaMobileSu3Anni)

Le vere giornate

Un altro importante fattore da considerare oltre al tempo di effort è il tempo di calendario: per lavorare otto ore al giorno su di un progetto, ne dovrai lavorare dodici e anche se ne lavorerai dodici, non riuscirai a lavorarne otto 😃 perché, dovendo gestire molti progetti in parallelo, si viene inevitabilmente interrotti e, inoltre, ci sono attività non produttive e non comprimibili. Considerare le persone “full time” su di un progetto fa parte di una gestione tanto ingenua quanto obsoleta, più verosimile forse alla fine del 19esimo secolo che all'inizio del 21esimo.

Vorrei ricordare al lettore due importanti invenzioni del 1896 (avete letto bene: mille ottocento novanta sei):

• il Quadriciclo Ford (la prima automobile sperimentale costruita da Henry Ford);
• il diagramma Gantt.

Per la carità: belli i motori endotermici e la pianificazione rigida ma negli ultimi centoventidue anni magari è uscito anche altro. 😃

In queste fotografie, assemblate dalle summenzionate pagine Wikipedia, ho voluto affiancare quelli che - per purtroppo ancora troppe aziende contemporanee ma guidate da “teste” saldamente ibernate alla seconda rivoluzione industriale - sono i più brillanti e attuali strumenti a disposizione. 😃

Conclusioni

Fotografia di aquachara su Unsplash

Puoi essere il miglior Project Manager “Waterfall” vivente ma se la tua azienda ha stimato male i tempi di sviluppo del software che ha poi venduto a preventivo, il risultato non potrà che essere l'evento più comune in questo campo: la consegna in ritardo, spesso accompagnata dalla variazione al ribasso dei requisiti e della ridotta qualità sia del codice che della vita degli sviluppatori, il tutto senza aver migliorato particolarmente la soddisfazione del cliente, per non parlare dell'abbassamento della redditività oraria del personale impiegato. Ne vale la pena? Certamente no ma vuoi per ignoranza, vuoi per i rapporti alla base della tipica mentalità di questa nostra epoca, il tutto avviene fin troppo frequentemente e un semplice metodo di correzione degli errori “in catena chiusa” può essere un primo modo tanto semplice quanto efficace per ridurre questo rischio.

--

Fotografia di copertina “Cause they’ve been swimming in the wrong waters. Now they’re pulling me down.” di Nikko Macaspac su Unsplash.