La regola del novanta-novanta in pratica

Il primo 90 percento del codice rappresenta il primo 90 percento dei tempi di sviluppo. Il restante 10 percento del codice rappresenta l'altro 90 percento del tempo di sviluppo.

- Tom Cargill, Bell Labs

Cosa significa esattamente in pratica? Che programmatori svolgono una notevole quantità di lavoro e che stanno dando il 180% di se stessi o?

Immagina così: quando inizi a lavorare sul 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, la funzionalità è tutt'altro che "conclusa", potrebbero esserci bug, piccole modifiche (piccole nelle piccole imprese) e così via. Quindi il software potrebbe sembrare quasi finito (90% fatto), 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 sembri quasi fatto, la quantità di lavoro necessaria per riportare il software in uno stato di funzionamento corretto è grande quanto arrivare a quello stato "quasi fatto". Questo perché la correzione dei bug spesso richiede molto tempo ma non produce molto codice.

Il problema è che la maggior parte degli sviluppatori stima di portare il software nello stato "quasi fatto", perché è relativamente semplice rispetto alla stima dello sforzo totale che il software richiederà.

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

1. Al team viene chiesto di stimare (ovvero indovinare) la quantità di lavoro necessaria per scrivere tutto il codice,
2. Il progetto procede con numerose pressioni interne ed esterne per "rispettare i tempi e il budget",
3. Quindi, per una percentuale significativa del progetto, viene riportato "su target". Questo è spesso aggravato selezionando prima i compiti facili per garantire che siano fatti buoni progressi.
4. Poi ad un certo punto, 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à rinviata (spesso molte volte).

Il "90%" è una cifra arbitraria, ma chiarisce bene: le stime sono ipotesi e probabilmente saranno sbagliate (spesso molto sbagliate) e la natura umana ci assicura quasi sempre sottovalutazione, quindi le cose sono invase.

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

Dopo aver implementato il 90% delle funzionalità, devo ancora implementare l'altro 90% .

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

• lanciare statistiche là fuori quando sono richieste stime ed essenzialmente indovinare ("Ho fatto l'80%")
• concentrarsi sulla complessità algoritmica del codice da scrivere, a scapito del volume di lavoro (sottovalutare lo sforzo richiesto per compiti comuni)
• passi mancanti ("lontano dagli occhi, lontano dal cuore")
• sottovalutare gli sforzi per mantenere e modificare il codice esistente
• sottovalutare lo sforzo richiesto per il codice della caldaia / "colla"

Questa regola integra 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 sviluppo del prodotto dell'80% richiede uno sforzo del 20%.
2. L'80% degli errori è nel 20% del codice.

In pratica, ciò significa quanto segue: lo sviluppo inizierà e proseguirà fino a quando non si noteranno i primi ritardi. I ritardi possono essere di varia natura:

• Scarso controllo di qualità, con conseguenti bug
• Requisiti aggiuntivi che il cliente ha inventato lungo il percorso (e le ragioni di ciò possono anche essere molteplici)
• Requisiti poco chiari dall'inizio, che comportano la caduta di parti dello sviluppo precedente (che potrebbe anche comportare errori di regressione)
• Sottovalutazioni iniziali dovute a scopi poco chiari, errori umani o circostanze non previste. Queste circostanze non previste possono essere foglie malate, dimissioni, guasti hardware o, in casi estremi, eruzioni vulcaniche (una volta abbiamo dovuto ritardare un progetto perché non potevamo volare in loco a causa di un'eruzione vulcanica in Islanda).

In conclusione, è molto più facile avvicinarsi all'obiettivo piuttosto che raggiungerlo.

Trovo la spiegazione di Wikipedia abbastanza illuminante:

Ciò aggiunge fino al 180% in una ironica allusione alla notorietà dei progetti di sviluppo software che supera significativamente i loro programmi (vedere la stima dello sforzo di sviluppo software). Esprime sia l'allocazione approssimativa del tempo a porzioni facili e difficili di un progetto di programmazione sia la causa del ritardo di molti progetti come incapacità di anticipare le parti difficili. In altre parole, ci vuole più tempo e più codice del previsto per far funzionare un progetto.

Cosa significa esattamente in pratica? Che programmatori svolgono una quantità considerevole di lavoro e che stanno dando il 180% di se stessi o?

No, i programmatori svolgono sempre la stessa quantità di lavoro per unità di tempo. La citazione riguarda la sottovalutazione dei costi e dei sovraccarichi. 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ò che ciò significa in pratica è che le persone mentono a se stesse.

Se un programmatore dice "abbiamo finito il 90%" significa che il 90% dello sforzo per costruire le funzionalità è stato speso.

Se un project manager dice "abbiamo finito il 90%, ho solo bisogno che qualcuno lo finisca" significa che hanno il 90% del budget (e probabilmente del 50%). Questo è un cliente senza soldi, alte aspettative e un cattivo atteggiamento.

La differenza è che ci vuole più sforzo delle funzionalità di codifica per completare un progetto: qa, correzioni di bug, copia modifiche, implementazione.

Queste cose devono essere gestite nel progetto e sono di responsabilità del project manager. Ciò sorprende spesso i nuovi PM che si affidano al "90% di funzionalità complete" solo per rendersi conto che sono solo a metà del "progetto concluso".