Категоризация задач / ошибок по риску изменений

У проекта, над которым я сейчас работаю, есть проблема: ошибки и задачи часто назначаются людям, которые слишком новы или слишком неопытны, и их работа в конечном итоге приводит к появлению новых ошибок в будущем. Проблема в том, что с некоторыми частями нашего программного обеспечения работать гораздо опаснее, чем с другими, из-за проблем с качеством кода. Я пытался бороться с этой проблемой, оценивая риск, связанный с задачами, и обращая пристальное внимание на то, каким разработчикам назначены какие задачи.

Мы используем JIRA, поэтому я начал маркировать проблемы, чтобы отслеживать эту оценку. Я заметил, что в итоге я использовал несколько метрик для классификации ошибки / задачи:

• Насколько это ясно / понятно. Например, нужно ли много работать над дизайном или просто исправить ошибку в пользовательском интерфейсе.
• Насколько ремонтопригодна уязвимая область кода. Это хорошо продуманная территория или большой клубок грязи.
• На какую часть программы, я думаю, повлияет необходимое изменение.

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

Кто-нибудь имел дело с такими вещами раньше?

Одним из недостатков большинства подходов к отслеживанию ошибок является то, что они касаются только одной стороны уравнения - представления конечного пользователя о системе. Это критическая ошибка, которую нужно исправить, это может подождать неделю (приоритет), эта ошибка болезненна, поскольку это является sпроблемой множественного числа (серьезность).

В блоге, описывающем многомерное отслеживание ошибок, рассматривается этот вопрос, включая представление разработчика: PEF и REV.

Значения PEF являются представлением пользователя:

• P айн - насколько болезненным является ошибка , когда он встречается?
• E ffort - сколько усилий нужно , чтобы работать вокруг?
• F requency - как часто имеет место ошибка , ?

REV сторона с точки зрения разработчика:

• R --isk - насколько рискованно это исправить?
• E ffort - сколько усилий потребуется , чтобы исправить?
• V erifiability - как легко проверить , что ошибка исправлена?

Каждый из них измеряется по шкале 1,9, где 1 - низкий / легкий, а 9 - высокий / жесткий. Числа складываются вместе, чтобы получить оценку PEF и REV.

Часть, которая обращается к описанным битам:

• Насколько это ясно / понятно. Например, нужно ли много работать над дизайном или просто исправить ошибку в пользовательском интерфейсе.
• Насколько ремонтопригодна уязвимая область кода. Это хорошо продуманная территория или большой клубок грязи.
• На какую часть программы, я думаю, повлияет необходимое изменение.

Эти факторы в усилие и риск описаны в REV.

Да, с этим боролись прежде. Я (в прошлом) использовал эту модель для пользовательских полей в Redmine, и она была достаточно успешной.

Большое преимущество этого появляется, когда вы сравниваете баллы PEF и REV. Если у вас PEF 21 и REV 7, это может быть большой победой. Хотя PEF, равный 7, и REV, равный 21, - это то, чего следует избегать какое-то время, потому что сторона риска и усилий, вероятно, перевешивает выгоду, фиксирующую его.

Затем можно посмотреть на оценку REV и назначить вещи с низким уровнем риска менее опытным разработчикам (низкий риск, большие усилия часто идеально подходят для этой ситуации).

Я бы сказал, что то, на что вы ссылаетесь, лучше назвать «сложностью». Конечно, чем сложнее изменение, тем выше «риск» того, что неопытный программист может внести какую-то новую ошибку. Неплохая идея ввести такое поле, если это реальная проблема.

Однако, судя по тому, что вы написали, у вас, похоже, есть две проблемы:

1. Вы имеете дело с новыми или неопытными программистами.
2. Качество (много / немного) вашего кода кажется сомнительным.

В дополнение к введению чего-то наподобие поля «сложность» (которое поможет управлять и расставить приоритеты в вашей работе), я бы посоветовал вам сосредоточиться на уменьшении риска двух вышеупомянутых проблем.

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

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

Да, это хорошая идея - не давать неопытным разработчикам слишком сложные задачи. Но обратная сторона в том, что если вы позволите им делать легкие вещи, они не будут учиться.

Я предлагаю альтернативную стратегию - ввести режим проверки кода. Пусть новички поработают над хитрыми вещами (в пределах разумного), но тщательно проанализируют свою работу.

В краткосрочной перспективе это больше работы для всех. В более долгосрочной перспективе вы получите целую команду разработчиков, которые могут справиться со сложными вещами, и находятся «на одной странице» в том, что касается качества кода.