Classificare attività / bug in base al rischio di modifiche

Il progetto a cui sto attualmente lavorando ha un problema: i bug e i compiti sono spesso assegnati a persone che sono troppo nuove o troppo inesperte e il loro lavoro finisce per produrre più bug lungo la strada. Il problema è che parti del nostro software sono molto più "pericolose" su cui lavorare rispetto ad altri a causa di problemi di qualità del codice. Ho cercato di combattere questo problema stimando il rischio associato alle attività e prestando molta attenzione a quali sviluppatori vengono assegnati a quali attività.

Usiamo JIRA quindi ho iniziato a etichettare i problemi per tenere traccia di questa stima. Ho notato che ho finito per utilizzare diverse metriche per classificare un bug / attività:

• Com'è chiaro / diretto. Ad esempio se si tratta di qualcosa che richiederà molto lavoro di progettazione o solo una semplice correzione di bug dell'interfaccia utente.
• Quanto è gestibile l'area interessata del codice. È un'area ben progettata o una grande palla di fango.
• Quanta parte del programma penso sarà influenzata dalla modifica richiesta.

Le mie etichette sono un po 'disordinate poiché non avevo un'idea chiara quando ho iniziato quali sarebbero le possibili categorie e ancora non lo so. Sto pensando di richiedere l'aggiunta di un nuovo campo (qualcosa come "Rischio") in modo che possiamo richiedere un preventivo prima di assegnare il lavoro a qualcuno.

Qualcuno ha già affrontato questo genere di cose prima?

Uno dei fallimenti della maggior parte degli approcci di tracciamento dei bug è che riguardano solo un lato dell'equazione: la visione del sistema da parte dell'utente finale. Questo è un bug critico che può essere risolto in questo modo può attendere una settimana (priorità), questo errore è doloroso per questo è un serrore di pluralizzazione (gravità).

Un post sul blog che descrive il tracciamento di bug multidimensionale affronta questo problema includendo la vista degli sviluppatori: PEF e REV.

I valori PEF sono l'opinione dell'utente:

• P ain - quanto sia doloroso è il bug quando si incontra?
• E ‍ffort: quanti sforzi ci vogliono per aggirare?
• F requenza - quanto spesso si verifica l'errore?

Il lato REV è dal punto di vista dello sviluppatore:

• R ‍isk - quanto è rischiosa la correzione?
• E ‍ffort: quanti sforzi ci vorranno per risolvere?
• V ‍erificabilità: quanto è facile verificare che il bug sia stato corretto?

Ognuno di questi è misurato su una scala 1..9 con 1 basso / facile e 9 alto / difficile. I numeri vengono sommati per dare un punteggio a PEF e REV.

La parte che indirizza i bit descritti:

• Com'è chiaro / diretto. Ad esempio se si tratta di qualcosa che richiederà molto lavoro di progettazione o solo una semplice correzione di bug dell'interfaccia utente.
• Quanto è gestibile l'area interessata del codice. È un'area ben progettata o una grande palla di fango.
• Quanta parte del programma penso sarà influenzata dalla modifica richiesta.

Questi fattori contribuiscono allo sforzo e al rischio descritti in REV.

Sì, è qualcosa con cui si è già combattuto. Ho usato (in passato) questo modello per campi personalizzati in Redmine ed è stato ragionevolmente successo.

Il grande vantaggio di questo si presenta quando si confrontano i punteggi PEF e REV. Se hai un PEF di 21 e un REV di 7, è qualcosa che può essere una grande vittoria. Mentre un PEF di 7 e REV di 21 è qualcosa che dovrebbe essere evitato per un po 'perché il rischio e lo sforzo probabilmente superano i benefici che lo fissano.

Si può quindi guardare il punteggio REV e assegnare le cose a basso rischio agli sviluppatori meno esperti (basso rischio, alto sforzo sono spesso ideali per questa situazione).

Direi che ciò a cui ti riferisci qui potrebbe essere meglio chiamato "complessità". Naturalmente, più un cambiamento è complesso, maggiore è il "rischio" che alcuni programmatori inesperti possano introdurre alcuni nuovi bug. Non è una cattiva idea introdurre un campo del genere se si tratta di un vero problema.

Tuttavia, a giudicare da ciò che hai scritto sembra che tu abbia due problemi:

1. Hai a che fare con programmatori nuovi o inesperti.
2. La qualità di (molto / alcuni) del tuo codice sembra essere discutibile.

Oltre a introdurre qualcosa di simile a un campo di "complessità" (che contribuirebbe a gestire e dare priorità al tuo lavoro), ti suggerirei di concentrarti sulla mitigazione del rischio di questi due problemi.

Per risolvere il primo problema, vorrei creare un processo in base al quale i nuovi programmatori discutono innanzitutto tutti i nuovi bug con un programmatore più esperto prima di lavorare sul bug. Inoltre, introdurrò sicuramente le revisioni del codice sia per ridurre il rischio di introduzione di nuovi bug sia da utilizzare come opportunità di coaching per i nuovi programmatori per accelerare più rapidamente.

Per quanto riguarda la qualità del codice, farei due cose. Innanzitutto, fermare il processo di decomposizione: concordare standard e pratiche di codifica che impedirebbero l'introduzione di qualsiasi nuovo codice inferiore. Le recensioni di codice suggerite potrebbero essere utili anche qui. In secondo luogo, vorrei identificare le parti peggiori del tuo codice e iniziare a refactoring e ripulirle.

Sì, è una buona idea non dare problemi agli sviluppatori inesperti che sono troppo complessi. Ma il rovescio della medaglia è che se lasci che facciano solo le cose facili, allora non impareranno.

Suggerisco una strategia alternativa è quella di istituire un regime di revisioni del codice. Lascia che i neofiti lavorino sul lavoro sulle cose difficili (entro limiti ragionevoli), ma rivedi a fondo il loro lavoro.

A breve termine, questo è più lavoro per tutti. A lungo termine, ti ritroverai con un intero team di sviluppatori in grado di gestire le cose complesse, E sono "sulla stessa pagina" per quanto riguarda la qualità del codice.