Відстеження багів у Planfix: готова конфігурація
Відстеження багів у Planfix не вимагає окремого баг-трекера: уся робота команди вміщується в один планувальник Planfix, де кожен співробітник створює багрепорт, а розробники й тестувальники самі розбирають завдання. Поки баги живуть у чатах, скриншотах і листах, частина з них губиться, а про стан виправлення знає лише той, хто його робить. Відео нижче (5:36) показує готову конфігурацію «Відстеження багів» — від створення багрепорту до деплою.
Що ви дізнаєтеся з відео
- з яких списків складається планувальник відстеження багів;
- як створити багрепорт зі списку та які два поля заповнити;
- чому опис бага варто будувати на словах-мітках і зберегти їх у шаблоні;
- як розробник бере баг собі й надсилає його на виправлення;
- як передати завдання на кодрев’ю, тестове складання й тестування;
- що зробити з багом після деплою, щоб список не захаращувався.
Як налаштувати планувальник для багів
Уся конфігурація — це один планувальник зі списками-етапами. Співробітники створюють багрепорти в одному з двох перших списків, а далі завдання рухається від списку до списку, аж поки баг не буде виправлено.
Крок 1. Зберіть списки етапів в одному планувальнику
Робота зосереджена в одному планувальнику: у ньому є список підозра на баг, перевірити для свіжих звернень і список баг підтверджено, потрібен виконавець. Багрепорт можна створити в будь-якому з цих двох списків, і саме їх проглядають розробники й тестувальники, коли вибирають завдання собі. Далі йдуть списки взятих у виправлення багів, кодрев’ю, тестового складання, тестування, деплою та готово, баг виправлено — кожен список показує, на якому етапі стоїть баг.
Крок 2. Налаштуйте шаблон багрепорту
Щоб створити багрепорт, натисніть плюс у списку підозри на баг: відкриється форма, у якій потрібно заповнити два поля — назва та опис. Назву варто зробити максимально зрозумілою, а опису приділити найбільше уваги, щоб розробник не витрачав час на уточнення якихось моментів і відтворення бага. В описі допомагають слова-мітки, виділені жирним шрифтом: їх можна одразу додати до шаблону завдання по багрепорту, щоб постановник орієнтувався за ними. Якщо баг вимагає негайної уваги, вкажіть це у відповідному полі.
Крок 3. Додайте всіх співробітників в аудитори
У кожному завданні по багу до аудиторів додано групу всі співробітники. Так усі розробники й тестувальники одразу бачать усі завдання щодо багів і можуть вибрати найбільш зрозумілі для себе. Якщо у вас є робочі групи лише з розробників або лише з тестувальників, додайте їх до шаблону.
Крок 4. Дайте розробнику взяти баг собі
Планувальник доступний розробнику, і він бачить усі завдання з двох перших списків. Щоб узяти баг, розробник переводить завдання в статус підтвердженого бага й ставить себе у виконавці: натискає іконку поля завдання та вибирає себе. Далі він надсилає завдання на виправлення — воно з’являється у списку взятих у роботу багів з іконкою виконавця, тож усім видно, що баг уже кимось узято. Перемикати етапи зручно кнопками зміни статусу: для кожного статусу налаштовують окрему кнопку.
Крок 5. Проведіть баг через кодрев’ю, тестування й деплой
Коли роботи над багом завершено, напишіть коментар зі сповіщенням потрібного співробітника й переведіть завдання на наступний етап — кодрев’ю. Старший розробник отримує повідомлення та бачить завдання у списку виправлених багів: якщо все гаразд, він відправляє його на тестове складання, якщо знайдено помилки — повертає на доопрацювання. Тестувальник так само ставить себе у виконавці й переводить завдання на етап тестування, після чого баг іде або на доопрацювання, або на деплой. На етапі деплою можна оновлювати робочу версію застосунку, а на етапі готово, баг виправлено — повідомити постановника та всіх зацікавлених осіб, що все готово. Після цього завершіть завдання, щоб воно не захаращувало список.
Статуси завдання: шлях бага в планувальнику
Етапи в цій конфігурації — це статуси завдання, а списки відбирають завдання за ними. Переводити завдання з етапу на етап можна не тільки кнопками, але й перетягуванням: у Планувальнику Planfix переміщення завдання в інший список змінює його параметри на ті, за якими в цей список відбираються завдання. Якщо команда звикла до канбану, той самий процес можна вести на Agile-дошках Planfix.
Приклад із відео: баг проходить усі статуси
У відео співробітник створює багрепорт у списку підозри на баг. Розробник знаходить завдання, переводить його в статус підтвердженого бага, ставить себе у виконавці й надсилає баг на виправлення. Коли код готовий, він коментарем викликає старшого розробника на кодрев’ю — той переводить завдання на тестове складання. Тестувальник бере завдання собі, тестує його й переводить на деплой, бо помилок немає. Останній крок — повідомити постановника, що все готово, і завершити завдання.
Кому це потрібно
- Розробники: беруть собі зрозумілі баги з двох перших списків, без ручного розподілу завдань;
- Тестувальники: бачать окремий список завдань, які слід протестувати, і повертають баг на доопрацювання однією кнопкою;
- Старші розробники: проводять кодрев’ю в завданні та за потреби самі розподіляють баги між виконавцями;
- Підтримка та постановники: створюють багрепорт за шаблоном і бачать, на якому етапі виправлення.
Часті запитання (FAQ)
Чи потрібен окремий баг-трекер, якщо є Planfix?
Ні. У конфігурації «Відстеження багів» уся робота зосереджена в одному планувальнику: там створюють багрепорти, беруть їх у виправлення, проводять кодрев’ю, тестування й деплой. Баги живуть у тій самій системі, що й решта завдань команди.
Хто бачить завдання по багах?
У кожному завданні по багу до аудиторів додано групу «всі співробітники», тому розробники й тестувальники одразу бачать усі баги та можуть вибрати завдання для себе. Якщо потрібно звузити коло, додайте до шаблону окремі робочі групи — наприклад, лише розробників або лише тестувальників.
Як передати баг на кодрев’ю?
Напишіть у завданні коментар зі сповіщенням потрібного співробітника, надішліть його й переведіть завдання на наступний етап. Старший розробник побачить баг у списку виправлених і далі або відправить його на тестове складання, або поверне на доопрацювання.
Спробуйте відстеження багів у себе
Почніть з одного планувальника: зберіть у ньому списки етапів, налаштуйте шаблон багрепорту й домовтеся, що розробник ставить себе у виконавці, перш ніж братися за код. Поруч буде корисно подивитися, як планувальник допомагає навести лад у завданнях. Якщо Planfix ще не ваш робочий інструмент, створіть акаунт і проведіть перший баг усіма етапами на своїх даних.
