Come stimare un'attività di programmazione se non ne hai esperienza [chiuso]

Sto attraversando un momento difficile con la direzione che chiede stime sulle attività di programmazione che utilizzano controlli di terze parti con cui non ho esperienza precedente.

Capisco decisamente perché vorrebbero le stime, ma sento che qualsiasi stima che fornirò sarà a) troppo breve e mi farà sembrare cattivo oppure b) troppo lunga e mi farà sembrare cattivo.

Quale stima o risposta potrei dare alla direzione per togliermeli dalla schiena in modo da poter continuare a fare il mio lavoro!

La migliore risposta che puoi dare è chiedere tempo per mettere a punto un prototipo veloce per permetterti di dare una stima più accurata. Senza una certa esperienza con uno strumento o un problema, qualsiasi stima che dai è essenzialmente priva di significato.

Per inciso, molto raramente c'è un problema nel fornire una stima troppo lunga. Si verificano problemi imprevisti, le priorità cambiano e i requisiti vengono "aggiornati". Anche se non utilizzi tutto il tempo che hai richiesto, avrai più tempo per i test o puoi rilasciare "presto".

Sono sempre stato troppo ottimista nelle mie stime e questo può mettere molto stress nella tua vita, specialmente quando sei un giovane programmatore senza l'esperienza e la fiducia in te stesso per dire ai capi verità scomode.

Ti svelo un segreto. Anche se fossi un esperto con quella tecnologia, è probabile che la tua stima sia altamente imprecisa. È la natura della bestia quando si fa qualcosa che è intrinsecamente un compito di ricerca e sviluppo. Purtroppo la direzione spesso cerca di applicare un modello di produzione e richiede stime accurate. Per illustrare il mio punto, considera la difficoltà di stimare accuratamente i seguenti due sforzi:

A) Produci altri ombrelli da 11K che sono esattamente gli stessi dei 2K che hai sfornato il mese scorso. B) Progetta un nuovo tipo di ombrello e costruisci il primo.

Lo sviluppo del software è B, ma chiedono una stima supponendo che A.

Il meglio che puoi fare è suddividere l'attività nei pezzi più piccoli possibili (non più di 1/2 giornata ciascuno) e poi triplicare il numero finale che trovi. (Metodo Spolsky)

In alternativa, Steve McConnell ha un intero libro (probabilmente diversi) su questo aspetto dell'ingegneria del software. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (e altri) parla del cono di incertezza . Fondamentalmente fornisci una stima simile a questa:

Il lavoro richiederà tra le 3 e le 9 settimane con 4 settimane più probabili.

Man mano che il progetto procede, puoi perfezionare il tuo preventivo. Man mano che si fa più lavoro e si comprende meglio lo sforzo richiesto, è possibile perfezionare la stima per essere più accurata.

Ha funzionato per me, ma può richiedere un certo sforzo per convincere altri soggetti interessati al progetto a comprendere il processo.

Potresti prendere in considerazione la possibilità di fornire sia una stima che un livello di confidenza, cioè è 50/50 che ci vorranno 3-6 mesi o 6-9 mesi o il 75% di possibilità di essere fatto in 9 mesi e il 90% che lo sarai fatto in un anno.

Un'altra cosa che potresti prendere in considerazione è usare l' approccio della " saggezza della folla ". Vai in giro e chiedi a 25-50 persone quanto tempo pensano che ci vorrà e fai una media delle loro stime. Il Planning Poker di Mike Cohn è, credo, molto simile a questo, anche se difficile da pianificare con un solo sviluppatore.

Suddividi la tua stima in:

• Noto noto ; quanto tempo ci vorrà per fare quello che sai fare. Dovresti essere in grado di fornire questa stima con un alto grado di sicurezza.
• Incognite conosciute ; quanto tempo pensi che ci vorrà per fare ciò che non sai come fare. Puoi usare un metodo come quello di Dacracot per fornire diversi livelli di fiducia su questa stima.
• Incognite sconosciute ; questo è il buco nero in tempo reale. Queste sono le cose che insorgono nei momenti più inopportuni e ti mordono il culo. Fornisci un intervallo per la stima con giustificazione basata sui rischi che prevedi.

Offriti di adeguare la stima e alcune pietre miliari lungo il percorso. Eventuali incognite sconosciute diventeranno sconosciute note, le incognite conosciute dovrebbero diventare note conosciute man mano che acquisisci esperienza e la stima di te conosciuta può essere regolata in base ai progressi fino ad oggi. Puoi fare una stima iniziale, quindi rivalutare quando hai completato circa il 25%, poi di nuovo al 50%, poi di nuovo all'85%. Ad ogni pietra miliare la tua stima dovrebbe iniziare a convergere sul tempo effettivo che impiegheranno le attività.

