Завдання і тікет — що це, системи трекінгу та робота з завданнями

Що таке завдання і тікет?

Завдання — одиниця роботи, зафіксована в системі трекінгу. Містить опис, пріоритет (Critical, High, Medium, Low), виконавця, дедлайн та статус. В мобільній розробці завданням може бути «Додати екран профілю з аватаром», «Реалізувати пагінацію стрічки» або «Оновити версію targetSdk до 35». Кожне завдання прив'язане до проєкту, спринту та конкретного розробника або команди.

Тікет — ширша сутність. Тікетом може бути баг-репорт («Додаток падає при повороті екрану на Android 14»), запит на фічу («Додати підтримку темної теми»), звернення в техпідтримку («Не приходить push-сповіщення») або завдання від менеджера («Підготувати звіт по crash rate за місяць»). Різниця між завданням і тікетом розмита: в Jira обидва поняття об'єднані в Issue. Ключова відмінність: завдання — це завжди задача з виконавцем, тікет — може бути запитом без конкретного виконавця до моменту тріажу.

В Scrum та Kanban завдання — основний елемент беклогу. Кожне завдання має відповідати критерію INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Незалежні завдання можна реалізувати в будь-якому порядку. Оцінювані — команда може прикинути трудомісткість. Маленькі — вкладаються в один спринт. Тестовані — є чіткі критерії приймання. Великі завдання (епіки) дробляться на більш дрібні до виконання всіх критеріїв.

Типи завдань в мобільній розробці

Feature — нова функціональність додатка. Приклад: «Екран входу по біометрії (Face ID / Touch ID)». Feature-завдання завжди прив'язані до user story і мають Acceptance Criteria. Оцінка — в story points (1, 2, 3, 5, 8, 13). Bug — дефект, знайдений в процесі розробки або тестування. Пріоритет bug-тікета визначається severity (crash → Critical, UI-баг → Medium, помилка → Low). В мобільній розробці crash rate вище 0.1% — критичний баг, вимагає негайного фіксу.

Tech Debt / Chore — технічні завдання без видимого користувачу ефекту: оновлення бібліотек (Dependency Bump), рефакторинг (Міграція з ViewPager на ViewPager2), налаштування CI/CD, написання тестів. Tech Debt завдання часто недооцінюються, хоча за даними Stripe 2025, до 30% часу мобільної команди йде на обслуговування та погашення техборгу. Ігнорування Tech Debt призводить до зростання багів та уповільнення розробки нових фіч.

Додаткові типи: Spike (дослідницьке завдання — вивчити нову технологію, написати POC), Task (будь-яка робота, не пов'язана з кодом — документація, дизайн-рев'ю), Improvement (покращення існуючої функціональності — оптимізація часу завантаження екрану). В Jira типи issues налаштовуються під проєкт. Стандартний набір для мобільної команди: Story, Bug, Task, Improvement, Epic. Epic — велика тема, що об'єднує кілька історій. Приклад: «E-commerce: кошик та оформлення замовлення».

Життєвий цикл завдання: від створення до закриття

