Perché i programmi software sono così difficili da definire?

Se stai sfornando un progetto quasi identico ad altri progetti che hai fatto, utilizzando strumenti familiari e un team familiare, e ti vengono forniti requisiti scritti e rigorosi, allora dovrebbe essere possibile fare una buona stima.

Queste sono le condizioni che regolarmente pittori, installatori di tappeti, paesaggisti, ecc. Ma non è adatto per molti (o molti) progetti software.

Spesso ci viene chiesto di stimare progetti che utilizzano nuovi strumenti, tecnologie, dove i requisiti stanno cambiando, ecc. Questa è più estrapolazione verso l'ignoto dell'interpolazione rispetto alle nostre esperienze passate. Quindi è naturale che la stima sia più difficile.

Secondo la mia esperienza personale, è esattamente l'opposto di ciò che Pemdas ha detto : con la pratica, ho appena capito che è assolutamente impossibile stimare quanto tempo richiederà un'attività. All'inizio della mia carriera nello sviluppo di software, ho dato spesso stime come "45 giorni", "cinque settimane", ecc., Quindi ho provato molto duramente a finire in tempo. Qualche anno dopo, ho iniziato a dare stime meno precise come "circa un mese", "da cinque a sette settimane", ecc. In realtà, provo a non dare alcuna stima, o chiedo al cliente di dare la sua stima o scadenza o fornisco una stima il più approssimativa possibile.

Perché è così difficile avere un preventivo? Perché è quasi impossibile sapere come verrà scritto l'intero codice sorgente prima di scriverlo effettivamente, e perché il tuo lavoro dipende da cose casuali come altri popoli lavorano, la tua motivazione, ecc. Ecco un elenco più dettagliato dei possibili motivi:

1. Non è facile sapere che cosa è esattamente richiesto per fare un prodotto, specialmente come per farlo . Molto spesso ho iniziato alcune parti di un'applicazione, che, dopo giorni di lavoro, ho capito che il mio primo approccio era sbagliato e che c'è un modo migliore e più intelligente di fare le cose.

2. Potrebbero verificarsi alcuni problemi . Ad esempio, se, per iniziare il tuo lavoro, devi installare sul tuo computer un server SQL elegante e l'installazione fallisce e il supporto non esiste, potresti passare settimane a risolvere il problema.

3. I requisiti spesso non sono abbastanza chiari , ma dopo averli letti all'inizio, pensi che lo siano. A volte puoi capire che la media 'A' e, dopo aver iniziato ad implementarli, ti accorgerai che potrebbero significare 'B'.

4. I clienti amano cambiare le loro esigenze esattamente quando hai appena finito la parte interessata , e in realtà non capiscono perché richiedi altre due settimane e $ 2000 per fare un tiny cambia, perché non vedono che questo minuscolo cambiamento richiede di cambiare altre cose, che richiedono di cambiare gli altri, ecc.

5. Non puoi stimare la tua motivazione . Ci sono giorni in cui puoi lavorare per ore e avere successo. Ci sono settimane in cui, dopo aver scritto dieci righe di codice, passi a Programmers StackExchange e trascorri ore a leggere e rispondere alle domande.

6. Le cose peggiorano quando la tua stima dipende da altre persone . Ad esempio, in un progetto di 2 mesi ho dovuto aspettare che un designer facesse il suo lavoro per finire il mio. Questo designer ha impiegato 3 mesi prima di consegnare un pezzo di merda inutilizzabile. Ovviamente il progetto era in ritardo.

7. Il tuo preventivo dipende anche dal tuo cliente . Ho avuto clienti che passano settimane prima di rispondere alla loro posta. Può davvero influenzare il tuo programma quando devi aspettare la risposta (ad esempio se chiedi loro di specificare un requisito).

Che cosa puoi fare?

1. Fornisci una pianificazione più ampia . Se pensi di poter fare il lavoro in due settimane, dì che lo consegnerai in un mese.

2. Sii chiaro . Se ti affidi a un designer, a un altro sviluppatore, ecc., Dillo. Invece di dire "consegnerò il prodotto in tre mesi", dì "consegnerò il prodotto entro due mesi dal momento in cui il progettista mi fornirà i file PSD".

3. Spiega che se i requisiti cambiano ogni giorno, il progetto sarà difficilmente consegnato in tempo.

