Что в имени тебе моем...

Что в имени тебе моем...

В любом программном проекте сегодня внедрена та или иная система отслеживания дефектов, она же баг-трекер. Bugzilla, Jira, GitLab / GitHub - популярные продукты этого типа. Увы, большинство команд до сих пор не умеют нормально именовать и переименовывать баги.

Название дефекта - это строка, которая видна в большинстве списков и отчетов. Это 7-15 слов, в которых надо выразить квинтэссенцию проблемы. Каждое слово в названии бага - на вес золота. Если бы баг был Москвой, то его название было бы Рублевским шоссе. Тем не менее, названия дефектов вроде "Проблема с генерацией отчета" встречаются сплошь и рядом. Это не информативно и не полезно.

Название бага должно быть кратким, но плотным в плане информации. Очень рекомендую учиться у авторов новостных заголовков: "У жившего в Африке 100 тысяч лет назад человека нашли воспаление внутреннего уха" и так далее. Такие названия дают быстрое понимание того, о чем статья и может ли она быть интересна зрителю. С учетом этого более удачным названием для примера выше было бы "При запуске отчета из меню появляется сообщение об ошибке сети".

Название бага должно быть полным. Если есть важные детали, их надо отразить. Например, если ошибка начала появляться недавно, это надо включить - "При запуске отчета из меню вдруг стало появляться сообщение об ошибке сети". Если ошибка воспроизводится не всегда, это надо описать - "При запуске отчета из меню вдруг иногда стало появляться сообщение об ошибке сети". Если ошибка проявляется только при определенных условиях, это надо упомянуть - "При запуске отчета из меню в Chrome вдруг иногда стало появляться сообщение об ошибке сети". Иметь доступ к этим важным деталям прямо в заголовке ошибки очень полезно. Если вам покажется, что заголовок стал слишком длинным, помните - любой технический текст это как багажник автомобиля перед поездкой в отпуск: когда кажется, что забит полностью, туда можно путем перекладываний и перетрясываний упаковать еще столько же. Для нашего примера название можно сократить до "Меню 'отчет' в Chrome стало иногда падать с ошибкой сети", это 10 слов вместо 15 без потери информации. Но, как правило, этого не требуется - мутные короткие названия багов это гораздо более частая проблема, нежели ясные, но слишком длинные.

Название бага должно быть актуальным. Если оказалось, что дефект воспроизводится не иногда, а всегда, просто условия более хитрые, баг надо переименовать - "Меню 'отчет' в Chrome падает с ошибкой сети на плохом соединении". Почему-то часто мы боимся менять названия дефектов, словно они высечены в камне. Особенно, если этот баг придуман не нами. Друзья, не бойтесь - переименовывайте дефекты сколько нужно, лишь бы название отражало действительность и в каждый момент времени было мини-спойлером всего расследования, коим каждый баг является.

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

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

В конце замечу две вещи. Во-первых, хотя речь и идет о багах, все то же самое применимо к agile планированию - epics, stories, tasks и так далее. Там есть свои нюансы в плане измеряемости (например, из названия story должно быть понятно, как будет выглядеть ее демо), но суть в целом та же. Во-вторых, все это относится в большей степени к проектам размера выше среднего - скажем, начиная от 100 и выше дефектов / stories. И особенно актуально, когда количество переваливает за 500 - из моего опыта это тот порог, за которым начинается хаос и путаница, если команда не будет активно положение дел упорядочивать.