Задача и тикет — какво е това, системи за проследяване и работа със задачи

Какво е задача и тикет?

Задача (от англ. task) — единица работа, регистрирана в система за проследяване. Съдържа описание, приоритет (Critical, High, Medium, Low), изпълнител, краен срок и статус. В мобилното разработване задача може да бъде „Добавяне на екран за профил с аватар”, „Реализиране на пагинация на поток” или „Актуализиране на версията targetSdk до 35”. Всяка задача е обвързана с проект, спринт и конкретен разработчик или екип.

Тикет (от англ. ticket) — по-широка същност. Тикет може да бъде доклад за грешка („Приложението се срива при завъртане на екрана на Android 14”), искане за функция („Добавяне на поддръжка за тъмна тема”), обръщение към техническа поддръжка („Push известието не пристига”) или задача от мениджър („Подготовка на отчет за честотата на сривове за месеца”). Разликата между задача и тикет е размита: в Jira и двете понятия са обединени в Issue. Ключова разлика: задачата винаги е работа с изпълнител, тикетът може да бъде искане без конкретен изпълнител до момента на триаж.

В Scrum и Kanban задачите са основен елемент на backlog. Всяка задача трябва да отговаря на критерия INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Независимите задачи могат да се реализират в произволен ред. Оценими — екипът може да прецени трудоемкостта. Малки — се побират в един спринт. Тестируеми — имат ясни критерии за приемане. Големите задачи (епици) се разделят на по-малки части, докато не бъдат изпълнени всички критерии.

Видове задачи в мобилното разработване

Feature — нова функционалност на приложението. Пример: „Екран за вход чрез биометрия (Face ID / Touch ID)”. Feature задачите винаги са свързани с потребителска история и имат Критерии за приемане. Оценка — в story points (1, 2, 3, 5, 8, 13). Bug — дефект, открит в процеса на разработване или тестване. Приоритетът на bug тикета се определя от severity (crash → Critical, UI-грешка → Medium, печатна грешка → Low). В мобилното разработване честота на сривове над 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 — голяма тема, обединяваща няколко истории. Пример: „Електронна търговия: кошница и завършване на поръчка”.

Жизнен цикъл на задача: от създаване до затваряне

Open (To Do) — задачата е създадена, но не е започната. Съдържа описание, Критерии за приемане, приоритет. В този статус задачата трябва да премине през груминг (уточняване и оценка) преди да влезе в спринт. In Progress — разработчикът е започнал работа. В мобилното разработване е важно да се свързват commit-и и pull request-и със задачата: в Jira чрез Smart Commits (APP-123 #comment коригиране на грешка), в GitHub/GitLab чрез ключови думи в описанието на PR (Closes APP-123).

In Review — кодът е изпратен за преглед. Автоматични проверки: CI (Gradle build, lint, unit тестове), SonarQube (качество на код), Danger (changelog, тестове). Разработчикът не може да започне следващата задача, докато текущата е в Review — това предотвратява многозадачността. QA / Testing — тестерът проверява на реални устройства (Android — различни версии на ОС и размери на екрани, iOS — различни модели iPhone). Ако бъдат открити грешки, задачата се връща в In Progress с коментар.

Done (Closed) — задачата е завършена: кодът е обединен в main/master, преминал е тестване, готов за пускане. Някои екипи добавят статус Deployed — задачата достига до потребителя едва след публикуване на билда в магазините. Важно е да затваряте задачите с коментар за резултата: коя версия, кой PR, какви метрики са се променили. Според данни на Linear (2025), екипите, които затварят задачи с описание на резултата, се връщат с 40% по-рядко към същите задачи.

Жизненият цикъл може да включва статус Blocked — задачата не може да бъде изпълнена поради външна зависимост (чакаме дизайн, отговор от backend, одобрение от мениджър). Blocked задачите трябва да имат коментар с причина и дата на следваща проверка. Седмичният преглед на Blocked задачите помага за идентифициране на системни забавяния в процеса на разработване. Блокерите, по-дълги от 2 седмици, изискват ескалация до нивото на продуктов мениджър.

Системи за проследяване на задачи

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

Linear — модерен тракер за продуктови екипи. Бърз интерфейс, първокласна поддръжка на клавишни комбинации, вграден Cycle (аналог на спринт), интеграция с GitHub и Slack. Предимства: скорост на създаване на задачи чрез CMD+K, автоматично разпределение по фази (Triaged → Backlog → Upcoming → Current → Completed), вградена документация и пътни карти. Linear се избира от стартъпи и продуктови екипи, които ценят скоростта на работа. През 2025 г. 40% от новите мобилни проекти използват Linear.

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

Най-добри практики за водене на задачи

Пишете Критерии за приемане — критериите за приемане трябва да бъдат конкретни и проверими. Лошо: „Екранът за вход работи”. Добре: „Потребителят въвежда имейл и парола, натиска Вход. Ако данните са верни — преминаване към главния екран. Ако са неверни — показва се грешка „Грешен имейл или парола””. Критериите за приемане (AC) са договор между разработчик, тестер и продуктов мениджър. Без AC задачата не отговаря на Definition of Ready (DoR) и не трябва да влиза в спринт.

Свързвайте всичко. Commit-и, 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 дни. Ако разработчикът оценява подзадачата по-дълго — режем още. Подзадачите са вътрешна техника на екипа, те не са видими в продуктовия backlog. Сумата от оценките на подзадачите не е задължително равна на оценката на родителската Story (част от работата — комуникация, code review, тестване).

Пирамида на декомпозиция: Epic (Тримесечие / Полугодие) → Feature / Story (Sprint) → Task (1-3 дни) → Sub-task (Няколко часа). Техника INVEST помага да проверите качеството на декомпозицията. Ако задачата не е Independent (зависи от други) — това е сигнал, че декомпозицията е неправилна. Ако задачата не е Small (повече от 8 story points) — трябва да се реже по-нататък. Често срещан модел: Epic → 5-15 Stories → всяка Story → 3-8 Sub-task-и. Крайната оценка на epica = сума от оценките на Stories, но първият спринт обикновено дава отклонение от 20-30% в оценките.

Типични грешки при работа със задачи

Грешка 1: твърде големи задачи. Задача за 2 седмици работа е epica, която трябва да бъде декомпозирана. Големите задачи не са подходящи за ежедневно проследяване, висят в In Progress със седмици. Правило: максимален размер на задачата — 2-3 дни работа. Всичко по-голямо — декомпозирайте. Страничен ефект: разработчикът чувства напредък, затваряйки 2-3 задачи седмично вместо една гигантска. Това повишава мотивацията и предвидимостта на сроковете.

Грешка 2: липса на Критерии за приемане. Разработчикът направи функцията, тестерът провери — всичко е наред. Мениджър: „А къде е бутонът за редактиране?” — „В задачата не е написано”. Без 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. Това предотвратява натрупването на технически дълг и поддържа скоростта на разработване.