Come crei accuratamente le stime per i progetti di programmazione dati a te? [duplicare]

Mi è veramente piaciuta l'idea di Pianificazione basata sull'evidenza , e ho avuto un certo successo. Utilizzando le misure statistiche dell'accuratezza della stima passata, offre un intervallo di confidenza su quanto siano accurate le stime future, piuttosto che su una data fissa. Gli svantaggi che ho riscontrato erano che richiede di ricordare di aggiornare uno strumento con il tempo trascorso alla fine di un'attività, qualcosa che non sono mai stato molto bravo a essere diligente, in quanto è molto difficile da eseguire in modo accurato se si passa frequentemente da un'attività all'altra . Inoltre, anche se si suppone che tenga conto della probabilità di interruzioni e tracce laterali, mi sono comunque sentito come se le mie stime fossero uno sparo al buio.

Recentemente, ho iniziato a utilizzare la tecnica pomodoro e ho davvero migliorato il mio feeling sia per quanto tempo ininterrotto e concentrato ha il compito di completare certi tipi di attività e quanto tempo ininterrotto e concentrato ho a disposizione in una giornata tipo. I precedenti blocchi mentali con il ricordo di registrare il mio tempo trascorso non sono un problema perché fondamentalmente è solo un pulsante premuto alla fine di ogni intervallo di 25 minuti per registrarlo. Attualmente sto lavorando a uno strumento che ibrida EBS e pomodoro per sfruttare il meglio di entrambi i mondi.

Nonostante la nostra natura spesso sarcastica e ironica, i programmatori sono ottimisti estremi quando si tratta di stimare la durata delle attività.

Non seguo un metodo formale ma ho un sistema che sembra funzionare ragionevolmente bene.

Il mio approccio abituale è quello di pensare a tutti i compiti e capire quanto tempo impiegherei (come sviluppatore esperto) per farli. Questo diventa la mia linea di base. Se il progetto sarà realizzato da un gruppo medio di sviluppatori, raddoppierò la mia stima. se sarà fatto da nuovi sviluppatori lo triplicherò. Se deve essere fatto da stagisti, lo quadruplo e avverto tutti gli affiliati che il prodotto finale prodotto dagli stagisti dovrà quasi certamente essere gettato via e riscritto. Stagisti che scrivono sistemi complessi è una pessima idea.

Questa è la stima dello sforzo. Da lì, è necessario aggiungere in tempo per test, implementazione, risoluzione dei problemi e, naturalmente, incontri con il cliente. Su un progetto medio per me, questo arriva a circa il 10-20% della stima dello sforzo.

Ogni progetto avrà una certa quantità di incognite, quindi potrebbe iniziare al 5% per tecnologie consolidate con un prodotto finale definito e arrivare al 100% per una tecnologia all'avanguardia con un obiettivo mobile come obiettivo finale. Se sai dove sono le grandi incognite (vale a dire un nuovo framework per fare XYZ), quindi concediti del tempo extra per tutte le attività che interagiscono con quella sconosciuta.

Dopo aver valutato alcuni progetti, avrai un'idea di dove sono i tuoi punti ciechi personali e imparerai a tamponare quelle aree un po 'di più.

Ovviamente, una volta fornita questa stima al supervisore, probabilmente la raddoppieranno quando la inoltreranno alle parti interessate, semplicemente perché sanno come i programmatori tendono ad essere ottimisti:)

Non so perché, ma mi sembra sempre abbastanza per me prendere la stima media dei programmatori coinvolti e moltiplicare per 3. Sembra di lanciare freccette su una tavola, ma spesso esce più vicino di metodi di stima più formali.

L'accuratezza della stima del progetto dipende in larga misura dall'abilità del cliente e la volontà di tradurre i propri desideri in requisiti aziendali senza introdurre un creep di portata elevato. E i clienti hanno pazienza per una corretta pianificazione.

Considerati i buoni requisiti di business e il minimo creep scoop, affrontiamo ancora il problema della stima della complessità ... nessun compito facile.

Ora, lavoro per i grandi affari. Spesso, dove il software è un centro di costo. In questo ambiente, si deve affrontare un certo livello di qualità. Substandard a quello di dire ... Google.

Nel tentativo di compensare questa bassa qualità ho trovato il mio metodo di attacco. Prendi in pratica:

• Requisiti aziendali (che potrebbero variare da 1 a 100%) completa.
• Rompere i requisiti in attività.
• Ora puoi spostare le attività in una timeline, vedi gantt grafico, o vai al passaggio 4.
• Tradurre le attività in requisiti tecnici di alto livello. Questo potrebbero essere piani scritti formali Ma, Di solito non lo faccio su carta. Invece, crea un insieme di classi / interfacce con no implementazione. Qualcosa di simile a refactore rosso / verde .
• Ora, è possibile stimare con maggiore precisione la complessità da implementare classi di dire, "quanto tempo lo farà prendere per fare un inventario di monitoraggio sito web?".

Ovviamente, c'è molta dipendenza dal team nel processo. Quindi il mio consiglio è di provare a essere spensierato e fare del tuo meglio. C'è solo così tanto che possiamo fare.

Per stimare lo scopo nel corso degli anni ho sviluppato una "ricetta" per la stima dell'attività.

Per prima cosa, invece di calcolare per ore, uso le frazioni giornaliere dove 0,25 è di 2 ore (basato su un 8 ore al giorno).

Cerco di suddividere ogni attività per ottenere un massimo di 1 unità (o 1 giorno). Dopodiché puoi avere una buona stima per produrre una buona versione Beta.

Poi ho avuto il 45% di quel tempo su refactoring / documenting / optimizing e infine un pieno 100% per il debugging e test (in house e con il client)

Quando somma tutto quello che ottengo, per una stima di 1 giorno, un risultato di 20 ore di lavoro reale.

Infine divido le 20 / {ore di lavoro reali} per ottenere il numero di giorni necessari per sviluppare la versione finale.

Inizialmente la parte testing / debugging non verrà utilizzata immediatamente ma a lungo termine sarà alla fine.

Combina questo con EBS e puoi ottenere una probabile data di consegna che funziona

Usiamo la tecnica di stima componenziale È come chiamiamo il tipo di stima che è la più esente da rischi per entrambi: fornitori e clienti

Si può fare uso di stime di tipo componenziale per l'intero processo di sviluppo. Non è necessario rivalutare da zero quando si desidera aggiungere, rimuovere o sostituire funzionalità, servizi, ecc. È possibile rimuovere facilmente una funzionalità senza influire sulla precisione. Come si può vedere, questo tipo è molto flessibile. È il più vicino possibile ad una stima precisa del prezzo. Con una chiara stima procedurale, una prospettiva avrà piena comprensione di ciò che paga.

Ma per fare una stima del genere dovresti avere requisiti chiari, comprendere tutte le caratteristiche del progetto e quali servizi il tuo cliente ha bisogno. Di solito non lo fai, ma dovresti provare. Di conseguenza otterrai un progetto di successo e un cliente felice.

Spero che questa informazione ti aiuti! Per il nostro team è la tecnica migliore per fare una stima accurata.

Leggi la Stima del software: Demistificare la Black Art di Steve McConnell - ci sono molte tecniche differenti descritte.

Il mio consiglio è di fornire una stima a 3 punti in quanto aiuta a comunicare il rischio del lavoro intrapreso e ti costringe a pensare a cosa potrebbe andare storto.

Esegui anche le tue stime oltre qualcun altro prima di impegnarti. E se ci sono più persone che lavorano nell'attività ho trovato Pianificazione del poker un'ottima tecnica.