Quando si creano stime di tempo per le funzionalità, esiste una percentuale standard da utilizzare per il potenziale di refactoring?

0

Nota: ho capito che il refactoring è qualcosa che fai lungo la strada, non lo tratti come se fosse una "cosa" personale, o è un tuo compito specifico. Sto parlando del refactoring lungo la strada, tuttavia non sono sicuro di quanto tempo potrei finire per spendere refactoring o riscrittura invece di implementare solo nuove funzionalità.

Mi è stato chiesto di fornire stime di tempo per ogni parte di un'applicazione web che sto costruendo. Non ho molta esperienza con le scale temporali previste come molte delle tecnologie che mi viene chiesto di utilizzare, che non ho mai usato prima. Sto fornendo stime del tempo il più vicino possibile, tuttavia, so che lungo la strada finirò per refactoring e persino per riscrivere i blocchi dell'applicazione man mano che divento più familiare con i framework.

Le stime che posso ricavare si basano su quanto tempo ci vorrà per rendere il lavoro "funzionante". Non so quanto tempo avrò bisogno di spendere per farlo funzionare bene con altre parti dell'applicazione, poiché nessuna di esse è ancora stata scritta.

Il tempo aggiuntivo dedicato al refactoring e alla riscrittura mentre procedo è sconosciuto per me. Esiste una tipica percentuale di tempo che può essere aggiunta alle stime temporali delle funzionalità che possono giustificare il potenziale refactoring e riscrittura?

Il mio project manager non ha familiarità con lo sviluppo del software. Sono a tutti gli effetti da solo su questo, con un po 'di supervisione una volta che il progetto è stato realizzato attraverso un paio di revisioni del codice con un paio di altre persone in altre parti dell'azienda.

    
posta Douglas Gaskell 26.10.2016 - 19:44
fonte

5 risposte

1

No, non esiste uno "standard", dipende individualmente da te e dai compiti da svolgere. Tuttavia, specialmente se sei un principiante, ti aspetti che le tue stime del tempo di "budello" siano troppo basse (e questo non solo perché sottovaluti il tempo di refactoring, ma anche il tempo di debug, il numero di bug del tuo codice e anche il tempo di "ricerca e apprendimento" per alcune attività di programmazione).

Tuttavia, se le tue stime sono troppo basse di un fattore di 1,5, 2, 3 o 5, puoi scoprire solo da solo . Per questo, puoi provare a stimare un'attività, misurare lo sforzo e confrontarlo con la stima. Ripeti più volte e nel corso dei mesi e degli anni potresti migliorare con le stime. Ma non aspettarti troppo, anche molti programmatori esperti non stanno facendo bene nella stima di compiti di programmazione più grandi.

    
risposta data 26.10.2016 - 20:01
fonte
1
  1. Se hai bisogno di chiarimenti su ciò che stai stimando, chiedi questo chiarimento, un paio di volte se necessario. Non chiedere se è necessario stimare i dettagli di implementazione, come "refactoring". Il gestore è più interessato a incontrare le specifiche funzionali . Quindi calcolare le stime per tutto ciò che ci vorrà per rendere semplicemente il software come desiderato, quindi aggiungerlo. Quindi il tuo lavoro con il manager è davvero quello di ottenere chiarimenti sul requisito funzionale.

  2. Se il tuo project manager vuole un singolo numero come stima del tempo, fornisci insieme all'antivisione che c'è una significativa incertezza nella stima (dovuta in parte a necessità come il refactoring), e il risultato finale potrebbe effettivamente variare ampiamente. Suggerire di fornire una stima più accurata con ulteriori ricerche o attività di preparazione. Il numero singolo che fornisci dovrebbe essere qualcosa del doppio della tua stima del caso migliore

  3. Spiega idealmente il Cono dell'Incertezza al tuo manager e spiega perché un fattore 4 è in realtà una differenza ragionevole tra il caso migliore e il caso peggiore nelle prime fasi di un progetto di sviluppo software. Cioè potresti completare a metà o raddoppiare il tempo effettivamente stimato.