4. Taglia la tua pianificazione . Fornire parti di un grande progetto in tempo è più facile.

5. Non dare mai una stima quando si utilizza un prodotto che non si conosce bene o, soprattutto, quando si lavora su un codice sorgente di qualcun altro: non si può mai prevedere quanto può essere schifoso il codice sorgente e come molto tempo trascorrerai a comprenderlo e copiarlo in copia su The Daily WTF.

Una domanda molto simile è "Quanto ci vorrà per risolvere questo cruciverba?"

Non puoi rispondere a questo finché non lo hai visto per vedere numerose cose come:

• È in una lingua familiare? (Spagnolo contro inglese contro cinese)
• È uno di un tipo che abbiamo già risolto? (Uno di una serie in esecuzione in una rivista, ad es.)
• Qualche lead richiede conoscenze aggiuntive prima ancora che possiamo capirlo?
• Esiste da qualche parte nelle cose puzzle che, per tua conoscenza, richiederà un lavoro aggiuntivo?

Dato che di solito ci sono parecchie cose nuove in un progetto (altrimenti non sarebbe un progetto) non puoi dire quanto tempo impiegheranno a risolverlo finché non le avrai guardate con attenzione. Forse risolvono anche più o meno o loro, e quindi non sei ancora sicuro che non ci sia una sorpresa o due in cui non hai pensato a loro.

C'è anche una strong pressione per farlo nel modo più economico possibile, quindi il più rapidamente possibile e la colpa di una stima troppo bassa non va sul pressurizzatore del project manager ma lo sviluppatore fornisce la stima. Non ci vogliono molte iterazioni per lo sviluppatore per cogliere questo, e imparare a essere MOLTO stanco di dare numeri assoluti.

The most obvious reason why you engineers can't give you accurate estimates is that it's impossible.

Ovviamente puoi stimare quanto tempo +2 ci vorranno dalla tua casa al lavoro. Sai come guidare una macchina, puoi valutare il traffico e altri fattori esterni.

Dimmi quanto tempo ti ci vorrà per guidare da Londra a Barcellona. Senza strumenti di pianificazione GPS avanzati, ovviamente. Usando il buon vecchio metodo come facciamo ancora nella stima del software. Stima empirica e previsioni .

Nel software, è peggio:

1. Le stime spesso diventano un impegno , quindi il nostro giudizio viene modificato.
2. Ci possono essere enormi differenze tra la stima di Bob e Karl per lo stesso compito.
3. Le incertezze sono molto comuni, quanti di noi rimangono bloccati su uno stupido bug o un crash del disco rigido che distrugge qualsiasi apparente buona stima.
4. Di solito dimentichiamo tutte le altre attività rispetto alla programmazione, tra cui riunioni, telefonate, assistenza al nostro collega, ecc.
5. Il cervello umano è limitato . Non è stato progettato per stimare attività a lungo termine.

Ecco perché è impossibile dire al tuo cliente che cosa sarà in grado di spedire per il 02/01/2011 con buona precisione, e dimenticarsi del 03/01/2011.

Per risolvere tutti questi problemi, ti consiglio tecniche di stima avanzate come Pianificazione del poker (disclaimer: questo è uno dei miei siti web) e Sviluppo iterativo con Velocity calcolo.

• I primi due problemi vengono affrontati utilizzando Planning Poker. Le stime sono collettive e la squadra le possiede piuttosto che individui.
• Gli ultimi terzi problemi vengono affrontati utilizzando Velocity e lo sviluppo iterativo. Conoscendo la tua velocità (il fattore da applicare alle tue stime basate sulla cronologia), puoi pianificare le versioni con maggiore sicurezza. Lo sviluppo iterativo, quando ben fatto, porta in primo piano le funzionalità più importanti e ti aiuta a fornire valore ai tuoi utenti in anticipo.

Lo sviluppo del software è - per definizione - un atto di scoperta e invenzione. Deve sempre coinvolgere qualcosa di sconosciuto.

L'unica volta che tutto ciò che riguarda lo sviluppo del software è noto quando il software è completo.

L'unica volta che non ci sono tecnologie sconosciute o funzionalità aziendali è quando è una soluzione completa e pacchettizzata pronta per il download.

Il motivo per cui scriviamo nuovo software è perché abbiamo una nuova funzione o una nuova tecnologia o entrambi. Nuovo significa nuovo - sconosciuto - imprevedibile.

