Quantità di lavoro di routine nello sviluppo del software e il suo effetto sulla stima

Question

Quantità di lavoro di routine nello sviluppo del software e il suo effetto sulla stima

#1 da (11 voti)
#2 da (6 voti)

11

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.

Lasciatemi descrivere come vengo a questa conclusione e dimmi se l'argomentazione ha qualche grave difetto:

Tutto ciò che può essere stimato con alta precisione è un lavoro di routine, ovvero cose che sono state fatte prima. Tutti gli altri tipi di lavoro che coinvolgono ricerca e creatività non possono essere stimati, almeno non con una precisione di, diciamo, +/- 20 percento.
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, è il momento di trovare un'astrazione che eviti questa ripetizione. Queste astrazioni possono essere semplici cose come estrarre il codice ripetuto in una funzione o metterlo in un ciclo. Possono anche essere più complessi come creare un linguaggio specifico di dominio. In ogni caso, la loro implementazione comporterà ricerche (qualcuno l'ha già fatto prima?) O creatività.

Da questi due punti traggo la conclusione sopra.

In realtà mi sono chiesto per un po 'perché questa relazione non è menzionata in ogni altra discussione, post di blog o articolo sulla stima del software. È troppo teorico? Le mie supposizioni sono sbagliate? O è troppo banale? Ma allora, perché la maggior parte degli sviluppatori che conosco crede di poter fare stime con un'accuratezza del +/- 20 percento o migliore?

development-process estimation

posta Frank Puffer 14.08.2016 - 12:41

fonte

2 risposte

Leggi altre domande sui tag development-process estimation

Linguaggi di programmazione non in inglese [chiuso] Perché la storia di MS Data Access è così frammentata? È la natura dell'accesso ai dati o è solo MS?

score 11 · Answer 1

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

Ad esempio, ho scritto i livelli di accesso ai dati così tante volte che ora preferisco farlo 'a mano lunga' piuttosto che usare l'ORM popolare del mese. È più facile e veloce per me gestire i "problemi di routine" con soluzioni note piuttosto che trovare e risolvere nuovi problemi in 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 sarebbe appartenuto alla società per cui stavo lavorando per quel momento, e altri sviluppatori lo avrebbero trovato solo come eccentrico come qualsiasi altro ORM di terze parti.

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

Non dire che la stima è facile! È più facile, ma trovo che in questi giorni il problema di stima sia dovuto all'insufficienza dei requisiti piuttosto che alla codifica del tempo trascorso.

I requisiti tendono a ricadere in tre categorie:

Vago, dettagli lasciati allo sviluppatore.

"Make me a website, it has to be cool and sell my widgets"

Questi tendono ad essere i più facili da stimare, poiché quando si verifica un problema inaspettato si può semplicemente cambiare i requisiti in qualcosa di equivalente dal punto di vista funzionale ed evitare il problema.

Molto specifico

"Make the header background colour #ff1100"

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

Vago, dettagli ipotizzati

"Make me a website, (just like facebook)"

Qui la moltitudine di ipotesi non dichiarate, "ovviamente vorrai un logo diverso", "dovrebbe avere uno scorrimento infinito", "deve essere scalabile fino a 1 miliardo di utenti!" controllare efficacemente la stima. O l'ingegnere pensa a tutto e spinge la stima oltre le aspettative "1 ora di punta", o pensa a / presuppone solo che le caratteristiche di base sono obbligatorie e danno una stima troppo bassa. "oh una settimana o due, presumo tu voglia solo mettere facebook in un iframe giusto?"

Con la codifica dell'esperienza è molto veloce, ma i requisiti di progettazione sono (di solito) il duro, e questo è sempre più spinto indietro ai non-programmatori. Con metodologie agili che aumentano la velocità di codifica trasferendo questa responsabilità al "business" piuttosto che agli sviluppatori.

score 6 · Answer 2

why do most developers I know believe that they can do estimates with an accuracy of +/- 20 percent or better?

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

Se ho intenzione di animare una palla che rimbalza, potrei passare un giorno, una settimana, un mese o un anno e ancora solo avere un'animazione di una palla che rimbalza. Spero che sembrerà migliore più tempo passerò su di esso, ma a un certo punto sono ridicolo.

Quanta fatica ho messo nel far rimbalzare la palla è una funzione del tempo che è ragionevole spenderci. Se il mio livello di abilità non sta tagliando, potrei finire con una palla che si trova proprio lì. Ma quando arriva la scadenza dovrei lasciare che la scadenza scivoli o almeno ottenere una palla sullo schermo? Cascata ha insistito sul rimbalzo della palla e quindi il programma è scivolato. Agile dice che tiri fuori la palla. Almeno scopriremo quante persone si preoccupano di rimbalzare. Quindi la qualità è scivolata.

Cerco di essere sicuro che le mie palle rimbalzino, ma quando arriva la scadenza è meglio produrre una palla statica che niente. Quindi valuto il tempo in base a ciò che sembra una ragionevole quantità di tempo da dedicare a un problema prima di parlare di alternative. A volte la palla non ha intenzione di rimbalzare. A volte va bene. Scomparire per un mese non è OK.