Valore di ponderazione della variazione rispetto al costo, come gestire le modifiche costose

Question

Valore di ponderazione della variazione rispetto al costo, come gestire le modifiche costose

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Molto spesso ci sono situazioni in cui un bug esiste nel codice, o viene richiesta una funzionalità, dove ci si aspetta che la correzione / implementazione aggiunga meno valore all'azienda rispetto al costo di una qualsiasi delle seguenti: implementazione, in particolare la convalida nessun effetto collaterale viene introdotto in pre-release e implementato qualsiasi ri-lavoro richiesto, O costo della vita con quegli effetti collaterali nella produzione.

Quindi nessuno vuole un ROI negativo, quindi è semplicemente il caso che dovremmo convivere con tali bug o l'assenza di caratteristiche aziendali desiderate o c'è un modo migliore? La nostra unica opzione razionale è aspettare per implementare queste storie, fino a quando non sarà necessario un così grande cambiamento che si risolvono quasi naturalmente come parte di una revisione più grande?

Modifica: non sto cercando un modo per convincere il management a gestire il debito tecnico ei rapporti con il management non fanno parte della mia domanda. La mia domanda è semplicemente, c'è un'opzione migliore rispetto alle scelte di (a) ROI negativo dato il codebase così com'è (che può includere o meno il debito tecnico) o (b) attendere che siano necessarie maggiori modifiche al codice base?

development-process planning

posta Brad Thomas 25.03.2016 - 22:08

fonte

3 risposte

1

I bug che non aggiungono tanto valore al code-base come il loro fixing non dovrebbero essere affrontati, fino a c'è un tempo in cui il personale in grado nell'organizzazione non ha altro da fare. (Ammettilo, tu conosci questo accade.)

Poiché i programmatori tipicamente disegnano uno stipendio, questo trasforma il ROI negativo in uno positivo: la correzione costa ancora di più nel tempo del programmatore di quanto non ripaga, ma non è una perdita altrettanto grande come se tu fossi semplicemente seduto senza fare nulla .

risposta data 07.04.2016 - 12:53

fonte

1

Quando chiami un idraulico?

Quando il tuo rubinetto inizia a gocciolare? Probabilmente no.
Quando il tuo sink inizia a bloccarsi? Può essere.
Quando la lavatrice si spegne e l'acqua della pressione di rete penetra nel lavandino [bloccato] e inonda la tua cucina? Troppo tardi.

Gli insetti non fissati hanno la brutta abitudine di tornare a perseguitarti se lasciati per un certo periodo di tempo. Poiché la maggior parte verrà introdotta come parte di uno sviluppo, il momento migliore per risolverli è mentre sono ancora freschi nella mente della squadra / persona che li ha introdotti. Una volta lasciato a sedere per un po ', nessuno ricorderà nulla di quel pezzo di codice, il che aumenta solo entrambi il costo e il rischio di provare a risolverlo.

risposta data 07.04.2016 - 13:30

fonte

Leggi altre domande sui tag development-process planning

Java 8: cosa fa un ritorno vuoto in un costruttore? Aggiorna la versione secondaria di Semver sugli aggiornamenti di test?

score 5 · Accepted Answer

Con risorse limitate, le correzioni dei bug dovrebbero essere prioritarie rispetto a qualsiasi altro lavoro (richieste di funzionalità, miglioramenti delle prestazioni, miglioramenti UX, nuove piattaforme ....).

Non sottovalutare l'impatto della scarsa qualità sui tuoi utenti o del debito tecnico sulla tua velocità complessiva. Ma realisticamente, alcune correzioni non valgono lo sforzo ingegneristico - o non vale la pena deviare le risorse da quella nuova funzionalità su cui tutti stanno lavorando.