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

Sembra che, secondo la mia esperienza, convincere noi ingegneri a stimare e determinare accuratamente i compiti da svolgere sia come tirare i denti. Piuttosto che dare una stima di swag di 2-3 settimane o 3-6 mesi ... qual è il modo più semplice per definire programmi software in modo che non siano così dolorosi da definire? Ad esempio, il cliente A desidera una funzionalità entro il 02/01/2011. Come si pianifica il tempo per implementare questa funzione sapendo che potrebbero essere necessarie altre correzioni di bug lungo il percorso e impiegare tempo di progettazione aggiuntivo?

Se stai lanciando un progetto quasi identico ad altri progetti che hai fatto, usando strumenti familiari e un team familiare e ti vengono dati requisiti scritti e fermi, allora dovrebbe essere possibile fare una buona stima.

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

Spesso ci viene chiesto di stimare progetti che utilizzano nuovi strumenti, tecnologie, dove i requisiti cambiano, ecc. Questa è più estrapolazione verso l'ignoto che interpolazione sulle nostre esperienze passate. Quindi è naturale che la stima sarà più difficile.

Secondo la mia esperienza personale, è esattamente l'opposto di quello che ha detto Pemdas : con la pratica, ho appena capito che è totalmente impossibile stimare quanto tempo richiederà un'attività. All'inizio della mia carriera nello sviluppo di software, ho spesso dato stime come "45 giorni", "cinque settimane", ecc., Quindi ho cercato molto duramente di finire in tempo. Alcuni anni dopo, ho iniziato a fornire stime meno precise come "circa un mese", "5-7 settimane", ecc. In realtà, provo o a non dare alcun preventivo, o chiedo al cliente di dare il proprio preventivo o scadenza o do 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 mentre lavorano gli altri, la tua motivazione, ecc. Ecco un elenco più dettagliato dei possibili motivi:

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

2. Potrebbero sorgere alcuni problemi . Ad esempio, se, per iniziare il lavoro, è necessario installare sul computer un server SQL di fantasia e l'installazione non riesce e il supporto è inesistente, è possibile passare settimane a risolvere questo problema.

3. I requisiti spesso non sono abbastanza chiari , ma dopo averli letti all'inizio, pensi che lo siano. A volte puoi capire che significa "A" e, dopo aver iniziato a implementarli, noterai che forse significano "B".

4. Ai clienti piace cambiare le loro esigenze esattamente quando hai appena finito la parte interessata , e davvero non capiscono perché stai richiedendo altre due settimane e $ 2000 per fare una piccola modifica, perché non vedono che questa piccola modifica richiede 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, si passa ai programmatori StackExchange e si passano ore a leggere per rispondere alle domande.

6. Le cose peggiorano quando il tuo preventivo 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 . Avevo clienti che passavano settimane prima di rispondere alla loro posta. Può davvero influire sul tuo programma quando devi attendere la loro risposta (ad esempio se stai chiedendo loro di specificare un requisito).

Cosa sai fare?

1. Dai un programma più ampio . Se pensi di poter svolgere il lavoro in due settimane, supponi che lo consegnerai entro un mese.

2. Sii chiaro . Se fai affidamento su un designer, un altro sviluppatore, ecc., Dillo. Invece di dire "Consegnerò il prodotto tra tre mesi", dire "Consegnerò il prodotto entro due mesi dopo che il progettista mi fornirà i file PSD".

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

4. Taglia il tuo programma . La consegna puntuale di parti di un grande progetto è più semplice.

5. Non dare mai una stima quando usi un prodotto che non conosci bene o, soprattutto, quando lavorerai su un codice sorgente di qualcun altro: non puoi mai prevedere quanto può essere scadente il codice sorgente e quanto tempo impiegherai comprenderlo e copiarlo su The Daily WTF.

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

Non puoi rispondere fino a quando non lo avrai visto per vedere numerose cose come:

• È in una lingua familiare? (Spagnolo contro inglese contro cinese)
• È uno di un tipo che abbiamo risolto prima? (Uno in una serie in esecuzione su una rivista ad es.)
• Qualcuno dei lead richiede ulteriori conoscenze prima ancora di poterlo capire?
• C'è qualche cosa nel puzzle che, a tua conoscenza, richiederà un lavoro aggiuntivo?

