Nel caso in cui sei bloccato in modalità Cascata, l'unico metodo abbastanza preciso che ho usato è:

1. Crea una struttura di analisi del lavoro
2. Assicurati che sia sufficientemente dettagliato in modo da poter collegare l'entità di ogni attività a qualcosa che tu o qualcuno con cui puoi parlare.
3. Per ogni attività, trova i numeri migliori, i casi probabili e i casi peggiori basati sull'esperienza. Il caso migliore è che se tutto è andato alla perfezione, il caso peggiore è se dovessi rifarlo (forse due volte) e probabilmente è da qualche parte lì dentro.
4. Utilizza una formula di ponderazione come (1 * migliore + 4 * probabile + 1 * peggiore) / 6 per ottenere una stima per ogni attività che tenga conto dell'intervallo.
5. Ho anche visto varianti in cui è possibile aggiungere un componente di "rischio" a ciascuna attività. I tre livelli di rischio sono 0, 1 e 2. Un rischio di 0 significa che lo hai già fatto prima (o qualcosa di molto vicino), 1 significa che non lo hai fatto prima, ma è fatto regolarmente nel tuo settore, 2 significa che probabilmente non è mai stato fatto prima nel settore. Prendi il numero di rischio e moltiplicalo per un'approssimazione della "deviazione standard" della tua stima. Aggiungilo alla tua stima ponderata. Quindi un rischio di 0 non lo muove, ma un rischio di 2 lo sposta abbastanza vicino al tuo peggiore numero di caso.
6. Aggiungi tutte le attività.
7. Aggiungi un contingency (un po 'di%) per "unknown unknown".

Finirai con un numero molto preciso. Non sto dicendo che sia accurato, ma sarà preciso.

L'accuratezza dipende interamente dalla possibilità di trovare un numero per ogni attività basata sull'esperienza passata o di trovare qualcuno che l'ha già fatto prima. Più esperienza hai, migliori saranno le tue stime.

Quando esegui il progetto, traccia il tuo tempo rispetto a ogni attività e annota quelle che ti sei perso, in modo da poter confrontare. Questo ti renderà migliore nel tempo.

La stima del software è estremamente difficile. Un approccio che ho usato è quello di rompere i requisiti il più finemente possibile e stimare ogni pezzo separatamente. Quindi aggiungi un "fattore fudge" che può essere un moltiplicatore (raddoppiarlo) o un importo fisso (x ore per il lavoro inatteso). Se non hai buone esigenze, la stima è impossibile a fini pratici.

L'industria ha imparato molto nei trent'anni dal '81. Stimare così non ha mai funzionato. Con la mania Agile che ha sostanzialmente riscritto il paesaggio, usiamo "story point" che rappresentano una "difficoltà comparativa" nebulosa. Otteniamo quindi "velocità" in modo che i muck mucks possano fare le loro stime $$ con una certa quantità di dati empirici.

Ho appreso alcuni approcci "rigorosi" come le stime dei punti di funzione e alcune varianti di esso che sono state progettate per applicazioni moderne. Penso che la parte di questi approcci che è preziosa sia forzare un'analisi più dettagliata dei requisiti noti, altrimenti potrei altrimenti darla.

Ottenere un buon set di dati con cui lavorare è molto difficile anche se si ha un buon modello. Misurare la produttività è difficile. Le persone giocano quasi a qualsiasi metrica.

Ho smesso di usarlo perché la mia organizzazione è troppo disfunzionale per trarre vantaggio dalle stime del software, ma ho una certa considerazione per il gruppo Cost Xpert e il loro strumento; ma è molto costoso e probabilmente non vale il costo e la curva di apprendimento per la stragrande maggioranza delle organizzazioni.

È molto difficile stimare sforzi e costi, ma se vuoi qualcosa di più preciso, allora:

• dividi HoursOfWork in 3 componenti:

  1. stima migliore,
  2. stima più probabile,
  3. stima peggiore.

• rimuovi EstimatedIddle.

Prendi nota che qualsiasi operazione che richieda più tempo di 8 ore introdurrà un errore enorme.

Ciò che normalmente facciamo è dividere l'ambito di lavoro completo in moduli / elementi principali che potrebbero essere considerati come sotto-progetto. In altre parole, sono quelle parti del lavoro che il cliente considera come parti separate del progetto e che il cliente desidera ottenere separatamente.

Una volta terminato, dividiamo ciascun modulo in attività, sotto-attività e anche sotto-attività ancora più piccole, in modo che ciascuno possa essere stimato abbastanza facilmente e la stima impieghi da una a dieci ore-uomo. In questo modo otteniamo una dettagliata suddivisione dell'ambito di lavoro per il progetto.

L'ultimo passo è la distribuzione delle attività tra le pietre miliari. Lo facciamo in modo tale che dopo ogni milestone client vengano visualizzati risultati visibili. Questo aiuta a superare una pietra miliare e passare a un'altra. Quindi finalmente otteniamo qualcosa del tipo:

Modulo 1

    <ol>
        <li>
            Primary task 1 - 5 hrs
            <ol>
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            </ol>
        </li>
        <li>
            Primary task 2 - 9 hrs
            <ol>
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>
            </ol>

Inizialmente l'abbiamo fatto usando solo foglio Excel. Ma più di due anni fa abbiamo iniziato a utilizzare uno strumento software per questo. Ci sono pochi prodotti simili che aiutano con questo www.evenflow.com , www .swproposal.com e alcuni altri. Non ricordo tutte le liste. Abbiamo fatto ricerche molto tempo fa. Spero che possa aiutarti.

Una buona domanda è come stimare con precisione. Non esiste una stima corretta al 100% come crediamo. L'unico modo è dividere l'ambito di lavoro completo in compiti il più piccoli possibile. I compiti più piccoli sono la revisione più dettagliata e l'analisi del progetto che fai. In questo modo aumenta comunque la precisione.