Categorizza compiti / bug a rischio di modifiche

Uno dei difetti della maggior parte degli approcci di tracciamento dei bug è che si occupano solo di una parte dell'equazione: la visione dell'utente finale del sistema. Questo è un bug critico per risolvere il problema può aspettare una settimana (priorità), questo bug è doloroso per questo è un s in un glitch di pluralizzazione (gravità).

Un post sul blog che descrive il monitoraggio dei bug multidimensionale esamina questo aspetto includendo la vista sviluppatore: PEF e REV.

I valori PEF sono la vista dell'utente:

• P ain - quanto è doloroso il bug quando viene rilevato?
• E ffort: quanto impegno ci vuole per aggirare?
• F requisito: con quale frequenza si verifica il bug?

Il lato REV è dalla vista dello sviluppatore:

• R isk: quanto è rischiosa la correzione?
• E ffort: quanto impegno ci vorrà per risolvere?
• V erifiability - quanto è facile verificare che il bug sia corretto?

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

La parte che indirizza i bit descritti:

• How clear/straightforward it is. E.g. whether it's something that will need a lot of design work or just a simple UI bug fix.
• How maintainable the affected area of the code is. Is it a well-designed area or a big ball of mud.
• How much of the program I think will be affected by the required change.

Questi fattori nello sforzo e nei rischi descritti in REV.

Sì, è qualcosa con cui è stato combattuto prima. Ho usato (in passato) questo modello per i campi personalizzati in Redmine e ha avuto un discreto successo.

Il grande vantaggio di questo arriva quando si confrontano i punteggi PEF e REV. Se hai un PEF di 21 e un REV di 7, questo è 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 lato rischio e sforzo probabilmente superano i benefici che lo risolvono.

Si può quindi guardare il punteggio REV e assegnare cose con 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, più alto è il rischio che qualche nuovo bug possa essere introdotto da un programmatore inesperto. Non è una cattiva idea introdurre un tale campo se è 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 aiuterebbe a gestire e dare la priorità al tuo lavoro), ti suggerirei di concentrarti sulla mitigazione del rischio dei due problemi precedenti.

Per affrontare il primo problema vorrei creare un processo in cui i nuovi programmatori prima discuteranno tutti i nuovi bug con un programmatore più esperto prima di lavorare sull'errore. Inoltre, introdurrò sicuramente le revisioni del codice per ridurre il rischio di nuovi bug introdotti e utilizzare come opportunità di coaching per i nuovi programmatori per accelerare la velocità.

Riguardo alla qualità del codice, farei due cose. In primo luogo, interrompere il processo di decomposizione: concordare norme e pratiche di codifica che impedirebbero l'introduzione di nuovi codici inferiori. Le recensioni di codice suggerite potrebbero essere d'aiuto anche qui. In secondo luogo, identificherei le parti peggiori del tuo codice e inizierei a refactoring e pulizia di questi.

Sì, è una buona idea non dare a sviluppatori inesperti problemi troppo complessi. Ma il rovescio della medaglia è che se gli permetti solo di fare le cose facili, allora non impareranno.

Suggerisco che una strategia alternativa sia istituire un regime di revisione del codice. Lascia che i neofiti lavorino per lavorare su cose difficili (entro limiti ragionevoli), ma riesamina attentamente il loro lavoro.

A breve termine, questo è più lavoro per tutti. A lungo termine, finirai 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.