A volte, ci sono progetti di ricerca e sviluppo in cui non si sa nulla in anticipo sulla tecnologia, i concetti e il cliente. Tuttavia, il gestore ha ancora bisogno di stime temporali. Cosa posso fare per produrre stime utili?
Onestamente, come scrive Nassim Nicholas Taleb nel suo libro The Black Swan: "non possiamo proprio prevederlo". Principalmente a causa di incognite sconosciute. In genere è meglio comunicare questo fatto, il fatto che non è possibile prevedere, invece di comunicare una stima.
Come scrive Taleb: è meglio avere una visione generale, che sbagliare. Quindi assicurati di comunicare il fatto che hai difficoltà a stimare e ad usare le cose come "curve di apprendimento in nuove tecnologie" come uno degli argomenti. Ciò significa che l'intervallo della tua stima sarà grande: "questo progetto avrà un costo compreso tra 100k e 500k".
Dicendo una cosa del genere, quella che ti chiede di stimare qualcosa si rende conto che le cose non sono così semplici.
L'assoluta prima cosa di cui hai bisogno è un'idea dell'ambito. Più concreto è, meglio è, ma qualsiasi forma di fabbisogno può essere utilizzata per produrre stime iniziali. I requisiti del cliente, la visione, lo scopo e i documenti concettuali possono essere utilizzati nelle prime fasi. Man mano che i requisiti e l'ambiente operativo cominciano a diventare più chiari, le stime miglioreranno. Una maggiore comprensione del cliente (in particolare le interfacce tra il cliente e l'organizzazione in via di sviluppo), il team che esegue il lavoro, le tecnologie da utilizzare, l'architettura del sistema e una progettazione dettagliata contribuiranno a una stima più accurata. Questo è visibile nel Cono dell'Incertezza.
Se si utilizza uno strumento di modellazione parametrica, ad esempio SLIM o COCOMO (solo intermedio o avanzato, in quanto Basic non tiene conto dei fattori di costo), devono esserci fattori di regolazione per la non familiarità della tecnologia. Ad esempio, COCOMO ha un gran numero di driver di costo , inclusi alcuni specificamente orientati verso familiarità con la piattaforma di destinazione, nonché la lingua e gli strumenti utilizzati per sviluppare il sistema. SLIM tiene conto anche dell'esperienza complessiva del team di sviluppo, che dovrebbe includere considerazioni sugli strumenti e le tecnologie utilizzate.
Con questa tecnica, gli output degli strumenti di modellazione sono generalmente validati perché sono stati utilizzati con successo per stimare progetti software precedenti per molti anni in molte organizzazioni. Tuttavia, l'output è valido quanto l'input dello strumento.
Se non stai utilizzando modelli parametrici per la stima, dovrai semplicemente considerare questi fattori quando produci le tue stime. Diventa più un giudizio, ma puoi prendere in considerazione attività come leggere la documentazione, configurare il nuovo ambiente di sviluppo e sviluppare applicazioni di esempio sulla piattaforma di destinazione o con le lingue di destinazione.
In questi casi, è necessario suddividere le stime per attività ed essere in grado di utilizzare il proprio giudizio professionale per eseguire il backup. Si spera che tu abbia dati storici e altre prove concrete su cui basare le tue stime. Altrimenti, è più una battaglia in salita.
Separa i tempi di formazione e di ricerca più importanti dai tempi di sviluppo. Rompere il progetto in più sottoprogetti che hanno lieto fine. Assicurati di creare un proof of concept dopo l'allenamento.
Se sei nuovo nella tecnologia, non ti avvicinerai mai al tempo di sviluppo effettivo. Raccogli questo come un rischio all'inizio del progetto e sii generoso nella tua stima. Questo vale per le tecnologie di base che tu e il tuo team non avete familiarità.
Dipende, ho usato FPA ( Analisi del punto di funzione ) per la maggior parte del tempo, ma eravamo in questo "sviluppo web in -prospetto", intendo, sai, Forbes 500 web company.
L 'attività può essere sempre divisa in due parti: una, che si adatta perfettamente all'FPA: si hanno interfacce di input, interfacce di output, file logici interni (cioè tabelle / tipi di database da esportare) e si dispone di questi complessi , sistemi sconosciuti.
Nella versione facile, il compito complesso è un componente già scritto, è solo difficile e sconosciuto interfacciarlo con esso.
La versione dura è quando deve essere scritta, quindi le stime basate su piloti, COCOMO, qualsiasi cosa.
Due cose, tuttavia, di importanza:
Ogni tipo di sistema di stima deve avere un tempo di calibrazione per la tua organizzazione. Non ti sviluppi mai da solo, almeno c'è un cliente che aspetta il tuo codice (o non saresti così disperato a riguardo, scrivendo il codice per il tuo bene). La domanda non è "quanto velocemente può essere sviluppata?", Ma "quanto velocemente può essere sviluppato con tutti voi?"
Una volta avevo un manager che leggeva il romanzo di Black Swan e ne era pazzo. Ci stava dicendo che è impossibile stimare, e stavo facendo la mia solita precisione a + -10% delle stime inesorabilmente ...
Realizzo progetti che si adattano regolarmente a questa descrizione e non l'ho ancora capito! Per fortuna, dove lavoro, mi viene data la libertà di fare ciò di cui ho bisogno e non ho limiti di tempo inutili. I progetti non hanno sempre successo e questo è solo una parte di ciò che il lavoro è con così tante incognite. Tuttavia, ogni volta l'azienda acquisisce conoscenza.
Spiacente, questo non aiuta affatto
Stima il tempo necessario per realizzare un progetto simile usando la tecnologia familiare. Moltiplicare per 4. Aggiungi un po 'di tempo per l'apprendimento.
Se la stima è troppo breve sembrerai ingenua e arrogante. se la stima è troppo grande sembrerai ignorante e incompetente. Scegli con saggezza.
Leggi altre domande sui tag estimation time-estimation