Uso un preciso sistema di etichettatura per le mie stime ... classe A, classe B e classe C.

La stima della classe C è la prima che ottengono. È dichiarato apertamente come più o meno 50% a causa di incognite. Se vogliono che continui a dare loro una classe B, allora ho bisogno di soldi per fare ricerche.

La classe B è più o meno il 25%. A volte questo è abbastanza buono e mi danno i soldi per costruire. In caso contrario, meno soldi e più ricerca.

La classe A è più o meno 10%, la finale e vai o no. Se è un tentativo e mi allontano troppo dal preventivo lo confesso spesso e presto.

Penso che se rimuovi la frase "che utilizzano controlli di terze parti con cui non ho alcuna esperienza precedente", potresti avere una descrizione migliore del tuo problema più ampio.

Se "Agile" ci ha insegnato qualcosa, è che, se la direzione si aspetta che tu, su base continuativa, stimi i progetti in questo modo, e "sembrerai male" se dici che non può essere fornito perché non hai informazioni sufficienti, sei in autostrada per FAIL.

Il problema più grande saranno i problemi su cui non hai alcun controllo e che non hai ancora identificato. Quante volte ti sei guardato indietro e ti sei detto "Bene, ho premuto la mia stima proprio sul pulsante - al terzo tentativo, dopo aver capito che ... e che avevo bisogno della versione ... e che il dba sarebbe stato attivato per una settimana e che il Project Manager avrebbe avuto bisogno di me per ... per una settimana e che mia moglie era incinta e ... ".

Mi sforzerei davvero di dire: "Posso identificare i fattori di rischio critici e elaborare una lista di controllo dei risultati finali per testarli in xx giorni. A quel punto ti fornirò un'altra stima incrementale".

E sarebbe davvero bello se tu potessi suggerire che dovrebbero "Per favore insisti sul fatto che non cercherò mai di darti una stima credibile di quel tipo in futuro. Licenzimi se ci provo".

(Esagerato, ma solo leggermente.)

Non provare nemmeno a stimare. Non c'è alcun modo in cui la tua stima sarà corretta. Dopotutto è solo una stima.

Ti consiglio invece di dividere la funzionalità in piccoli pezzi (non più di, diciamo 1-2 giorni) e di provare a fornire questi pezzi come codice funzionante, completo, testabile e prezioso al cliente / gestore. In questo modo vedrà di persona i tuoi progressi giorno per giorno. Ciò significa anche che può infatti decidere di interrompere lo sviluppo una volta soddisfatto e considerarlo completo, anche se potrebbe non aver raggiunto tutti gli obiettivi.

Dai un'occhiata alle pratiche agili "Pianificazione del rilascio" e "Pianificazione dell'iterazione" per informazioni più approfondite su questo approccio.

Tieni presente che se chiedi un tempo stimato più lungo ma lo fai sotto il tempo, sembra molto meglio che sottovalutare e dover chiedere un'estensione.

Proverei a prendere in giro un prototipo in modo da avere un'idea migliore del tempo necessario. Sii onesto con i tuoi dirigenti in modo che possano prevedere ritardi imprevisti nella curva di apprendimento.

EDIT: potresti anche vedere se puoi ottenere una scadenza più "iterativa". In "Pragmatic Thinking and Learning", Andy Hunt sottolinea bene che le persone sono esperti di progetto più vicini alla fine del progetto e meno informati all'inizio. Non ha molto senso fare tutto il progetto e la stima del tempo all'inizio, quando tutti sono meno informati sul progetto. Se "iterate" le scadenze e risolvete il problema in blocchi, avrete più successo.

Molte valutazioni accurate sono la conoscenza di sé. Se hai scritto molto codice, se hai dovuto imparare molte API, inizi a farti un'idea di domande come:

• Quanto tempo mi ci vuole per imparare una nuova API?
• Quanto tempo mi ci vuole per imparare una nuova lingua?
• Quanto tempo mi ci vuole per imparare un nuovo set di strumenti (compilatore / linker / IDE)?
• Quanto tempo mi ci vuole per implementare un'attività tipica?
• Quanto tempo mi ci vuole per testare il mio lavoro?
• Quanto tempo mi ci vuole per distribuire il mio lavoro?

In tutto questo, dovresti avere un'idea di cose come:

• Quanti bug tipici crei e come sono classificati (ad esempio, facile, difficile, impossibile)
• Quante complicazioni vengono introdotte (ad esempio, necessità di refactoring a causa della mancanza di API di terze parti o API difettose; necessità di riprogettazione a causa di incomprensioni di capacità; strumenti / processi di compilazione non standard)
• Quanto tempo si perde a causa di interruzioni / problemi esterni

