Які три форми списку в Jira?
Нативні прапорці в описі (і action items) — разовий punch-список на робочому елементі. Підзавдання — дочірні завдання зі своїм виконавцем, оцінкою, строком і workflow. Checklist for Jira тримає структурований список на батьківському елементі — шаблони, прогрес, валідатори — без зайвих завдань. Як додати цей список, показує посібник із чеклістів у Jira; ця сторінка — гід із рішення.
Жоден не є запасним варіантом. Три кроки перевірки від репортера живуть в описі. Дизайн-прохід іншої команди заслуговує підзавдання. Definition of Done, чекліст QA-тестування і runbook релізу живуть на батьківському елементі як чеклісти, щоб планка якості їхала зі story.
Чому обирати навмисно
Коли кожен рядок «ми згадали?» стає підзавданням, дошка заростає картками, які ніколи не мали бути завданнями. Коли планка якості живе лише в Confluence, її легко пропустити. Чекліст на робочому елементі — середній шлях: ті самі кроки щоразу, прогрес на завданні й у JQL, і все ще один батьківський елемент на шматок роботи.
Усі три на своїх місцях — виграш процесу. Intake лишається легким. Delivery тримає спільну планку відвантаження. Справжні шматки роботи й далі отримують дочірнє завдання. Checklist for Jira зроблено для списків, які ви повторюєте; Jira вже закриває решту.
Коли що використовувати
Прапорці в описі — для списку, який ви ніколи не перевикористовуєте. Чекліст — коли ті самі кроки з’являються на кожній story, багу чи change, особливо якщо потрібні шаблони, прогрес-бар або гейт на workflow. Відкривайте підзавдання, коли робота — справжній шматок: свій власник, оцінка й статус на дошці.
Поставте це на робочий елемент із Checklist for Jira
Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.
Поруч
| Потреба | Прапорці в описі | Checklist for Jira | Підзавдання |
|---|---|---|---|
| Володіння | Живе в описі; легко пропустити в довгому полі | На робочому елементі зі згадками й статусами пунктів | Свій виконавець на кожному дочірньому завданні |
| Незалежний workflow | Ні | Статуси пунктів: Open, In Progress, Blocked, Done | Повний workflow завдання, статус і переходи |
| Оцінки й строки | Ні | Дати й згадки на пунктах, не повна оцінка завдання | Story points, час, строк на дочірньому |
| Звітність на дошці | Ні | Прогрес на завданні, на дошках і в JQL | Кожне дочірнє — окрема картка |
| Легкий прогрес | Ручний перегляд опису | Прогрес-бар і лічильник завершення | Зведення дочірніх завдань |
| Шаблони | Ні | Проєктні й глобальні шаблони, включно з Protected | Лише шаблони завдань |
| Кілька списків на одному батьківському | Ні | Так — Done, QA і реліз можуть жити разом | Так, як окремі завдання |
| Валідація | Ні | Блокувати перехід, поки список (або іменований список) не завершено | Умови workflow на завдання |
| Автоматизація | Ні | Автододавання під час створення або статусу; Jira Automation apply / complete / reset | Jira Automation на завданнях |
| Навантаження | Найнижче — набір в описі | Панель на батьківському елементі, без зайвих завдань | Нове завдання на кожен шматок |
Коли підзавдання — слушний інструмент
Створюйте підзавдання, коли робота — справжній шматок роботи, а не перевірка якості. Дизайн-прохід іншої команди, міграція даних зі своєю оцінкою, security review з окремим workflow — це заслуговує дочірнього завдання. Чеклісти не замінюють це. Вони замінюють дюжину рядків «ми згадали?», які ніколи не мали бути завданнями.
Коли чекліст на батьківському елементі пасує краще
Тримайте Definition of Done і acceptance criteria як чеклісти на story, щоб планка відвантаження й обіцяна поведінка лишалися видимими разом. Вішайте чекліст QA-тестування, коли тестувальники ведуть прохід. Використовуйте Protected-шаблон, коли формулювання не має роз’їжджатися. Автозастосовуйте й вимагайте їх через посібник з автоматизації, щоб процес з’являвся без зайвих карток на дошці.
Приклади з delivery, QA й онбордингу
- Доставка: тримайте Definition of Done і acceptance criteria як чеклісти на story. Винесіть дослідження продуктивності в підзавдання зі своїм власником.
- QA: ганяйте чекліст QA-тестування на батьківському елементі. Відкривайте підзавдання лише коли падіння потребує окремого виконавця й workflow.
- Онбординг: Protected-чекліст на тікеті найму достатній для акаунтів, заліза й знайомств. Підзавдання доречне, коли IT має вести замовлення ноутбука як окрему роботу.
Поєднуйте з рештою delivery-набору
Коли будете готові повторно використовувати список, почніть із хаб шаблонів і зв’яжіть його з посібник з автоматизації. Нативні варіанти й те, як додати чекліст, покриває посібник із чеклістів у Jira. Підзавдання лишайте для роботи, яка заслуговує завдання; чеклісти — для процесу, який має лишатися на батьківському елементі.
Часті запитання
Чи варто заборонити підзавдання?
Підзавдання лишайте для роботи, яка справді є дочірнім завданням — свій виконавець, оцінка й workflow. Чекліст — для планки якості, яка має лишатися на батьківському елементі.
Прапорці в описі — це погано?
Це найшвидший дім для списку, який ви ніколи не перевикористовуєте. Переходьте на шаблон, коли ті самі кроки з’являються на кожній story.
Чи може одна story мати чеклісти й підзавдання?
Так — часто це здорова схема. Definition of Done і QA сидять на батьківському елементі. Дизайн-прохід або міграція стоїть поруч як підзавдання.
Коли рядок чекліста має стати підзавданням?
Коли в рядка з’являються власник, оцінка й статус, який дошка має показати окремою карткою. Доти тримайте його на батьківському елементі, щоб планка якості лишалася одним прогрес-баром.
Поставте це на робочий елемент із Checklist for Jira
Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.