Что такое управление дефектами? Серьёзность, приоритет и состояния между ними

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

У большинства команд он есть, записан он или нет. Незаписанный вариант обычно звучит как “заведи в трекере и надейся”, и он работает, пока дефектов не станет больше, чем кто-либо способен удержать в голове - как правило, около тридцати.

Жизненный цикл

В разных трекерах состояния называются по-разному, а форма под ними одна и та же.

• Новый. Заведён, никто ещё не смотрел.
• Отсортирован. Кто-то прочитал его, подтвердил, что он настоящий, и решил, насколько он срочный.
• Назначен. У него есть ответственный.
• Исправлен. Ответственный считает, что готово. Больше пока никто ничего не считает.
• Проверен. Кто-то, кроме ответственного, подтвердил это по исходному отчёту.
• Закрыт. Готово.

Есть ещё два законных финала, с которыми часто обращаются неправильно. Отклонён значит, что это не дефект: поведение задумано так, или в отчёте описано недоразумение. Отложен значит, что он настоящий и сейчас не исправляется. Для обоих нужна причина, записанная в задаче, потому что иначе тот же дефект заведут заново через шесть недель - тот, у кого нет способа узнать, что его уже рассматривали.

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

Серьёзность и приоритет - не одно и то же

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

Серьёзность - это насколько плохо само поведение. Потеря данных серьёзна. Съехавшая иконка нет. Это свойство самого дефекта, и оно не меняется оттого, что поменялся календарь.

Приоритет - это насколько скоро его исправят. Это решение бизнеса, и оно зависит от того, кого задевает, скольких, есть ли обходной путь и что ещё претендует на ту же неделю.

Эти два расходятся в обе стороны, и именно поэтому их стоит различать:

Высокая серьёзность, низкий приоритет

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

Низкая серьёзность, высокий приоритет

Название компании с опечаткой на странице тарифов, его видят все, исправлено этим утром

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

Кто сортирует и как часто

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

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

Сортировке нужны три ответа на дефект, и не больше: настоящий ли он, насколько он плох, чей он. Всё, что длиннее, - это проектирование, происходящее не на той встрече.

Отчёты решают, с какой скоростью идёт процесс

Каждое состояние после “нового” зависит от того, насколько хорош был отчёт.

Сортировка не может оценить серьёзность, не зная, что на самом деле произошло. Ответственный не может починить то, что не может воспроизвести. Проверка не может ничего подтвердить, если исходные шаги больше нигде не записаны. Расплывчатый отчёт стоит не просто пяти минут того, кто его завёл, - он стоит одного круга уточнений на каждом этапе, а каждый такой круг - это день.

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

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

Метрики, которые вводят в заблуждение

Три числа считают потому, что их легко посчитать, и каждое стоит читать внимательно.

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

Смотреть вместо этого стоит на долю переоткрытий: дефекты, помеченные исправленными, которые вернулись. Это прямое измерение того, значит ли “исправлено” что-нибудь в вашей команде, и, в отличие от остальных, её трудно подкрутить.

Коротко

Шесть состояний, записанная причина для всего отклонённого или отложенного и проверка, сделанная не тем, кто исправлял. Серьёзность - это насколько плохо, приоритет - насколько скоро, и это разные поля. Сортировка по расписанию, а не когда кто-то вспомнит. И большая часть сэкономленного времени экономится в самом начале, в отчёте: дефект, который пришёл полным, проходит весь процесс без единого вопроса.