Sulla base di tutte queste cose, sarai in grado di sviluppare un'idea di quanto tempo impiegherà qualcosa e sarai in grado di affermare le tue ipotesi ("Presumendo che l'API sia sana ...") anche di fronte a informazioni tristemente incomplete.

Stimare quanto tempo è necessario per imparare a sufficienza per fare una stima migliore, ad esempio, "Non lo so: non ci ho mai lavorato prima. Probabilmente mi ci vorrà per inserire la tua stima qui per capire cosa hai bisogno di impararlo, cosa che dovrei sapere prima di poterti dare una buona stima per usarlo per completare il tuo progetto . "

Durante la programmazione ho sempre preso quello che pensavo davvero ci sarebbe voluto e l'ho moltiplicato per 3 per fornire una stima. Se penso di poter fare un lavoro in 1 settimana, dico al cliente che ci vorranno 3 - se penso che mi ci vorranno davvero 3 settimane dico al cliente 9 settimane.

In questo modo mi sono impegnato a "sotto la promessa, oltre a mantenere" - se riesci a farlo con successo, la tua vita sarà molto migliore ei tuoi clienti saranno estremamente felici.

Nel tuo caso vorrai sicuramente avere almeno una certa comprensione di ciò in cui ti stai immergendo prima di fornire un preventivo. Forse hai anche bisogno di fornire una stima di quanto tempo ci vorrà per fornire una stima. Moltiplicare per 3 rende felici i clienti.

Suddividi in cose con cui hai una certa esperienza. L'atto di tagliarlo a pezzi ti darà un'idea migliore di ciò che sai e di ciò che non sai.

Una volta che i pezzi sono abbastanza piccoli da poter essere visti come singoli compiti definiti, alcuni di essi saranno del tutto non stimabili. Per questi, prima fai il prototipo o lascia a te stesso un ragionevole lasso di tempo, a seconda delle dimensioni del pezzo. Se ti accorgi di avere pezzi non stimabili più grandi di 2-4 settimane di lavoro, torna prima a tagliarli a pezzi.

Alla fine arriverai ad alcune soluzioni tecnologiche molto strane (che pensi dovrebbero funzionare, ma non lo sai per certo), e un sacco di lavoro da fare per sostenere quella roba, una volta che funziona. Ci saranno alcuni pezzi di design mancanti, per i quali è meglio scegliere una libreria nota o un algoritmo molto semplice per la versione iniziale.

Se non riesci a suddividere i compiti, dovresti assumere qualcuno con sufficiente esperienza che può (dal momento che la tua mancanza di esperienza ti perseguiterà anche in altri modi). Se non puoi assumere qualcuno, dovresti contrattare per un periodo casualmente lungo (da 6 mesi a 2 anni) e andare direttamente a un prototipo disordinato (finché non sei riuscito a darti abbastanza esperienza per sapere cosa è giusto e cosa sbagliato). Ma, se finisci per agitarti, è importante non illuderti e pensare che lo stai facendo nel "modo" giusto. I prototipi dovevano essere gettati via. Si spera che una volta completato il conto alla rovescia del prototipo, tu sia pronto per costruirlo sul serio.

Paolo.

Devi solo indovinare un numero esterno e iniziare a valutare immediatamente, far loro sapere che le informazioni future potrebbero influenzare le tue stime, ma che le manterrai aggiornate.

Durante la valutazione, tienili informati, tramite un documento pubblicato sul Web o aggiornamenti settimanali, ma includi sempre una "data di fine stimata" aggiornata e i motivi (se presenti) delle estensioni.

La maggior parte dei manager dovrebbe capire che - chiedendo le date di fine, in realtà stanno dicendo "dacci un'idea di come possiamo pianificare il nostro programma" e "non prenderci un'eternità".

Se finisci per estendere più di una o due volte, rivaluta l'intero programma in base alla tua nuova conoscenza che fai schifo nella stima.

Aggiungo a ciò che ha detto RB, quando mi trovo in questa situazione stimo quanto tempo ci vorrebbe con strumenti che conosco, e poi raddoppio quella stima per costruire una curva di apprendimento.

La parte importante sta comunicando alla gestione che la stima è una supposizione , se si preme per una stima più accurata o se cercano di - Dio mio - vendono un limite di tempo (sicuramente che sarà solo prendere voi 2 giorni per costruire la Starship Azienda, sei bravo tu sei) ATTACCA LE TUE PISTOLE , non compromettere la tua stima o il fatto che sia inaffidabile.

Se la direzione sovrascrive te e timebox il compito, ad esempio "Bene, deve essere fatto in 2 giorni", fai di nuovo loro sapere che è la loro stima, che è esattamente affidabile quanto la tua.

Prendi tutto questo per iscritto.

Mi occupo molto di stima nel mio lavoro ed è una vera sfida. Una delle mie maggiori sfide è stimare quanto tempo impiegherà uno sviluppatore diverso per portare a termine un'attività senza sapere quanto sarà abile quello sviluppatore.