risposta data 26.10.2016 - 23:00
fonte
0

Come spesso accade, dipende.

Se stai partendo da zero, stai provando a realizzare un disegno decente in anticipo o semplicemente a farlo mentre vai? Meno pianificazione porterà probabilmente a un maggiore tempo di refactoring.

Hai familiarità con il framework / linguaggio / qualcos'altro? (Sembra che tu non lo sia, ma lo sto inserendo nell'interesse di avere una risposta più completa e generale). Se non lo sei, quasi inevitabilmente troverai che hai fatto qualcosa di male. Ciò porta a un ulteriore refactoring.

Quanto è grande il tuo sistema? Un piccolo sistema può essere refactored molto più velocemente di uno grande.

Quanti test automatici hai? Un sistema senza test è pericoloso per il refactoring in quanto non si sa mai cosa si sarebbe potuto rompere. Ciò significa che devi eseguire molti test manuali durante il refactoring (e quindi probabilmente introdurrai bug, portando a un maggiore lavoro). Test manuale = più tempo.

Stai seguendo i principi del buon design? SOLIDO, ASCIUTTO, ecc. Ridurranno la quantità di lavoro di refactoring necessario per l'evoluzione del sistema. La programmazione di copia-incolla lo aumenta.

Quanto sei bravo nel refactoring? Alcune persone sono più veloci di altre. La pratica di solito ti rende migliore / più veloce.

Non esiste una percentuale / quantità di tempo standard perché non esiste una situazione standard.

    
risposta data 26.10.2016 - 19:57
fonte
0

Il refactoring consiste nell'apportare grandi cambiamenti a piccoli passi. Suggerisco in base alle dimensioni della tua caratteristica di poter calcolare il tempo necessario per questo piuttosto che pensare di farlo nell'ultima fase se non stai realizzando prototipi. Come altri hanno già suggerito quanto copertura di test automatizzata hai reso il tuo refactoring più agile. Se hai preso in considerazione le modifiche di revisione per la tua funzione che dovrebbero influenzare il tuo sforzo di refactoring.

    
risposta data 26.10.2016 - 22:20
fonte
-5

Regola uno dei refactoring: Do not refactor.

La stima temporale di un'attività è fondamentalmente uguale al costo di tale attività. Il refactoring per definizione non produce cambiamenti nel prodotto che l'utente vede, quindi il suo valore per l'utente finale è zero.

Regola due del refactoring (solo per esperti): Non refactoring.

Il refactoring può avere valore per l'azienda. tempi di correzione dei bug più rapidi, aumento generale della velocità di sviluppo con l'aggiunta di nuove funzionalità. meno carico sui server ecc.

Tuttavia, questo valore è difficile da stimare e si corre il rischio di aggiungere bug in un sistema che in precedenza funzionava correttamente. Otterresti un valore molto maggiore con meno rischi lavorando su una versione 2 da zero invece di ricostruire la versione 1.

chiarimenti sulla riscrittura.

Ogni anno vediamo cambiamenti di mare in idee tecnologiche popolari. database no-sql, microservizi, architettura delle code, ecc. Per adottare queste nuove idee in una soluzione esistente può essere necessario un completo refactoring.

Tuttavia, scrivere una nuova versione da zero ti consente di passare alla nuova tecnologia mantenendo comunque un prodotto esistente.

Inoltre, a causa della grande quantità se il refactoring richiesto sarà più veloce per ricominciare. Consentendoti di abbracciare più pienamente le nuove idee e non essere vincolato da schemi precedenti. Finisci con un prodotto coerente che sfrutta appieno le nuove idee piuttosto che il mostro di tecnologia di Frankenstein accumulato sulla tecnologia

    
risposta data 26.10.2016 - 20:01
fonte

Leggi altre domande sui tag