La regola del novantanove in pratica

Immagina che sia così: quando inizi a lavorare su software puoi scrivere enormi quantità di codice in tempi relativamente brevi. Questo nuovo codice può aggiungere enormi quantità di nuove funzionalità. Il problema è che, spesso, che la funzionalità è lungi dall'essere "conclusa", potrebbero esserci bug, piccole modifiche (piccole per le piccole imprese) e così via. Quindi il software potrebbe sembrare quasi finito (90%), perché supporta la maggior parte dei casi d'uso. Ma il software ha ancora bisogno di lavoro. Il punto di questa regola è che, nonostante il software abbia l'impressione che sia quasi terminato, la quantità di lavoro necessaria per portare questo software in uno stato di lavoro corretto è tanto importante quanto arrivare a quello stato "quasi fatto". Questo perché la risoluzione dei bug è spesso dispendiosa in termini di tempo, ma non produce molto codice.

Il problema è che la maggior parte degli sviluppatori stimano l'acquisizione del software in uno stato "quasi fatto", perché è relativamente semplice rispetto alla stima effettiva dello sforzo totale che il software impiegherà.

È un riferimento a uno scenario comune, che purtroppo si verifica ancora oggi:

1. Al team viene chiesto di stimare (cioè di indovinare) la quantità di lavoro necessaria per scrivere tutto il codice,
2. Il progetto procede con numerose pressioni interne ed esterne per "rimanere nei tempi e nel budget",
3. Quindi per una percentuale significativa del progetto, viene riportato "su target". Questo è spesso aggravato selezionando in primo luogo i compiti facili per assicurarsi che siano compiuti buoni progressi.
4. Quindi, in un certo momento, viene raggiunto un punto critico in cui la realtà deve essere accettata: il progetto non sarà completato in tempo e la data di rilascio verrà respinta (spesso molte volte).

"90%" è una cifra arbitraria, ma rende bene il punto: le stime sono supposizioni e probabilmente saranno errate (spesso molto errate) e la natura umana ci assicura quasi sempre di essere sottovalutate, quindi le cose superano.

Ho sentito una versione diversa di questa (chiamata anche "regola 90-90") che va così:

After I have implemented 90% of the functionality, I still have to implement the other 90%.

Entrambe le versioni si riferiscono alla difficoltà di stimare correttamente lo sforzo per lo sviluppo di prodotti software e le insidie comuni a cui le persone tendono a cadere:

• lanciando statistiche là fuori quando sono necessarie stime e essenzialmente indovinando ("Sono 80% fatto")
• concentrarsi sulla complessità algoritmica del codice da scrivere, a scapito del volume di lavoro (sottovalutare lo sforzo richiesto per le attività comuni)
• passaggi mancanti ("fuori dalla vista, lontano dalla mente")
• sottovalutare gli sforzi per il mantenimento e la modifica del codice esistente
• sottovalutare lo sforzo richiesto per il codice boilerplate / "glue"

Questa regola completa la regola 80-20. Ora, ci sono molte diverse interpretazioni della regola 80-20, ma le due che mi piacciono di più sono:

1. Il primo 80% di sviluppo del prodotto richiede il 20% di sforzi.
2. L'80% degli errori si trova nel 20% del codice.

In pratica, questo significa quanto segue: lo sviluppo inizierà e proseguirà fino a un certo punto in cui verranno notati i primi ritardi. I ritardi possono essere di varia natura:

• Controllo di qualità scadente, con conseguenti bug
• Requisiti aggiuntivi che il cliente ha sviluppato lungo il percorso (e i motivi possono essere molteplici)
• Requisiti non chiari sin dall'inizio, che comportano la perdita di parti dello sviluppo precedente (che potrebbero anche portare a bug di regressione)
• Sottovalutazioni iniziali dovute a portata non chiara, errore umano o circostanze imprevedibili. Queste circostanze imprevedibili possono essere foglie malate, dimissioni, guasti hardware o, in casi estremi, eruzioni vulcaniche (una volta abbiamo dovuto ritardare un progetto perché non potevamo volare sul posto a causa di un'eruzione vulcanica in Islanda).

La linea di fondo è che è molto più facile avvicinarsi all'obiettivo piuttosto che raggiungerlo.

Trovo che la spiegazione Wikipedia sia piuttosto illuminante:

This adds up to 180% in a wry allusion to the notoriety of software development projects significantly over-running their schedules (see software development effort estimation). It expresses both the rough allocation of time to easy and hard portions of a programming project and the cause of the lateness of many projects as failure to anticipate the hard parts. In other words, it takes both more time and more coding than expected to make a project work.

What does that exactly mean in practice? That programers do substential amount of work and that they are giving 180% out of themselves or?

No, i programmatori fanno sempre la stessa quantità di lavoro per unità di tempo. La citazione riguarda la sottovalutazione dei costi e dei superamenti. Il 180% è la quantità di tempo e denaro che il progetto finisce per costare.

Significa approssimativamente "Ci vorrà il doppio del tempo che pensi" e "Penserai che stai andando bene fino a quando non è già troppo tardi (la scadenza è vicina)".

Ciò significa in pratica che le persone mentono a se stesse.

Se un programmatore dice "siamo fatti al 90%" significa che il 90% dello sforzo per creare le funzionalità è stato speso.

Se un project manager dice "siamo fatti al 90%, ho solo bisogno che qualcuno lo finisca" significa che sono al 90% attraverso il budget (e probabilmente il 50% fatto). Questo è un cliente senza soldi, grandi aspettative e un cattivo atteggiamento.

La differenza è che è necessario uno sforzo maggiore rispetto alle funzionalità di codifica per completare un progetto: qa, correzioni di bug, correzioni di copia, implementazione.

Queste cose devono essere gestite nel progetto e sono responsabilità del project manager. Questo spesso sorprende i nuovi PM che arrivano fino al "90% di funzioni complete" solo per rendersi conto che sono solo a metà del "progetto fatto".