Poiché lo sviluppo del software deve coinvolgere novità, lo sforzo di sviluppo non può essere previsto.

Onestamente, penso che ci voglia solo pratica. Se scrivi abbastanza codice alla fine dovresti essere "abbastanza" preciso. Il mio primo capo riteneva che questa abilità fosse abbastanza importante da richiedere che lo praticassi in modo informale su ogni funzione / progetto che ho implementato. Dopo ogni progetto abbiamo rivisto le stime e abbiamo cercato di capire dove ho sbagliato. Alla fine, hai capito bene.

Non è mai facile. Cerchi solo di migliorare.

Uno dei vantaggi di suddividere il codice consegnabile in parti più piccole, è che i clienti possano capire cosa aspettarsi e quando aspettarselo. Ora hai una sorta di linea di base da usare come riferimento.

Se hanno una definizione rigorosa di una funzionalità di cui hanno bisogno in un determinato periodo, devono sapere che risorse aggiuntive devono essere assegnate a questa richiesta. Stanno prendendo un rischio nella gravità dei bug che si verificano e quanto tempo possono andare senza che vengano corretti. Quando qualcosa di importante viene fuori, si torna al cliente e li forza in una decisione. Correggo il bug o faccio la scadenza sulla nuova funzione? Dare loro abbastanza informazioni per prendere una decisione informata.

Spero che tu abbia abbastanza storia di lavorare insieme e ti sia stabilito abbastanza da essere considerato affidabile. Non puoi aspettarti che comprendano appieno il processo di sviluppo, ma puoi farli sentire che stai facendo uno sforzo onesto e non approfittando della loro mancanza di conoscenza.

Perché facciamo il programma troppo presto. Vedi l'articolo di Construx su come fare un preliminare approssimativo, poi meglio uno dopo. Inoltre, se non si tiene traccia delle proprie stime precedenti, è difficile migliorare. FogBugz lo fa [un cliente di quello gratuito, nessun altro conflitto di interessi].

Ho imparato molto da questo libro:

Stima del software: Demistificazione della Black Art

In breve, per ottenere risultati di stima migliori, facciamo ciò:

1. tutti i compiti tranne banali sono stimati da più di una persona (due nel nostro caso)
2. dividiamo le attività in compiti più piccoli. Più compiti hai, più è probabile che la tua stima sia buona - legge di grandi numeri se ricordo bene dal boo
3. stimiamo lo scenario peggiore, migliore e più probabile. A volte ognuno di noi valuta questi scenari di alberi in modo completamente diverso. Ciò significa che dobbiamo parlare e di solito si scopre che uno di noi non ha capito il compito. Se quella persona avesse stimato il compito da solo, sarebbe stato stimato sbagliato.
4. inseriamo 3 numeri da sopra il punto in equazione e riceviamo stima (excell) k

Dopo che l'attività lavorativa è terminata e la nostra stima è sbagliata, cerchiamo di trovare i motivi per cui. E incorporiamo questa conoscenza nel prossimo processo di stima. Finora questo è il miglior processo che ho usato per la stima di compiti più grandi. Quando dico compito intendo lavori che richiedono circa 50-500 ore.

Nota: questo si applica solo ai progetti in cui si fatturano all'ora rispetto a una tariffa fissa / fissa.

