Quantità di lavoro di routine nello sviluppo di software e relativo effetto sulla stima

Sono convinto che la quantità di lavoro di routine nello sviluppo del software sia - e dovrebbe essere - relativamente piccola, se non trascurabile, e che questo sia il problema fondamentale della stima del software.

Consentitemi di descrivere come giungo a questa conclusione e di dirmi se l'argomentazione presenta qualche grave difetto:

1. Tutto ciò che può essere stimato con elevata precisione è un lavoro di routine, ovvero cose che sono state fatte in precedenza. Tutti gli altri tipi di lavoro che coinvolgono la ricerca e la creatività non possono davvero essere stimati, almeno non con un'accuratezza, diciamo, del +/- 20 percento.

2. Lo sviluppo del software consiste nell'evitare attività ripetitive. Uno dei suoi principi di base è DRY (non ripeterti). Ogni volta che un programmatore si trova a fare cose ripetitive, è tempo di trovare un'astrazione che eviti questa ripetizione. Queste astrazioni possono essere cose semplici come estrarre il codice ripetuto in una funzione o metterlo in un ciclo. Possono anche essere più complessi come la creazione di una lingua specifica del dominio. In ogni caso, la loro attuazione comporterà ricerca (qualcuno l'ha mai fatto prima?) O creatività.

Da questi due punti traggo la conclusione di cui sopra.

In realtà da un po 'mi chiedo perché questa relazione non sia menzionata in ogni altra discussione, post di blog o articolo sulla stima del software. È troppo teorico? I miei presupposti sono sbagliati? O è troppo banale, ma allora perché la maggior parte degli sviluppatori che conosco credono di poter fare stime con una precisione del +/- 20 percento o migliore?

Su ogni singolo progetto questo può essere vero. Tuttavia, se lavori su più progetti simili per diverse aziende nel corso degli anni, potresti ritrovarti a "risolvere" sostanzialmente lo stesso problema molte volte con solo lievi variazioni.

Ad esempio, ho scritto livelli di accesso ai dati così tante volte che ora preferisco farlo "a mano lunga" piuttosto che usare il popolare ORM del mese. È più veloce e più facile per me affrontare i "problemi di routine" con soluzioni note piuttosto che trovare e risolvere nuove stranezze nei componenti di terze parti.

Ovviamente potrei scrivere il mio ORM per semplificare il codice ripetitivo senza aggiungere le stranezze sconosciute nel sistema di qualcun altro, ma questo codice apparterrebbe alla società per cui mi è capitato di lavorare in quel momento, e altri sviluppatori lo troverebbero altrettanto eccentrico come qualsiasi altro ORM di terze parti.

Allo stesso modo, secondo la mia esperienza, la maggior parte della programmazione è l'automazione dei processi aziendali e sebbene ad ogni azienda piaccia pensare che i loro processi siano unici per loro; In realtà non lo sono.

Per non dire che la stima è facile! È più facile, ma trovo che in questi giorni il problema della stima sia dovuto all'inadeguatezza dei requisiti piuttosto che al tempo impiegato per la codifica.

I requisiti tendono a rientrare in tre categorie:

1. Vago, dettagli lasciati allo sviluppatore.

"Fammi un sito Web, deve essere bello e vendere i miei widget"

Questi tendono ad essere i più facili da stimare, poiché quando si verifica un problema grave e imprevisto puoi semplicemente modificare i requisiti in qualcosa di funzionalmente equivalente ed evitare il problema.

2. Molto specifico

"Rendi il colore di sfondo dell'intestazione # ff1100"

Super veloce da fare e, ancora una volta, facile da stimare. Ma! il requisito è destinato a cambiare. "Hmm no su ripensamenti, prova quest'altro rosso" o "Aspetta! Intendevo solo su quella pagina!" quindi il lasso di tempo reale di "quanto tempo resterò soddisfatto del colore dell'intestazione" non ha nulla a che fare con le stime di codifica

3. Vago, dettagli ipotizzati

"Fammi un sito Web, (proprio come Facebook)"

Qui la moltitudine di presupposti non dichiarati, "ovviamente vorrai un logo diverso", "dovrebbe avere uno scorrimento infinito", "deve essere scalabile a 1 miliardo di utenti!" controllare efficacemente il preventivo. O lo sviluppatore pensa a tutto e spinge la stima oltre le aspettative "1 ora di manodopera", oppure pensa / presume che siano necessarie solo le funzionalità di base e fornisca una stima troppo bassa. "oh, una o due settimane, presumo che tu voglia solo mettere Facebook in un iframe giusto?"

Con l'esperienza la codifica è molto veloce, ma i requisiti di progettazione sono (di solito) la parte difficile, e questo è sempre più ricondotto ai non programmatori. Con metodologie agili che aumentano la velocità di codifica spostando questa responsabilità verso "l'azienda" anziché verso gli sviluppatori.

perché la maggior parte degli sviluppatori che conosco ritiene di poter fare stime con una precisione del +/- 20 percento o migliore?

Perché stimiamo la nostra pazienza con il problema molto più del problema reale.

Se avessi intenzione di animare una palla che rimbalzava, potrei passare un giorno, una settimana, un mese o un anno su di essa e avere ancora un'animazione di una palla che rimbalza. Spero che sembrerà migliore più tempo ci trascorro, ma ad un certo punto sono ridicolo.

Quanto sforzo faccio per far rimbalzare la palla è una funzione del tempo che è ragionevole spendere su di essa. Se il mio livello di abilità non lo taglia, potrei finire con una palla che si trova lì. Ma quando arriva la scadenza dovrei lasciar perdere la scadenza o almeno ottenere una palla sullo schermo? La cascata ha insistito sul rimbalzo della palla e quindi il programma è scivolato. Agile dice di portare la palla là fuori. Almeno scopriremo quante persone si preoccupano di rimbalzare. Quindi la qualità è scivolata.

Cerco di far rimbalzare le palle, ma quando la scadenza si avvicina è meglio produrre una palla statica piuttosto che niente. Quindi stima il tempo in base a quello che sembra un ragionevole lasso di tempo da dedicare a un problema prima di parlare di alternative. A volte la palla non rimbalza. A volte va bene. Scomparire per un mese non va bene.