La Regola del 90-90

La trilogia dedicata al processo di stima dei progetti software (e non solo software) si chiude con l’ultima regola che probabilmente è anche la più cinica verso chi fa del software il proprio lavoro. Se la Legge di Hofstadter lega la difficoltà della stima alla complessità della realtà, se la Legge di Parkinson spiega la difficoltà del rispetto delle stime legandola ad aspetti psicologici sulla gestione del tempo, la Regola 90-90 in maniera umoristica e cinica ci dice che nei progetti software stimare o provare a rispettare le stime è praticamente inutile.

La Regola 90-90 fu ideata nel 1985 da Tom Cargill, un ingegnere dei Bells Labs, ragionando con alcuni colleghi sulla difficoltà di concludere i progetti software, sentenziò la seguente frase:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

ovvero

“Il primo 90% del codice occupa il primo 90% del tempo di sviluppo. Il restante 10% del codice occupa il restante 90% del tempo di sviluppo”.

La frase fu ripresa e resa famosa dalla rivista Comunication of the ACM, nella rubrica “Programming Pearls” del settembre 1985.

Cosa dice sostanzialmente questa regola? Proviamo a leggerla bene. La prima frase sembra piuttosto logica: la codifica del primo 90% del codice occupa il 90% del tempo del progetto. Tutto piuttosto condivisibile. Il cinismo sta nella seconda metà della frase: il restante 10% del codice richiede un tempo pari sempre al 90% del tempo totale del progetto!!!

Questo aforisma, diventato nel tempo una Regola riconosciuta nel mondo del software, pone il focus su due concetti piuttosto pesanti:

• il primo è relativo all’approssimatività con cui vengono effettuate le stime
• il secondo è che questa difficoltà sta sopratutto sulle parti che vengono lasciate alla fine e che sono quelle che irrimediabilmente fanno fallire o andare in ritardo i progetti

Sono entrambi concetti affrontati sia dalla Legge di Hofstadter sia da quella di Parkinson: la realtà è complessa e quindi qualunque stima sarà sottostimata, e la capacità di gestire il tempo porterà inevitabilmente a dover fare delle corse alla fine del tempo. Ma questa regola va anche oltre, perché afferma che non sarà possibile restare nei tempi e soprattutto che le parti finali di un progetto saranno quelle che inevitabilmente ci faranno perdere tanto tempo: il progetto impiegherà il 180% del tempo previsto perché l’ultimo 10% del codice richiederà un tempo enorme per essere reso maturo e funzionante, pronto per essere pubblicato.

I motivi per cui accade ciò, possono essere molto diversi:

• Sono state lasciate per ultime le parti più complesse del progetto
• Le parti realizzate in precedenza non sono mai state integrate, messe in comunicazione fra di loro
• Le parti realizzate non sono mai state testate insieme e presentano molti bug
• Il cliente ha visto il prodotto solo alla fine, evidenziando diverse difformità rispetto ai desiderata
• ecc

Tutte storie di vita vissuta!!! La domanda a questo punto diventa: ma c’è un modo per sfuggire a questa regola? come ci si difende? è una regola non aggirabile?

Considerando che la regola risale al 1985, è chiaro che l’approccio alla pianificazione e alla gestione dei progetti basata sul waterfall, già allora mostrava tutti i suoi limiti e le sue difficoltà. Occorre sicuramente avere approcci diversi per non incorrere nei forti rischi evidenziati da questa regola.

E ovviamente su questi temi, le metodologie agili hanno provato a dare una risposta, introducendo diversi concetti che permettono al team di minimizzare gli effetti della Regola 90-90. Quali sono questi concetti? Limitandosi a Scrum, abbiamo:

1. Definition of Done: permette di definire in maniera sicura e univoca in quali condizioni è possibile considerare completata una funzionalità. Questo permette di evitare il rischio di ritrovarsi alla fine con funzionalità da testare, verificare, ecc…
2. Sprint Review: ad ogni iterazione, alla fine di ogni sprint, il team condivide con il cliente i risultati ottenuti dal progetto, minimizzando così il rischio di incomprensioni con il cliente alla fine del progetto
3. Release Pontentially Shippable: ad ogni sprint, il codice realizzato deve essere potenzialmente pronto al rilascio; questo permette al team di concentrarsi sin dal primo momento sugli aspetti di deploy, integrazione delle funzionalità, consistenza del software
4. Priority: il backlog delle funzionalità del prodotto è ordinato e consumato in odine di priorità; questo permette di concentrarsi sin dall’inizio sulle funzionalità principali e, incaso di ritardi, sarà comunque sempre possibile interrompere il progetto e consegnare al cliente il prodotto con le funzionalità più importanti realizzate fino a quel momento, con la certezza che quelle rimaste sono le meno rilevanti

Si tratta quindi di pratiche che interessano le modalità con cui viene gestito e affrontato il progetto dal team; pratiche che hanno l’obiettivo di minimizzare i rischi del progetto, compreso quello di vedere i costi lievitare e andare fuori controllo rispetto agli obiettivi iniziali.

Dalla prima ideazione della Regola 90-90 sono passati oltre 30 anni, che nell’informatica è più di un’era, ma sono aspetti sempre validi e con i quali occorre confrontarsi continuamente, con il supporto delle giuste pratiche.

Della Regola 90-90 ne esiste anche una seconda definizione fatta da Michael Abrash, storico developer di alcuni giochi come Snack, Quake, Unreal, che in una pubblicazione riporto che:

After you finish the first 90% of a project, you have to finish the other 90%

Il concetto è sempre lo stesso: sul primo 90% del progetto non poniamo un livello di attenzione sufficiente per avere un prodotto maturo per la pubblicazione!

Le altre Leggi alla base dello Sviluppo Software