Perché stiamo comunque facendo la stima del software sapendo che è rotto? [duplicare]

Anche una stima molto imprecisa è ancora meglio di nessuna.

Non fare assolutamente alcuna stima significherebbe sostanzialmente dire al management "qualunque cosa tu voglia programmare, non ho idea, potrebbero volerci anni e costare miliardi", che in termini commerciali significa "nessuna programmazione dovrebbe essere fatta".

Il modo corretto di gestire l'imprecisione nella stima è di tenerlo aggiornato e aggiornare i piani ogni volta che si ottengono nuove informazioni dopo l'avvio dello sviluppo - man mano che il progetto procede, le stime per il lavoro rimanente diventeranno più accurate nel tempo.

Rimuovere le scadenze dal processo di sviluppo non è una soluzione, perché le scadenze esatte sono esigenze aziendali.

Un progetto software è più della semplice parte di sviluppo. Marketing, vendite, amministrazione del sistema, supporto, formazione degli utenti, ecc. Richiedono tutti una data di rilascio prefissata in modo che possano pianificare di conseguenza la loro parte del progetto. Naturalmente sarebbe meglio da una prospettiva di sviluppo pura dire semplicemente "è finito quando è finito" e non rilasciare fino a quando tutte le funzionalità non funzionino fino alle specifiche e tutti i bug saranno schiacciati. Ma non è possibile pianificare un progetto su questa base. Devi avere un programma in modo da poterti coordinare correttamente tra gli altri partecipanti al progetto, o loro inizieranno a diventare inefficienti e il progetto fallirà perché loro non hanno le capacità quando ne hai bisogno.

Quindi la vera soluzione al problema non è cercare di inventare un processo che non ha scadenze. La vera soluzione è ottimizzare i nostri metodi di stima del tempo in modo da poter trovare scadenze più realistiche e modificare i nostri processi di sviluppo, in modo che lo notiamo presto quando una scadenza non può essere soddisfatta. Ci sono molti approcci a questo e finora non abbiamo trovato quello che funziona meglio - ma stiamo ancora provando.

La stima ha diversi scopi. Uno è "quando può essere completato questo progetto", ma almeno altrettanto importante è la stima come strumento per la decisione e l'allocazione delle risorse.

Supponiamo che il tuo capo decida i tempi di risposta in un'app web e che qualcuno suggerisca di riscrivere l'app in C ++ come opzione. Basta saltare nella porta C ++ senza alcuna stima sarebbe un disastro. Una semplice stima del costo rispetto al vantaggio avrà un grande valore aziendale in quanto potrebbe essere paragonata ad altri potenziali miglioramenti come l'implementazione del caching di output. In questo caso, anche una stima estremamente approssimativa è molto meglio di nessuna stima.

Senza dubbio le stime sono difficili, ma ottengono anche una reputazione peggiore a causa di problemi che non hanno nulla a che fare con la stima stessa.

Per prima cosa, non dovresti confondere stima e programmazione. Le stime stimano la quantità di tempo necessaria per risolvere un compito. Trasformare una stima in date è una questione di pianificazione e questo può essere influenzato da condizioni esterne. Ad esempio, a uno sviluppatore potrebbe essere assegnato di dedicare parte del suo tempo a un altro progetto, e questo ovviamente influirà sul programma, anche se la stima è la stessa. Un piano di progetto ovviamente scivolerà se il project manager dimenticherà di includere le festività, le persone che prendono l'influenza, ecc., Nel programma, ma ciò non significa che la stima sia stata negativa.

Inoltre, le modifiche apportate all'ambito durante lo sviluppo influiranno sulla pianificazione. Il cambiamento dell'oscilloscopio è un evento naturale man mano che si impara di più (sebbene lo scorrimento incontrollato dello scope sia pericoloso), ma ovviamente le stime dovranno essere aggiornate se l'ambito cambia, poiché ora si sta facendo un progetto diverso da quello stimato. Di nuovo, ciò non significa che la stima originale fosse cattiva o inutile.

Inoltre, dovresti essere consapevole del fatto che la quantità di lavoro inserita nel processo di stima influirà sulla qualità del risultato. Vi è una grande differenza tra una stima immediata e una stima dettagliata con le specifiche dei requisiti dettagliate suddivise in punti funzione e attività secondarie specificate alla granularità di alcune ore. Ovviamente maggiore è il lavoro, migliore è la stima, ma è di per sé una decisione in termini di costi / benefici.

Vedi "Cono di incertezza", un concetto utile che mi ha aiutato più di una volta.

link di Wikipedia "Cono di incertezza"

Il software non è solo "Sviluppo", include pre-vendita, vendite e gestione e molti altri.

In generale, le stime vengono utilizzate per inserire prezzi o costi in progetti Softwate (sia che si tratti di costi con allocazione di resourse, o del prezzo da addebitare a una società esterna).

Quando è solo un costo, è anche conoscere l'allocazione delle risorse, quanti giorni abbiamo bisogno di X persona. Quanti giorni abbiamo bisogno di qualcuno con il profilo Y, ecc.

Quando si tratta di prezzo, si tratta di margini di profitto e rischi attenuanti.

Quando non è di quelli, forse è solo una data per fare un annuncio. L'azienda ha bisogno che alcune date siano impostate come scadenze.

Per chiudere, il problema principale con le stime è quando non vengono trattati come sono. Sono fondamentalmente le nostre aspettative su ciò che verrà raggiunto. E l'Aspettativa dovrebbe anche essere descritta con una incertezza , ad esempio, credo che sviluppando la funzionalità X, supponendo che Y e Z siano vere, forse con un 20% di certezza.