Di solito cerco di pianificare il mio programma in modo che consista essenzialmente di un gruppo di Sprint SCRUM (se si utilizza SCRUM o no). Davanti a me, durante la pianificazione, stabilisco quale sarà la lunghezza di ogni sprint e quali saranno le caratteristiche del progetto. In genere ci sono alcune caratteristiche che devono essere fatte prima, quindi cerco di dare una stima migliore (da non confondere con l'ottimismo) per quelle e tutte le caratteristiche che saranno verso la fine del progetto avranno stime generalizzate. Dopo aver mappato le funzionalità agli sprint, provo ad aggiungere da 1 a 2 sprint alla fine del progetto per tenere conto delle caratteristiche che scorrono a destra e per le funzionalità trascurate nella raccolta dei requisiti originale.

La chiave di tutto è che tutto questo è trasparente per il cliente in anticipo, così capiscono perché gli ultimi due sprint sono vuoti o scarsamente popolati. Almeno a questo punto, il cliente con cui ho lavorato mi è piaciuto perché sa che c'è un certo margine nel programma / finanziari poiché molti di loro sono consapevoli che le stime del SW tendono ad essere meno che concreti. Sono anche consapevoli del fatto che se non abbiamo bisogno dell'ultimo sprint o giù di lì, allora quelle sono ore che non fatturiamo. Con la trasparenza del modo in cui è costruito il programma e il feedback regolare su come stanno andando i progressi durante l'esecuzione del progetto, ogni cliente con cui ho fatto questo è stato estremamente soddisfatto.

Oltre a tutte le cose citate, vedo queste due cose come alcuni dei maggiori problemi. In primo luogo, si stima la data finale in base alla disponibilità di ogni deviatore per le 8 ore al giorno 5 giorni a settimana. Questo non è corretto e garantisce quasi al 100% che la data di fine non venga rispettata su qualsiasi progetto che non sia banale. Le persone prendono tempo libero, partecipano alle riunioni aziendali (o non basate sui progetti), combattono con le risorse umane per le richieste di assicurazione sanitaria, fanno pause, ecc. Non assumere mai più di 6 ore di disponibilità per sviluppatore al giorno.

I devlopers successivi notoriamente dimenticano di stimare tutte le attività non di sviluppo come riunioni ed e-mail riguardanti il progetto, la distribuzione, il supporto QA, il supporto UAT, i test delle unità di scrittura, la ricerca, la documentazione ecc. Una volta aggiunto questo tipo di compito alla nostra stima foglio di calcolo, le nostre stime sono migliorate.

Quando si tratta di stimare il tempo per le attività che possono richiedere più tempo di alcune ore, faccio del mio meglio per utilizzare queste regole:

1. Non mai cerca di prevedere quando altre persone finiranno il loro lavoro se ti capiterà di dipendere da esso. Parla solo per te.
2. Analizzare prima l'attività, quindi effettuare una stima. Analizzando voglio dire almeno scrivere (e non cercare di tenere tutto in te!) Una lista di sottoattività con stima per ognuna di esse.
3. Se un'attività è abbastanza complessa, stimare il tempo per tale analisi stessa. Lascia che la stima sia un processo separato. Puoi anche assicurarti che il tuo capo lo sappia.
4. Non stimare sotto pressione. Metti in chiaro che ci vuole tempo per fare una stima ragionevole e dire loro qualcosa come "Chiamerò una data domani entro le 11:00, quando avrò finito di analizzare l'attività". So che alcuni clienti / manager possono fare pressioni, ma non devono passare. Metti la tua faccia impegnata e richiedi il tuo tempo!
5. Chiedi un po 'più di tempo che pensi ti servirà perché probabilmente hai dimenticato di aggiungere un tempo di pausa caffè (e altre distrazioni) nella stima.
6. Per le attività di grandi dimensioni chiedi anche di più: probabilmente ci sarà più di una pausa caffè.
7. Se davvero non riesci a stimare (l'attività è troppo difficile / non familiare) o davvero incerta, chiedi a qualcuno in grado di aiutarti con la tua analisi.

Probabilmente ci sono più regole di quelle, ma in realtà non ho un poster con queste regole sulla mia bacheca. Li ho appena formulati ora, ma vengono dalla mia esperienza (quindi potrebbe non funzionare per voi).

L'unico modo affidabile per pianificare lo sviluppo del software che riesco a pensare (ma non l'ho ancora provato) è Pianificazione basata sull'evidenza che è fondamentalmente il metodo Monte Carlo utilizzato per contare la probabilità di una data di spedizione in base a record storici relativi alle attività che hai già realizzato. È bello perché non tenta di utilizzare parametri diversi dal tempo stimato e attuale. Tuttavia, richiede molta esperienza per dividere in anticipo le attività più grandi in quelle più piccole e devi disporre di una grande serie di dati storici per farlo funzionare con precisione.

Ci sono "unknown unknown" e "unknown unknown". : -)

1. Le stime spesso diventano scadenze.

   • Nessuno vuole perdere una scadenza e diventare titolo!

2. I requisiti cambiano (spesso razionalmente) e il programmatore non può porre il veto.

3. Il programmatore fa / potrebbe non avere il controllo su fattori come

   • Disponibilità del codice su cui и dispedente su
   • Qualità del codice da cui dipende
   • Architettura generale e design del sistema
   • API per accedere ad altre parti del sistema