metodo di stima nella "fase di definizione appena terminata"

Question

metodo di stima nella "fase di definizione appena terminata"

#1 da (4 voti)
#2 da (0 voti)

0

Utilizziamo fondamentalmente la metodologia del ciclo di vita di Waterfall. Analisi dei requisiti: ottengo un caso d'uso creato da qualcun altro. Design (parlando solo di un design di basso livello): mi viene un po 'da pensare a come lo disegnerei, potrebbe essere sia all'istante che dopo un po' di tempo. Test di codifica e unità: in caso di test di unità, non sto utilizzando alcun TDD, ma sto cercando di ottenere la copertura completa del codice, tramite mock e così via dopo che la codifica è terminata.

Mi viene chiesto delle stime subito dopo il passaggio del Requisito. Dal momento che ho solo una buona idea su come sarà il design, non ho modo di dire sulle stime. Per quanto riguarda la parte di codifica, come posso ottenere il numero totale di metodi nella "fase di definizione appena terminata" (non so mai quanto sarò in fase di refactoring in questa fase), Unit Testing con copertura completa del codice: I haven ' Ho scritto un codice, quindi come posso sapere quanti comportamenti ci sono per testare un metodo e quindi il tempo.

C'è qualche modo scientifico / o altro modo per saperlo in questa fase?

Nota: ho già letto questo possibile domanda simile .

Posso suddividere tutte le mie attività in piccole unità, ma ho problemi a dare una stima per ogni unità.

Edit1

Anche questo è parte del mio problema tutto è iniziato da qui. Anche la nostra organizzazione ha testato (o correttamente detto eseguito test di integrazione) manualmente o tramite emulatori, ecc. Quindi ogni volta che vengono apportati miglioramenti per un determinato cliente È necessario creare nuovamente i dati di test e che dire di eventuali modifiche irrisolte che hai introdotto. Quindi, introduco Automated Unit Testing, ma ora c'è di nuovo un problema per la stima corretta che è necessaria per dare all'organizzazione una visione lungimirante della "stima del tempo di creazione di una suite di test con codice" in parole semplici costruite per il team di validazione.

Gentilmente aiuto.

estimation time-estimation planning workload-estimation

posta shankbond 24.07.2013 - 18:43

fonte

2 risposte

Leggi altre domande sui tag estimation time-estimation planning workload-estimation

pattern MVVM: il miglior approccio di progettazione per gestire un'applicazione Posso vendere il mio software che utilizza parti di PSEXEC [chiuso]

score 4 · Answer 1

Ti suggerisco di leggere qualcosa chiamato Cono di incertezza .

È provabile impossibile stimare con precisione la data di completamento di un progetto prima che l'implementazione o addirittura il progetto siano effettivamente iniziati. Questo non vuol dire che non si possa stimare affatto, ma in questa fase della pianificazione, la durata effettiva potrebbe essere pari a 4 volte la stima, anche se si è in grado di fornire stime di attività estremamente accurate.

Questo è il motivo per cui la cascata è malvagia. Persino Royce lo ha proposto solo come un uomo di paglia per ciò che non dovresti fare. Cerca almeno di ottenere il buy-in per RUP e consentire un certo grado di iterazione, altrimenti sei fregato.

Se sei davvero tenuto a qualsiasi stima ti venga in mente (in altre parole, non è in realtà una stima , ma piuttosto una scadenza ), quindi trascorri alcuni giorni o settimane a sviluppare un'architettura e un modello di usabilità, stimare le tue funzionalità / attività, aggiungerlo e moltiplicare per 4. Questa è la migliore euristica disponibile.

Se prevedi problemi di sovraccarico (organizzazione occupata), formazione, turnover, ecc ... quindi aggiungi più fattore fudge per tenerne conto. Stimare la percentuale di tempo al giorno che il team del progetto spenderà effettivamente per il lavoro del progetto e dividere per quel numero per ottenere una stima corretta. Questo è separato dal margine di errore del 400% sopra riportato; quella stima è per sforzo mentre la stima corretta è per tempo.

score 0 · Answer 2

Quando ho bisogno di fornire stime, dopo aver completato l'analisi, vorrei fare quanto segue: 1. Guarda le singole funzioni che codificheremo. 2. Usa il totale di tutte le funzioni come un conteggio e poi dividi queste funzioni in livello semplice, medio e difficile, che indica di nuovo la quantità di codice che dobbiamo fare.

Per ognuno, assegnerei un tempo, in base alla mia esperienza e quanto avrei impiegato per completarlo.

Ora, per l'applicazione totale, otterrò un valore, se devo svolgere personalmente il compito.

Quindi, inizio a lavorare sulla regolazione fine.

Come rimuovere i metodi duplicati, aggiungendo in tempo per il refactoring (che in realtà riduce il tempo se si usa uno strumento per refactoring e si avvia il refactoring mentre si codifica invece del refactoring dopo il completamento), un po 'di margine di errore.

Seguendo questo metodo, anche se ci sono ritardi imprevisti, sarò in grado di consegnare l'attività in tempo, e più spesso presto.

Una cosa importante che fa la differenza è la tecnologia da utilizzare e il livello di abilità in quella tecnologia.

Come gli altri hanno detto sopra, c'è un rischio nelle prime fasi della pianificazione. Le stime devono essere migliorate all'avvio e all'avvio del progetto.

Risorse, skillset, tecnologia (esistente / nuova), fanno la differenza.