Come posso stimare quanto tempo impiegherà un progetto? [duplicare]

C'è molto da dire per i requisiti dettagliati. Tutti odiano creare documenti sui requisiti, ma sono un male molto necessario. Detto questo, ho gestito molti progetti software nel corso degli anni e ho alcuni metodi che ho trovato rendono molto più facile stimare.

Personalmente non posso dire abbastanza su Microsoft Project. Ci sono strumenti gratuiti con capacità simili ma MS Project è di gran lunga il mio preferito. Indipendentemente da quale strumento di gestione del progetto sceglierai, queste metodologie dovrebbero applicarsi ancora.

1. Crea un elenco di attività di alto livello (CMS, layout del sito, codifica personalizzata, ecc.)
2. Inizia ad aggiungere attività secondarie e gruppi di attività secondarie, secondarie e secondarie dal livello superiore.

In definitiva ciò che stai cercando qui è capire tutto ciò che è coinvolto. Non otterrai tutto, ti mancherà inevitabilmente qualcosa, ecc. Ma non è questo il punto dell'esercizio. Man mano che procedi a elencare ogni attività che deve essere eseguita (abbassa elementi come Ricerca X, Test X, ecc.) Scoprirai attività a cui non hai mai pensato mentre la attraversi. Pensa a tutto ciò che deve essere fatto dalla pianificazione alla costruzione, alla verifica, alla migrazione al cliente.

Una volta terminati tutti i compiti, puoi iniziare a stimare il tempo necessario per ciascun articolo. I tuoi tempi sono un'ipotesi plausibile, assicurati di riempirli con il 20-40% (o più) di tempo in più di quanto pensi. Lo strumento di gestione del progetto che usi dovrebbe avere un concetto di "Predecessori" o simili. Ciò ti consentirà di collegare le attività e indicare quali attività richiedono il completamento di altre attività.

Ora che hai compiti, stime temporali e predecessori, il tuo piano di progetto può "iniziare" a stimare una tempistica per te.

La gestione del progetto ha essenzialmente due concetti principali. O A, la scadenza del progetto dovrebbe dettare la timeline o B, i compiti del progetto dovrebbero dettare la timeline. Sono MOLTO molto nel campo B. Molti tipi di MBA e "contatori di bean" tenteranno di dirti quando il progetto è "Due". Guarderanno anche il tuo piano e diranno "se mettiamo 5 sviluppatori sul task X, verrà eseguito in 1/5 del tempo". Queste teorie sono inutilizzabili in un mondo di sviluppo software. Mentre ci sono alcuni casi che un concetto simile può essere impiegato, è generalmente una ricetta per il disastro. Immagina 5 persone che provano a modificare lo stesso file contemporaneamente. Cammineranno l'uno sull'altro e anche gli strumenti di gestione del codice sorgente più avanzati saranno molto più brevi.

OK, quindi hai una "stima" ora. Sì, è approssimativo, no non è completo e sì cambierà (tornare indietro e aggiungere più tempo di riempimento ora). Probabilmente anche guardando la data di fine e pensando a te stesso, il cliente / capo sta per impazzire quando vedranno quanto tempo ci vorrà. Qui è dove ti fermi e fai un respiro profondo. Non solo hai pensato a tutto ciò che questo progetto prenderà, ma ora hai i dettagli documentati su PERCHÉ ci vorrà così tanto tempo. Se vogliono mettere in discussione il tempo devono andare per compito per "ritagliare" il tempo. Ho trovato nel 95% dei casi che non avranno alcun interesse a farlo. Avrete anche (nelle loro menti) chiaramente capire cosa deve essere fatto ed essere visto come un "esperto" nel farlo poiché avete un piano dettagliato che mostra cosa ci vorrà.

Note: assicurati di inserire le attività con le stime nelle ore in cui puoi. È difficile contestare che qualcosa durerà 8 o 10 ore. Se metti 1 giorno, iniziano a provare a negoziare. Ci saranno compiti che richiedono settimane e mesi, basta metterli come tali e prepararsi a spiegare il perché. Se è possibile, suddividere questa attività in attività secondarie più piccole in ore / giorni.

Spero che ti aiuti! Daniel .....

How can i judge how long it will take to complete a website?

How can I estimate how long the job will take, and how can I calculate the required time to finish any new projects?

Non puoi.

Prepara un programma con cui ti senti a tuo agio.

Il meglio che puoi fare è produrre piccoli risultati (settimanali, ogni due settimane) e provare a indovinare quanti di questi.

Credo che le pratiche di stima agili siano le più accurate. Perché ha successo è perché si basa sulla stima delle caratteristiche in relativa complessità, e quindi si combina con la capacità effettiva misurata.

Una buona introduzione è questa presentazione in due parti di Mike Cohn: Part1 Part2 . È circa 1:30.

Joel sulla programmazione basata sull'evidenza

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

The steeper the curve, the more confident you are that the ship date is real.

Here’s how you do it...

Probabilmente non puoi farlo su base razionale, specialmente per un progetto nuovo di zecca.

Vedi: Grandi limiti alla stima del software Materiale di supporto: Limiti matematici alla stima del software

In sostanza, la stima si riduce all'esperienza. Valuterai in modo più accurato il nuovo lavoro in una base software già esistente. Valuterai in modo meno accurato il software nuovo di zecca. Ogni tanto, sottostanti o sovrastimato grossolanamente.

Ricorda, chiamano le stime per un motivo. Definisci compiti e inizia a tracciare il tuo lavoro. Prova a sviluppare una sorta di linea di base. Quindi esercitati a fare stime e verifica l'accuratezza.

Non sei sicuro di come puoi confrontarti con gli altri, ma puoi almeno provare a migliorare il tempo di sviluppo e la capacità di stima.

Hai bisogno di requisiti che sono ulteriormente cotti per dare una stima accurata. Tu o un BA devi recarti presso il cliente per determinare ciò che vogliono, elaborando i punti elenco che hai elencato sopra. Siediti e pensa a un elenco di domande per ciascuno dei precedenti, in modo da poter intervistare il cliente. In base alle loro risposte dovresti iniziare con un progetto approssimativo e suddividere i tuoi compiti al livello più basso di granularità possibile. Fino a quando non puoi suddividere ogni attività a 16 ore o meno, devi assicurarti che il cliente comprenda che il tuo livello di fiducia nelle stime è x%, molto probabilmente inferiore al 70% per iniziare, ma con esperienza.

Una volta che i tuoi compiti sono stati suddivisi nelle 16 ore magiche o meno che ho menzionato sopra, dovresti essere in grado di dare una stima accurata. Tieni presente che quando inizi, farai schifo a stimare. Devi tenere traccia di ciò che hai stimato in ciascuno dei tuoi progetti in modo da poter continuare a migliorare. Se hai perso una parte importante della funzionalità in una stima, devi ricordarla quando stai mettendo insieme le stime future.

Lo sviluppo web offre un livello di incertezza, i clienti avranno le loro preferenze personali sullo stile della pagina e ottenere che da loro possa risultare difficile. Devi tenerlo a mente, quando riesaminano il tuo lavoro devi essere pronto a dire loro cosa ci vorrà per portare a termine le modifiche che hanno richiesto. La stima di un singolo progetto deve essere un processo interativo in cui la fiducia aumenta con ogni iterazione.

La pratica aiuterà. Le prime volte che lo fai ti capiterà veramente male, ma se cerchi di capire cosa hai sbagliato ogni volta e di imparare da esso dopo un po 'lo farai bene. (O vai fuori mercato perché continui a pagare meno persone)