Таска и тикет — что это, системы трекинга и работа с задачами

Что такое таска и тикет?

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

Тикет (от англ. ticket — билет, обращение) — более широкая сущность. Тикетом может быть баг-репорт («Приложение падает при повороте экрана на 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), рефакторинг (Migration с 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 фикс бага), в 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/mater, прошёл тестирование, готова к релизу. Некоторые команды добавляют статус 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, первый-class поддержка клавиатурных шорткатов, встроенный 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 таску на каждый Features-спринт. Пропорция: на каждые 3 Feature-таски — 1 Tech Debt или Bug. Это предотвращает накопление техдолга и сохраняет скорость разработки.