ГКЧП - Где, Как, Что Править?

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

Самописная система ведения задач была удобна, но недостаточна для распределённой команды. Поэтому был выполнен переход на Jira. Каждому продукту было присвоено своё имя в BTS (Bug Tracking System), а несколько глобальных модулей (код исправляется в одном скрипте, а при компиляции каждого продукта исправления автоматически попадают в билды) были перенесены из старой BTS в новую в продукт Global Modules, также задачи по сайту были импортированы в отдельный продукт Jira.

В старой BTS возможно было использовать единый список версий продуктов, а для закрытия багов приписали небольшой интерфейс. В Jira, к сожалению, нет возможности использовать сквозной список версий продуктов, поэтому в продукте Global Modules приходится создавать дубликаты номеров билдов по каждому скомпилированному продукту (но этот утомительный ручной труд был автоматизирован спустя 3 года мучений).

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

ГКЧП

или Как Правильно Читать баГ/импрув?

Где, Как, Что Править?


ГДЕ

* Определяем продукты, в которых надо фиксить. Это видно из номера:

     Prod_1-[issuenumber] - только в Product_1;

     Prod_2-[issuenumber] - в Product_2 и может быть в Product_3;

     Prod_3-[issuenumber] - в Product_3 и скорее всего в Product_2;

     GM-[issuenumber] - в Product_1, Product_2, Product_3 и может быть на сайте;

     WEB-[issuenumber] - на сайте и может в Product_1, Product_2, Product_3

* Определяем модуль или функционал, как часть продукта. Это видно из поля Component.

* Определяем список версий, в которых нужно внести исправления. Для этого на сайте смотрим номер текущей версии (Support -> Release History -> [ProductName]) и сравниваем его с номером билда, в котором выявлен баг/импрув. Это видно по значению поля Affect Versions. Если баг/импрув из числа GM, то номер Affects Versions префиксован кратким наименованием продукта. Если номер версии совпадает с точностью до релиза, то правку вносим только в текущие поддерживаемую и разрабатываемую. Если версия отлична по Мажору/Минору, то сверяемся в поле Label по наличию значений FIX_IN_PREV_VER и/или FIX_IN_OFFICIAL_VER.

* О том, нужен ли фикс в предыдущей версии или в будущей-разрабатываемой версии говорит поле Label со значениями FIX_IN_PREV_VER и/или FIX_IN_OFFICIAL_VER.


ЧТО

* Определяем объём работ по совокупности значений полей Summary, Description, Attachments. Обычно структура Descriptionнижеследующая:

     [Шаг / Модуль]

     [Пункт / Страница]

     [Что не так?]

     [При каких условиях?]

     Как должно быть?]

         example:

         [Шаги примера]


* Пояснительный скриншот или лог бага, или длинный пример хранится в поле Attachments (атач).

* У кого уточнить детали бага/импрува видно из полей BUG_HUNTER или Reporter.


ПРАВИТЬ/ПРОВЕРЯТЬ

* Если фикс был возвращен на доработку, то в поле Comments имеется причина.

* Проверять фикс надо как с default настройками, так и с описанными в Description или Environment.

Комментариев нет:

Отправить комментарий