Dato che di solito ci sono molte cose nuove in un progetto (altrimenti non sarebbe un progetto) non puoi dire quanto tempo impiegheranno per risolverle fino a quando non le avrai esaminate con molta attenzione. Forse anche risolverli più o meno o loro, e quindi non sei ancora sicuro che non ci siano sorprese o due in cui non hai pensato a loro.

Inoltre, c'è una forte pressione per farlo nel modo più economico possibile, quindi il più rapidamente possibile e la colpa per una stima troppo bassa non va sotto la pressione del manager del progetto ma lo sviluppatore fornisce la stima. Non ci vogliono molte iterazioni per lo sviluppatore per catturare questo, e imparare ad essere MOLTO stanco di dare numeri assoluti.

Il motivo più ovvio per cui gli ingegneri non sono in grado di fornire stime accurate è che è impossibile .

Ovviamente puoi stimare quanto tempo + -2 minuti ci vorranno da casa tua per lavorare. Sai come guidare un'auto, puoi valutare il traffico e alcuni altri fattori esterni.

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

Nel software, è peggio:

1. Le stime diventano spesso 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 stima apparentemente buona.
4. Di solito dimentichiamo tutte le altre attività oltre alla programmazione, inclusi incontri, telefonate, aiuto al nostro collega, ecc.
5. Il cervello umano è limitato . Non è stato progettato per stimare attività di lunga durata.

Ecco perché è impossibile dire ai tuoi clienti cosa sarai in grado di spedire per il 02/01/2011 con buona precisione e dimenticare il 03/01/2011.

Per affrontare tutti questi problemi, ti consiglio tecniche di stima avanzate come Planning Poker (disclaimer: questo è uno dei miei siti Web) e Sviluppo iterativo con calcolo della velocità .

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

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

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

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

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

Poiché lo sviluppo del software deve comportare 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 credeva che questa abilità fosse abbastanza importante da richiedere che lo esercitassi in modo informale su ogni caratteristica / progetto che ho implementato. Dopo ogni progetto abbiamo esaminato le stime e abbiamo tentato di capire dove ho sbagliato. Alla fine, ne hai capito.

Non è mai facile Cerchi solo di migliorare.

Un vantaggio derivante dalla suddivisione del codice consegnabile in pezzi più piccoli è che i clienti possono comprendere cosa aspettarsi e quando aspettarsi. 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 momento definito, devono sapere che risorse aggiuntive devono essere allocate a questa richiesta. Stanno correndo un rischio nella gravità dei bug che si verificano e per quanto tempo possono passare senza che vengano corretti. Quando arriva qualcosa di importante, torni dal cliente e li costringi a prendere una decisione. Posso correggere il bug o fissare la scadenza per la nuova funzionalità? Fornisci loro informazioni sufficienti per prendere una decisione informata.

Spero che tu abbia abbastanza storia di lavorare insieme e ti sei stabilito abbastanza per fidarti. Non puoi aspettarti che comprendano appieno il processo di sviluppo, ma puoi farli sentire che stai facendo uno sforzo onesto e non sfruttando la loro mancanza di conoscenza.

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

Ho imparato molto da questo libro:

Stima del software: demistificare l'arte nera

In breve, per ottenere risultati di stima migliori facciamo questo:

1. tutte le attività tranne banali sono stimate da più di una persona (due nel nostro caso)
2. dividiamo l'attività in attività più piccola. Più compiti hai, più è probabile che la tua stima sia buona - legge di grandi numeri se ricordo bene dal fischio
3. stimiamo lo scenario peggiore, migliore e più probabile. A volte ognuno di noi stima quegli scenari ad albero in modo totalmente 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 che il compito da solo sarebbe stato valutato errato.
4. mettiamo 3 numeri dal punto sopra in equazione e riceviamo la stima (eccellente) k

Dopo che l'attività lavorativa è terminata e la nostra stima era sbagliata, proviamo a trovare i motivi. 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 attività intendo lavori che richiedono circa 50-500 ore.

Nota: questo vale solo per i progetti in cui si paga ogni ora rispetto a una tariffa fissa / forfettaria.