Open (To Do) — завдання створено, але не розпочато. Містить опис, Acceptance Criteria, пріоритет. В цьому статусі завдання має пройти грумінг (уточнення та оцінку) перед потраплянням до спринту. In Progress — розробник почав роботу. В мобільній розробці важливо лінкувати коміти та pull request до завдання: в Jira через Smart Commits (APP-123 #comment fix баг), в GitHub/GitLab через ключові слова в описі PR (Closes APP-123).

In Review — код відправлено на рев'ю. Автоматичні перевірки: CI (Gradle build, lint, unit tests), SonarQube (code quality), Danger (changelog, тести). Розробник не може взяти наступне завдання, поки поточне в Review — це запобігає багатозадачності. QA / Testing — тестувальник перевіряє на реальних пристроях (Android — різні версії ОС та розміри екрану, iOS — різні моделі iPhone). Якщо баги знайдені — завдання повертається в In Progress з коментарем.

Done (Closed) — завдання завершено: код злито в main/master, пройшов тестування, готовий до релізу. Деякі команди додають статус Deployed — завдання дійде до користувача тільки після виходу білда в сторах. Важливо закривати завдання з коментарем про результат: яка версія, який PR, які метрики змінилися. За даними Linear (2025), команди, які закривають завдання з описом результату, на 40% рідше повертаються до тих самих задач.

Життєвий цикл може включати статус Blocked — завдання не може бути виконане через зовнішню залежність (чекаємо дизайн, відповідь від бекенду, апрув менеджера). Blocked завдання мають мати коментар з причиною та датою наступної перевірки. Щотижневе рев'ю Blocked-завдань допомагає виявляти системні затримки в процесі розробки. Блокери довше 2 тижнів вимагають ескалації на рівень менеджера продукту.

Системи трекінгу завдань

Jira — стандарт індустрії для команд від 10 осіб. Підтримує Scrum та Kanban дошки, розширене налаштування workflow, кастомні поля, автоматизації, інтеграцію з Bitbucket/GitHub. Недоліки: надлишковість для маленьких команд, повільний UI, складність конфігурації. Для мобільних проєктів Jira налаштовується за допомогою: плагіна Mobile-specific fields (Platform, OS version, Device model), інтеграції з TestFlight та Firebase Test Lab, автоматизації створення релізних білдів. Jira — вибір корпоративних проєктів з бюрократичними процесами.

Linear — сучасний трекер для продуктових команд. Швидкий UI, першокласна підтримка клавіатурних шорткатів, вбудований Cycle (аналог спринту), інтеграція з GitHub та Slack. Переваги: швидкість створення завдань через CMD+K, автоматичний розподіл по фазах (Triaged → Backlog → Upcoming → Current → Completed), вбудована документація та roadmaps. Linear обирають стартапи та продуктові команди, які цінують швидкість роботи. В 2025 році Linear використовують 40% нових мобільних проєктів.

Trello — проста канбан-дошка для маленьких команд (2–5 осіб). Картки з чек-листами, мітками, термінами. Недолік: немає спринтів, обмежена аналітика, складно масштабувати. YouGile — російський аналог Trello з канбан-дошками, чатом та відеодзвінками. Asana — трекер з фокусом на проєкти та таймлайни. Вибір трекера залежить від розміру команди, бюджету та вподобань: Jira для ентерпрайзу, Linear для продуктових команд, Trello/YouGile для стартапів. Важливо: інструмент має бути єдиним для всієї команди — дизайнери, розробники, QA, менеджери працюють в одній системі.

Кращі практики ведення завдань

Пишіть Acceptance Criteria — критерії приймання мають бути конкретними та перевіряваними. Погано: «Екран логіну працює». Добре: «Користувач вводить email та пароль, натискає Увійти. Якщо дані вірні — перехід на головний екран. Якщо невірні — показується помилка «Невірний email або пароль»». Acceptance Criteria (AC) — це контракт між розробником, тестувальником та продакт-менеджером. Без AC завдання не відповідає Definition of Ready (DoR) і не має потрапляти до спринту.

Лінкуйте все. Коміти, PR, тест-кейси, дизайн-макети (Figma), обговорення в Slack — все має бути прив'язано до завдання. В Jira це робиться через посилання в коментарях, в Linear — через автоматичну прив'язку PR. Правило одного кліка: від завдання до дизайну/коду/тестів — не більше одного кліка. Розробник відкриває завдання і одразу бачить макет в Figma, посилання на PR та тест-кейси. Це прискорює онбординг нових членів команди на 30% за даними Linear (2025).

Не створюйте завдання-привиди. Завдання без опису, без AC та без пріоритету — сміття. Якщо на щоденному стендапі ніхто не пам'ятає, навіщо створено завдання — його потрібно видалити або уточнити. Правило 48 годин: якщо завдання перебувало в статусі In Progress без активності 48 годин — розробник має залишити коментар про причини затримки. За даними Jira (2025), 60% завдань, що простоюють більше 3 днів, зрештою закриваються без виконання.

Декомпозиція завдань: епіки, юзер-сторі та підзадачі

Епік (Epic) — велика функціональна область, що об'єднує безліч історій. Приклад: «Онбординг користувача» включає «Екран привітання», «Вибір інтересів», «Завантаження аватара», «Налаштування сповіщень». User Story — задача з точки зору користувача. Формат: «Як [роль], я хочу [дію], щоб [цінність]». Приклад: «Як користувач, я хочу увійти по біометрії, щоб не вводити пароль щоразу». User Story пишеться продакт-менеджером або власником продукту.

Підзадача (Sub-task) — декомпозиція технічної роботи всередині Story / Task. Приклад для Story «Екран профілю»: Sub-task 1: Зверстати UI екрану (XML / SwiftUI), Sub-task 2: Зв'язати з ViewModel, Sub-task 3: Написати Unit-тести, Sub-task 4: Snapshot-тести, Sub-task 5: UI-тести (Espresso / XCUITest). Правило декомпозиції: кожна підзадача завершується за 1–2 дні. Якщо розробник оцінює підзадачу довше — ріжемо ще. Підзадачі — внутрішня техніка команди, вони не видимі в продуктовому беклозі. Сума оцінок підзадач не обов'язково дорівнює оцінці батьківської Story (частина роботи — комунікація, код-рев'ю, тестування).

Піраміда декомпозиції: Epic (Quarter / Half-year) → Feature / Story (Sprint) → Task (1–3 дні) → Sub-task (Кілька годин). Техніка INVEST допомагає перевірити якість декомпозиції. Якщо завдання не Independent (залежить від інших) — це сигнал, що декомпозиція неправильна. Якщо завдання не Small (більше 8 сторі-поінтів) — потрібно різати далі. Common pattern: Epic → 5–15 Stories → кожна Story → 3–8 Sub-tasks. Підсумкова оцінка епіка = сума оцінок Stories, але перший спринт зазвичай дає похибку 20–30% в оцінках.

Типові помилки при роботі з завданнями

Помилка 1: занадто великі завдання. Завдання на 2 тижні роботи — це епік, який потрібно декомпозувати. Великі завдання неможливо вбудувати в щоденний трекінг, вони висять в In Progress тижнями. Правило: максимальний розмір завдання — 2–3 дні роботи. Все що більше — декомпозувати. Побічний ефект: розробник відчуває прогрес, закриваючи 2–3 завдання на тиждень замість одного гігантського. Це підвищує мотивацію та передбачуваність термінів.

Помилка 2: відсутність Acceptance Criteria. Розробник зробив фічу, тестувальник перевірив — все ок. Менеджер: «А де кнопка редагування?» — «В завданні не написано». Без AC кожна сторона розуміє задачу по-своєму. Результат: переробка, конфлікти, зірвані терміни. AC — контракт: якщо в завданні немає критеріїв — воно не готове до спринту. На грумінгу першим ділом перевіряють наявність AC. Якщо AC немає — завдання відправляється на доопрацювання Product Manager-у.

Помилка 3: забуваємо про Tech Debt. Команда робить тільки Feature-завдання спринт за спринтом. Через півроку: збірка займає 15 хвилин, Gradle застарів на 3 мажорні версії, тести падають на CI через deprecation. Вихід: резервувати 20% часу команди на Tech Debt (Google SRE практика «SLO-based error budget»). Заводьте як мінімум одне Tech Debt завдання на кожен Feature-спринт. Пропорція: на кожні 3 Feature-завдання — 1 Tech Debt або Bug. Це запобігає накопиченню техборгу та зберігає швидкість розробки.