Mentre potresti vedere un certo successo iniziale con il metodo "sotto la promessa, oltre la consegna", scoprirai che nel tempo sarai superato da altre persone che seguono la scuola di pensiero "sopra la promessa, sotto la consegna". La mancanza di precisione tornerà a morderti in entrambi i casi. La precisione è molto legata all'esperienza e limita il numero di incognite con la tecnologia.

Una cosa che suggerirei è di avere un'idea del tipo di budget su cui lavorerà la stima. Se hai un budget limitato, non impazzire con una tecnologia sconosciuta e resta fedele a ciò che conosci. Se il tuo budget è un po 'più flessibile, puoi permetterti di sperimentare un po'.

Riconosci anche che ci saranno alcune attività in cui tutto ciò che puoi fornire è un Wild Ass Guess (WAG). Per questi dovresti impostare un tempo minimo per la tua stima e chiarire che non sai qual è il massimo. Spesso questo tipo di stima è una ragione sufficiente per escludere alcune funzionalità / requisiti dalla direzione.

Questa è un'abilità indispensabile che sia il project manager che il programmatore possono avere (e ovviamente possono padroneggiarlo!), Ho trovato un articolo, Stimare le attività di sviluppo software rese (un po ') più facili , che mi aspetto aiuti per una migliore stima delle attività del progetto.

Tutte le risposte di cui sopra hanno coperto praticamente tutto ciò che riguarda la creazione della stima stessa.

Una cosa che vorrei sottolineare è tenere traccia della tua stima (un piccolo foglio di calcolo Excel alla Joel, o anche un documento di Blocco note se è molto semplice), e alla fine di ogni giorno aggiornalo alle cifre più accurate che puoi ora fornire . Anche se non hai bisogno di restituirlo ai tuoi capi, tenerlo aggiornato ti dà un'idea migliore di come stanno procedendo le cose e, cosa più importante, avrai una buona idea del motivo per cui la tua stima cambia man mano che il lavoro procede .

Fare questo ti renderà migliore nella stima in futuro, sia per questa tecnologia specifica che per altre che non hai usato prima, semplicemente perché ti richiede a un certo livello di notare quando le tue aspettative cambiano a intervalli regolari e capire perché è successo .

Stimare quanto tempo impiegherà qualcosa fa parte del tuo lavoro. Finché è inteso come una stima piuttosto che una scadenza, non dovresti avere nulla di cui preoccuparti. Non c'è nessuno in una posizione migliore per fornire una stima della persona che scriverà il codice. Se non è possibile fornire una buona stima, è necessario rendere la direzione consapevole del rischio associato alla stima errata in modo che possano riconsiderare se vale la pena correre il rischio sulla programmazione contro questi controlli di terze parti sconosciuti.

Questa è una situazione molto comune: la necessità di affrontare l'ignoto. Un modo utile per affrontare questo problema è rendersi conto che oltre alle attività di programmazione effettive, hai un po 'di apprendimento da fare e la direzione dovrebbe esserne consapevole.

Quando ti trovi in ​​una situazione come questa, il progetto diventa improvvisamente un progetto di ricerca e sviluppo e un tempo più lungo del normale non ti farà sembrare male, dal momento che stai imparando e producendo programmi. Non so quanto velocemente stai imparando o quali risorse hai per affrontare eventuali problemi che potresti trovare (Stack Overflow è una delle opzioni che hai).

Direi che dovresti stimare come al solito e poi moltiplicare per 1,5 (se impari velocemente e hai accesso alle risorse per risolvere le tue domande) o per 2,5 se sei uno studente medio e fai affidamento solo su te stesso.

Spero che aiuti!

Fai del tuo meglio per suddividere l'attività in parti gestibili. Con un po 'di fortuna ci sono compiti specifici che sono legati al componente di terze parti coinvolto e altri che sono meno accoppiati (e quindi più facili da stimare). Fornire alla direzione le stime di divisione e indicare dove risiedono le stime più incerte.

Sono pienamente d'accordo con chi ha suggerito di giocare e di prototiparne alcuni. Impostare una casella temporale fissa per l'attività di prototipazione. ("Ho bisogno di due giorni prima per migliorare questa parte della mia stima.")

Puoi dare una gamma? 40-60 ore, qualcosa del genere?

Più piccole sono le attività, più difficile è, se puoi raggrupparle avrai un po 'più di "sbavatura" poiché gli errori potrebbero bilanciarsi alla fine del progetto.

Guarda qualsiasi area in cui hai esperienza e usala come guida. "L'ultima volta che avevo bisogno di creare una funzionalità che ha cambiato il database mi ci è voluto X". In bocca al lupo.