Calcola i costi del codice errato

Ho scoperto che se è possibile fornire numeri validi, è più probabile che i gestori agiscano. (Se possono comprendere la logica e il rapporto costi / benefici.)

IMHO, per fare un caso convincente, avresti bisogno di quanto segue per mostrare quanto sia grave:

• numero di incidenti di supporto registrati per i problemi
• tempo trascorso in ore a mantenere / bandire codice errato / fare supporto correzioni
• costo in base al tasso orario delle persone che eseguono la manutenzione / banda AIDS / support
• un modo per dimostrare in che modo questi oggetti sono critici per la missione attività

E per chiarire il caso, avrai bisogno di:

• stima del tempo per refactoring e implementare ciascuno dei primi 3 di questi cose brutte
• stima dei costi per l'implementazione (stesse tariffe orarie utilizzate in precedenza)

Con questi, puoi risparmiare tempo se il refactoring richiede molto meno del tempo di supporto per 3 incidenti per ciascuno dei 3 articoli principali. Puoi sostenere che questa quantità di tempo speso sarà inferiore a

• essere inferiore a n ulteriori incidenti di supporto
• non ci saranno più di questi incidenti per queste cose (ANCORA MEGLIO!)

Tuttavia, la parte più difficile di questa vendita sarà rispondere alla seguente domanda, dal momento che molte persone non risparmiano tempo nelle pianificazioni per tutto il supporto che stai facendo:

Per quanto tempo dovrò aspettare che il progetto corrente Y venga completato mentre passi del tempo a lavorare su questi problemi con X ????? (nonostante i tempi di supporto correnti, che non può essere previsto e pianificato nei grafici di Gantt)

Dipende molto dal modo in cui comunichi con i responsabili delle decisioni e da come capiscono la situazione.

Sicuramente penso che valga la pena farlo, così ti eserciti a costruire il caso con le metriche e a risparmiare tempo, anche se non lo fanno. Sfortunatamente, non tutti sono facili da convincere, nonostante i dati. BUONA FORTUNA!

Tieni presente che il refactoring introduce anche bug (che ti attendono nei tuoi test, ma sono comunque bug e devono essere corretti). Non tirare un Netscape in caso di incidente. Dipende dalla tua personale definizione di "refactoring". Per alcuni, questo significa "riscrivere tutto il codice" ad altri significa "cambiare alcuni interni". Come si dice che tipo sei? Porsi la seguente domanda:

Sto modificando l'interfaccia pubblica?

Se la risposta è sì, stai riprogettando. Se la risposta è no, stai facendo il refactoring e probabilmente puoi farlo solo nel corso delle tue attività quotidiane senza un'approvazione speciale. Questo è rilevante per la tua domanda perché una riprogettazione genererà molti più bug, mentre un refactoring è solitamente più facile da eseguire (dato che i tuoi test eserciteranno già l'interfaccia pubblica e non dovranno essere modificati).

È un caso difficile da fare, perché nessuno sa mai quanto X sarebbe costato con o senza il refactoring che è stato fatto un anno fa. Nella mia esperienza i manager pragmatici sparano sempre a questo genere di cose perché:

1. Nessun flusso di entrate diretto deriva dallo sforzo (costo finanziario, non fatturabile)
2. Un codice di lavoro brutto funziona ancora, si rischia di creare problemi anziché risolverli (costo potenziale di qualità)
3. Gli altri progetti subiranno un ritardo durante il refactoring (costo del tempo)

Tutti questi numeri si basano in ultima analisi su ipotesi, nel tuo caso confrontando l'importo che si suppone sarebbe costato non al refactoring rispetto a quello che si suppone sarebbe costato a refactoring . Il meglio che puoi fare è mostrare che hai qualche tipo di base numerica e fattuale per le ipotesi, e ne hai una abbastanza buona.

I professionisti sono che sarà probabilmente efficace convincerli a lasciarti refactoring, e potrebbe andare bene e ridurre il numero di bug.

Gli svantaggi sono che se la quantità di tempo speso per correggere i bug non diminuisce almeno quanto il tempo impiegato per il refactoring, probabilmente non ti sarà più permesso il refactoring, e probabilmente sarai incolpato per il " tempo perso.

Il risparmio nel tempo di debug ottenuto riducendo la complessità del progetto nel suo insieme o semplificando l'aggiunta di funzionalità potrebbe essere troppo difficile da misurare per aiutarti, ma potresti dire che esistono.