Di solito cerco di pianificare il mio programma in modo che consista essenzialmente di un mucchio di Sprum SCRUM (sia che usi SCRUM o meno). All'inizio, quando faccio il programma, stabilisco la lunghezza di ogni sprint e quali saranno le caratteristiche del progetto. In genere ci sono alcune funzionalità che devono essere fatte per prime, quindi provo a dare una stima migliore (da non confondere con l'ottimismo) per quelle e tutte le funzionalità 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 funzioni che scorrono a destra e delle funzioni che sono state trascurate nella raccolta dei requisiti originali.

La chiave di ciò è che ho reso tutto questo trasparente per il cliente in anticipo in modo che capiscano perché gli ultimi due sprint sono vuoti o scarsamente popolati. Almeno fino a questo punto, il cliente con cui ho lavorato mi è piaciuto, dato che sanno che c'è un certo margine nel programma / dati finanziari poiché molti di loro sono consapevoli che le stime SW tendono ad essere meno che concrete. Sono anche consapevoli del fatto che se non abbiamo bisogno dell'ultimo sprint o giù di lì, allora sono ore che non fatturiamo. Con la trasparenza nel modo in cui il programma è costruito 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 nominate, considero queste due cose come alcuni dei maggiori problemi. Innanzitutto si stima la data finale in base alla disponibilità di ogni sviluppatore per le 8 ore al giorno, 5 giorni alla settimana. Ciò non è corretto e praticamente garantirà al 100% che la data di fine non venga rilevata per qualsiasi progetto non banale. Le persone si prendono tempo libero, partecipano a riunioni aziendali (o non basate su progetti), combattono con le risorse umane per le richieste di assicurazione sanitaria, fanno pause, ecc. Non assumersi mai più di una disponibilità di 6 ore per sviluppatore al giorno.

I prossimi sviluppatori 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, la scrittura di test unitari, la ricerca, la documentazione ecc. Una volta aggiunti questi tipi di attività al nostro foglio di calcolo delle stime, il nostro le stime sono migliorate.

Per quanto riguarda la stima del tempo per attività che possono richiedere più tempo di alcune ore, faccio del mio meglio per utilizzare queste regole:

1. Non tentare mai di prevedere quando altre persone finiranno il loro lavoro se ti capita di dipenderne. Parla solo per te stesso.
2. Analizzare prima l'attività, quindi stimare. Analizzando intendo almeno scrivere (e non cercare di tenere tutto nella tua testa!) Un elenco di attività secondarie 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 dì loro qualcosa del tipo "Domani nominerò una data entro le 11:00 quando finirò di analizzare l'attività". So che alcuni clienti / gestori possono premere forte, ma non devono passare. Metti la tua faccia impegnata e rivendica il tuo tempo!
5. Chiedi un po 'più di tempo di quanto pensi tu abbia bisogno perché probabilmente hai dimenticato di aggiungere un tempo di pausa caffè (e altre distrazioni) nella tua stima.
6. Per i compiti più importanti chiedi ancora di più: probabilmente ci sarà più di una pausa caffè.
7. Se non riesci davvero 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 così, ma in realtà non ho un poster con queste regole sul mio muro. Li ho appena formulati ora, ma provengono dalla mia esperienza (quindi potrebbe non funzionare per te).

L'unico modo affidabile per pianificare lo sviluppo del software a cui riesco a pensare (ma non l'ho ancora provato) è Evidence Based Scheduling che è fondamentalmente il metodo Monte Carlo utilizzato per contare la probabilità di una data di spedizione in base ai record storici sulle attività che ho compiuto prima. È bello perché non tenta di utilizzare metriche diverse dal tempo stimato e effettivo. Tuttavia, richiede molta esperienza per dividere in anticipo le attività più grandi in attività più piccole e devi disporre di una grande serie di dati storici per farlo funzionare in modo sufficientemente preciso.

Esistono "incognite conosciute" e "incognite sconosciute". :-)

1. Le stime diventano spesso scadenze.

   • Nessuno vuole perdere una scadenza e diventare un titolo!

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

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

   • Disponibilità del codice da cui dipende
   • Qualità del codice da cui dipende
   • Architettura generale e progettazione del sistema
   • API per accedere ad altre parti del sistema