Улучшение производительности до 1 исправления ошибки на человека / день

Question

Я старший инженер-программист, и несколько месяцев назад меня попросили помочь с координацией исправлений ошибок. Менеджер проекта (не технический) поставил перед собой задачу повысить производительность до 1 исправления ошибки на человека / день. Это было настоящим испытанием, и я хотел бы знать, что могли бы сделать другие разработчики / менеджеры, чтобы улучшить показатели исправления ошибок.

Некоторые факторы, которые играют роль в этой ситуации:

• команда географически распределена (Европа, Азия, Австралия), 10-20 разработчиков в каждой области
• большая кодовая база, с которой я не так хорошо знаком, поскольку я работаю в компании всего 9 месяцев
• для исправления ошибок выделяются только наименее опытные разработчики, большинство способных разработчиков работают над улучшениями
• мы следуем гибкому подходу, поэтому используем контроль исходного кода, непрерывную интеграцию, базу данных ошибок, у проекта есть расписание и спецификации для новой работы, у нас есть тестеры и мы проводим тестирование удобства использования
• наш код зависит от множества внутренних и сторонних компонентов / библиотек
• Менеджер программ имеет несколько старых метрик исправления ошибок, показывающих исправление ошибок 0,7 на человека / день. Меня беспокоит то, что это основано на команде опытных разработчиков, работающих над прототипом, исправляющих ошибки в коде, который они сами написали. Сейчас я координирую команду разработчиков, которые не знакомы с кодом, а ошибки происходят из команды проверки.

Еще немного информации после прочтения первых нескольких ответов:

• Я пытался возразить против использования метрики производительности с исправленными ошибками, не слишком далеко зашел с этим подходом
• все ошибки имеют приоритет (1-5), включают серьезность (1-5) и помечены дополнительной информацией (например, ЗАБЛОКИРОВАНЫ другой ошибкой, СБОЙ, НЕВОЗМОЖНЫ и т.д.)
• у большинства ошибок написан тестовый блок, когда они исправлены
• ошибки в определенной области кода распределяются для людей, знакомых с этой областью, если это возможно
• коэффициенты исправления ошибок отслеживаются для каждой команды, а история исправлений сохраняется
• в ежедневных вставках я пытаюсь заставить людей двигаться, спрашивая о блокировании проблем и их решении
• весь новый код написан с помощью модульных тестов
• да, я делал все возможное, чтобы улучшить метрику производительности различными способами - закрывая старые не относящиеся к делу ошибки, создавая и исправляя ошибки для проблем, которые в противном случае были бы решены без отчета об ошибках

• Я разработал скрипты Python, которые напрямую обращаются к базе данных ошибок, чтобы автоматизировать некоторые обычные аспекты управления ошибками и для создания отчетов

Answer 1

Я думаю, что хорошей отправной точкой является систематизация процесса исправления ошибок. Если вы используете <1 баг / день, я предполагаю, что ваша кодовая база велика, и эти ошибки трудно найти / воспроизвести. Я бы начал с некоторого анализа </p>

1) Как долго понимать ошибку

2) Как долго можно найти / воспроизвести

3) Какой код исправляется (здесь есть шаблон)

4) когда вы исправляете, добавляете ли вы еще один юнит-тест

5) Вы просматриваете личность и команду, в которой происходят ошибки

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

Answer 2

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

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

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

Answer 3

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

Они выполняют реальную работу, и вполне разумно, чтобы у них было больше информации о узких местах.

Answer 4

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

Постарайся не дать людям застрять. Если у кого-то есть проблема и она никуда не идет, попросите его помочь и встать на правильный путь.

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

Вы всегда можете намеренно добавлять ошибки и исправлять их.