Класифікуйте завдання / помилки за ризиком змін

Проект, над яким я зараз працюю, має проблему: помилки та завдання часто призначаються людям, які є занадто новими або занадто недосвідченими, і їх робота призводить до появи нових помилок у дорозі. Проблема полягає в тому, що частини нашого програмного забезпечення набагато "небезпечніше" працювати, ніж інші, через проблеми якості коду. Я намагаюся боротися з цією проблемою, оцінюючи ризик, пов’язаний із завданнями, і пильно приділяю увагу розробникам, які отримують завдання.

Ми використовуємо JIRA, тому я почав проблематику з маркуванням, щоб відстежувати цю оцінку. Я помітив, що в кінцевому рахунку я використовував кілька показників, щоб класифікувати помилку / завдання:

• Наскільки це чітко / прямо. Наприклад, чи це щось, для чого знадобиться багато дизайнерських робіт, чи просто просте виправлення помилок в інтерфейсі.
• Наскільки ретельним є область дії коду. Це добре спроектована зона чи велика кулька грязі.
• Яка частина програми, на мою думку, вплине на необхідні зміни.

Мої етикетки такі безладні, оскільки я не мав чіткого уявлення, коли почав, що це за можливі категорії, а я досі цього не роблю. Я думаю про те, щоб запросити нове поле (щось на зразок "Ризик"), щоб ми могли вимагати оцінки перед тим, як присвоїти роботу комусь.

Хтось раніше займався подібними справами?

Однією з недоліків більшості підходів відстеження помилок є те, що вони мають справу лише з однією стороною рівняння - уявленням кінцевого користувача про систему. Це критична помилка, яку потрібно виправити, може зачекати тиждень (пріоритет), ця помилка болюча для цьогоs глюк плюралізації (тяжкість).

Повідомлення в блозі, що описує багатовимірне відстеження помилок розглядає цю проблему, включаючи перегляд розробника: PEF та REV.

Значення PEF - це перегляд користувача:

• P ‍ain - наскільки болюча помилка, коли вона зустрічається?
• E ‍ зусилля - скільки зусиль потрібно для того, щоб обійтись?
• F ‍частота - як часто виникає помилка?

Сторона REV - це з точки зору розробника:

• R ‍isk - наскільки ризиковано виправлення?
• E ‍ зусилля - скільки зусиль доведеться виправити?
• V Перевірка - як легко перевірити, що помилка виправлена?

Кожен з них вимірюється за шкалою 1..9, 1 - низький / легкий, а 9 - високий / важкий. Номери додаються разом, щоб дати бал за PEF та REV.

Частина, що стосується описаних бітів:

• Наскільки це чітко / прямо. Наприклад, чи це щось, для чого знадобиться багато дизайнерських робіт, чи просто просте виправлення помилок в інтерфейсі.
• Наскільки ретельним є область дії коду. Це добре спроектована зона чи велика кулька грязі.
• Яка частина програми, на мою думку, вплине на необхідні зміни.

Ці чинники зусиль та ризику описані в REV.

Так, це щось, з чим боролися раніше. Я (в минулому) використовував цю модель для користувацьких полів Redmine, і вона була досить успішною.

Велика перевага цього полягає у порівнянні балів PEF та REV. Якщо у вас PEF 21 і REV 7, це щось, що може стати великим виграшем. Хоча PEF з 7 та REV 21 - це те, чого слід уникати на деякий час, оскільки сторона ризику та зусиль, ймовірно, переважає над користю, яка його фіксує.

Потім можна переглянути оцінку REV і призначити речі з низьким ризиком менш досвідченим розробникам (низький ризик, великі зусилля часто ідеальні для цієї ситуації).

Я б сказав, що те, про що ви тут звертаєтесь, краще назвати «складність». Звичайно, чим складнішою є зміна, тим вище "ризик" полягає в тому, що якийсь новий помилку може ввести недосвідчений програміст. Непогано запровадити таке поле, якщо це справжнє питання.

Однак, судячи з написаного, у вас, здається, є два питання:

1. Ви маєте справу з новими або недосвідченими програмістами.
2. Якість вашого коду (багато / деякого) здається сумнівною.

Окрім того, щоб запровадити щось на кшталт поля «складності» (яке допомогло б керувати та визначити пріоритетною вашою роботою), я б запропонував вам зосередитись на зменшенні ризику вищевказаних двох питань.

Для вирішення першого питання я створив би процес, коли нові програмісти спочатку обговорюють усі нові помилки з більш досвідченим програмістом, перш ніж працювати над помилкою. Крім того, я обов'язково запроваджую огляди коду, щоб знизити ризик введення нових помилок і використовувати як тренерську можливість для нових програмістів швидше набирати швидкість.

Щодо якості коду, я би зробив дві речі. По-перше, зупиніть процес гниття: домовтеся про стандарти та практики кодування, які б перешкоджали введенню будь-якого нового неповноцінного коду. Пропоновані відгуки про код також допоможуть тут. По-друге, я б визначив найгірші частини вашого коду і почав би рефакторинг та очищення.

Так, непогано не доставляти недосвідченим розробникам проблеми, які надто складні. Але зворотний бік полягає в тому, що якщо ти лише дозволиш їм робити легкі речі, вони не навчаться.

Я пропоную альтернативну стратегію - встановити режим перегляду коду. Нехай новачки попрацюють над хитромудрими речами (в межах розуму), але ретельно перегляньте їх роботу.

За короткий термін це більше роботи для всіх. У довгостроковій перспективі ви зіткнетеся з цілою командою розробників, які вміють обробляти складні речі, і "знаходяться на одній сторінці", що стосується якості коду.