Регламент работы с техническими задачами

Стандарты декомпозиции, оформления, оценки и документирования тасков

Author

Services Task & Simulation Framework Documentation

Published

July 5, 2026

1. Классификация и типы задач

Для прозрачного планирования и автоматизации метрик (например, Velocity1) каждая задача в трекере должна иметь строго определенный тип. Основные категории:

  • Frontend (Фронтенд): Задачи на разработку пользовательского интерфейса (веб или мобильные приложения). Включают верстку, реализацию клиентской логики, интеграцию со сторонними API и управление локальным стейтом.
  • Backend (Бэкенд): Проектирование и разработка серверной логики, бизнес-моделей, создание REST/SOAP/gRPC/GraphQL эндпоинтов, оптимизация производительности и интеграция с внешними микросервисами.
  • Migrations (Миграции баз данных): Выделенный тип задач для изменения структуры БД (DDL/DML скрипты). Требует обязательного ревью со стороны DBA (Database Administrator) и написания скриптов отката (rollback).
  • Refactoring (Рефакторинг): Изменение внутренней структуры кода для улучшения читаемости и поддерживаемости без изменения внешнего поведения системы.
  • Bug / Hotfix (Ошибки): Исправление дефектов, обнаруженных в процессе тестирования (Bug) или на продуктовой среде (Hotfix).
  • DevOps / Infrastructure: Настройка CI/CD пайплайнов, обновление конфигураций инфраструктуры (Kubernetes2, Terraform3) или мониторинга.

2. Жизненный цикл задачи (Workflow)

Ниже представлена схема движения задачи от этапа планирования до успешного релиза на прод-среде. Разработчик обязан вовремя переводить статусы в таск-трекере.

graph TD
    A[Backlog] -->|Груминг и Анализ| B(Ready for Dev)
    B -->|Разработчик берет в работу| C(In Progress)
    C -->|Создан Pull Request| D(Code Review)
    D -->|Замечания ревьюера| C
    D -->|Аппрув от 2+ коллег| E(Ready for QA)
    E -->|Тестирование функционала| F(In QA)
    F -->|Найден баг| C
    F -->|Успешные тесты| G(Ready for Release)
    G -->|Деплой на Прод| H[Done / Released]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#f96,stroke:#333,stroke-width:2px
    style D fill:#ff3,stroke:#333,stroke-width:2px
    style H fill:#9f9,stroke:#333,stroke-width:2px

Стандартный воркфлоу задачи

3. Иерархия управления: Эпики, Фичи и Задачи

Для долгосрочного и краткосрочного планирования в компании используется четырехуровневая структура требований:

\[\text{Инициатива} \longrightarrow \text{Эпик (Бизнес / Архитектура)} \longrightarrow \text{Фича} \longrightarrow \text{Техническая задача}\]

  1. Инициатива (Strategic Initiative): Глобальная цель компании на уровне бизнеса (например, «Перевести 80% холодильников на автоматический учет»).
  2. Эпик (Epic): Крупный контейнер работ, рассчитанный на один или несколько кварталов.
  3. Фича (Feature): Конкретная осязаемая функция продукта, решающая задачу пользователя. То, что попадает в описание релиза (например, «Поиск товара на складе по сигналу смарт-метки»).
  4. Техническая задача (Task / Sub-task): Атомарное действие разработчика в коде (например, «Разработать UI-экран сканирования на Flutter»).

4. Классификация Эпиков: Бизнес vs Архитектура

Чтобы избежать путаницы при наполнении бэклога, все Эпики в таск-трекере строго разделяются на два типа по их первоисточнику и конечной цели.

4.1. Бизнес-эпики (Business Epics)

Создаются продуктовой командой (Product Owner / Product Manager) на основе рыночных потребностей и пользовательских болей.

  • Цель: Принести прямую, измеримую ценность пользователю или бизнесу (деньги, метрики, удержание).
  • Язык описания: Формулируются на языке пользователя, без упоминания конкретных баз данных, библиотек или языков программирования.
  • Пример: [BPDS-CORE] Интеграция Продуктовой Системы и Смарт-Меток. Цель бизнеса — снизить пересортицу товаров в холодильнике. Для разработчиков этот эпик станет техническим ориентиром, но его верхнеуровневый смысл — сугубо бизнесовый.

4.2. Архитектурные / Технические эпики (Enabler / Architectural Epics)

Создаются технической командой (CTO / System Architect / Tech Lead) на основе технологических потребностей платформы.

  • Цель: Обеспечить фундамент (платформу) для будущих бизнес-фич, устранить технический долг, повысить безопасность или масштабируемость системы. Технический эпик никогда не делается «ради искусства», он всегда подпирает бизнес-инициативы.
  • Язык описания: Формулируются на инженерном языке с указанием архитектурных паттернов, фреймворков и инфраструктурных решений.
  • Пример: [ARCH] Переход на микросервисную шину данных RabbitMQ или [PERF] Оптимизация индексов и партиционирование таблиц логирования. Бизнес не увидит эти изменения напрямую в интерфейсе, но они необходимы, чтобы приложение не падало при одновременной работе тысяч кладовщиков со смарт-метками.

5. Правила оформления и декомпозиции задач

Эффективность разработки напрямую зависит от атомарности конечных задач (Tasks). Мы придерживаемся следующих правил:

Принцип «Один метод — одна задача»

Запрещено создавать «комбайны» — задачи, описывающие создание целого модуля. Если разработка функции требует изменения бэкенда и фронтенда, она декомпозируется минимум на два отдельных таска.

Каждая задача должна быть независимой, проверяемой и изолированной. Если код метода можно покрыть одним набором юнит-тестов, это идеальный размер для одной задачи.

6. Разбор ключевых атрибутов задачи

Для демонстрации стандартов разберем структуру типовой задачи на примере:

Общая информация

  • Эпик: [BPDS-CORE] Интеграция Периодической Системы и Смарт-Меток
    • Что это: Верхнеуровневый проект (в данном случае — Бизнес-эпик), объединяющий все связанные задачи. Позволяет отслеживать общий прогресс крупной фичи.
  • Домен: FLUTTER_UI (Клиентский интерфейс мобильного приложения)
    • Что это: Технологический стек или архитектурный слой, к которому относится код. Помогает распределять задачи по профильным командам.
  • ID Задачи: FLUTTER-204
    • Что это: Уникальный идентификатор в таск-трекере (Jira/YouTrack) для связи коммитов, веток в Git (feature/FLUTTER-204) и логов.
  • Исполнитель: Назначается
    • Что это: Текущий ответственный за выполнение задачи. Статус «Назначается» означает, что таск находится в бэклоге спринта и ждет разбора разработчиком.
  • Текущий Статус: Ready for Dev
    • Что это: Этап жизненного цикла задачи. Данный статус указывает, что аналитика завершена, архитектура утверждена и код можно брать в работу.
  • Влияние на релиз: 🟡 Среднее (Зависит от готовности бэкенд-эндпоинта в задаче INVENTORY-412)
    • Что это: Оценка критичности задачи для выпуска версии и описание блокирующих зависимостей (блокеров). Показывает, что UI нельзя протестировать без готового API.

7. Правила именования Git-веток на основе ID задачи

Для автоматической связи системы контроля версий с таск-трекером вводится строгий регламент именования Git-ветвей. Название ветки должно начинаться с типа задачи, за которым следует ID из трекера.

Шаблон именования:

[тип-ветки]/[ID-задачи]-[краткое-описание-на-английском]

Допустимые типы веток:

  • feature/ — для новых фич и задач (например: feature/flutter-204-scancode-ui).
  • bugfix/ — для исправления стандартных багов (например: bugfix/flutter-210-fix-button-overflow).
  • hotfix/ — для срочных правок на продакшене.
  • refactor/ — для задач по рефакторингу кода.

8. Методология оценки задач в Story Points

Мы оцениваем задачи не в часах, а в абстрактных единицах — Story Points (SP), которые отражают совокупность сложности, объема работы и рисков (неопределенности).

Шкала оценки (Модифицированные числа Фибоначчи):

  • 1 SP: Минорное изменение. Правка текста, изменение цвета кнопки, добавление лога. Риски нулевые.
  • 2 SP: Простая изолированная задача. Создание простого UI-компонента без бизнес-логики, написание базового Unit-теста.
  • 3 SP: Стандартная задача среднего уровня. Создание метода контроллера, интеграция одного эндпоинта, создание формы валидации.
  • 5 SP: Сложная задача с зависимостями. Требует изменения нескольких модулей, алгоритмической проработки или интеграции с внешним сервисом.
  • 8 SP: Очень крупная или неопределенная задача. Внимание: Задача от 8 SP и выше обязана быть декомпозирована на предспринтовом планировании (Grooming).

9. Регламент проведения миграций баз данных

Любое изменение схемы данных сопряжено с риском нарушения доступности сервиса (Downtime). Процесс миграции строго регламентирован:

  1. Обратная совместимость (Backward Compatibility): Запрещено удалять или переименовывать колонки, которые все еще используются текущей версией бэкенда. Применяется стратегия Expand and Contract.
  2. Наличие Rollback-скрипта: Каждая миграция (Up) обязана содержать зеркальный скрипт отката (Down).
  3. Изоляция транзакций: DDL-операции должны выполняться в транзакциях там, где это поддерживает СУБД.
  4. Ревью со стороны DBA/Tech Lead: Задачи с типом Migrations проходят отдельное код-ревью.

10. Стандарты описания внутренних блоков задачи

Каждое техническое описание внутри таска должно содержать три обязательных раздела.

Раздел 1. Техническое задание для Разработчика (Scope of Work)

Scope of Work (SoW) — это детальное описание архитектурного решения, алгоритмов и изменений, которые необходимо внести в кодовую базу. * Что включает в себя: Ссылки на макеты в Figma, схемы данных, форматы запросов/ответов, бизнес-логику и краевые случаи (edge cases).

Раздел 2. Спецификация для QA Automation (Чек-лист автоматизации интерфейса)

QA Automation Spec — инструкции для инженеров автоматизации тестирования, определяющие, какие элементы интерфейса и сценарии должны быть покрыты автотестами (UI/E2E).

  • Цель: Обеспечить тестируемость интерфейса еще на этапе написания кода (Testability).
  • Что включает в себя:
    • Разметка элементов: Обязательное внедрение уникальных локаторов для ключевых UI-компонентов. Для Web-платформ использовать атрибут data-testid, для Flutter — параметры Key, для Android/iOS — accessibilityIdentifier.
    • Критические сценарии (E2E): Список цепочек действий, которые автоматизаторы должны покрыть тестами в первую очередь (например, «Успешная авторизация \(\rightarrow\) Переход в инвентаризацию \(\rightarrow\) Сканирование метки \(\rightarrow\) Проверка изменения статуса на сервере»).
    • Интеграционные проверки интерфейса: Проверка корректности обработки UI-слоем ошибок сети (отображение Error-state плашек при HTTP 500) и долгих ответов (отображение скелетонов/лоадеров).

Раздел 3. Критерии приемки задачи (Definition of Done)

Definition of Done (DoD) — универсальный чек-лист, определяющий стандарты качества компании. Задача не может быть переведена в статус «Готово», если не выполнен хотя бы один пункт из данного списка.

  • Цель: Гарантировать стабильность, безопасность и чистоту кода перед релизом.
  • Типовой чек-лист DoD:

11. Шаблон оформления Pull Request (PR)

При открытии PR в GitHub/GitLab разработчик обязан полностью заполнить описание по следующему маркдаун-шаблону (данный текст должен быть зашит в файл .github/pull_request_template.md или .gitlab/merge_request_templates/Default.md):

## 📝 Описание изменений
<!-- Кратко опишите, что было сделано и какая техническая проблема решена -->
- Реализован UI-экран ввода смарт-меток на Flutter согласно макетам из таска FLUTTER-204.
- Интегрирован метод валидации префиксов периодической системы на стороне клиента.
- Настроена обработка ошибок при отсутствии Bluetooth-соединения со считывателем.

## 🔗 Связанная задача
- **Task ID:** #FLUTTER-204

## 🛠️ Как тестировать?
<!-- Пошаговая инструкция для проверяющего разработчика или инженера тестирования -->
1. Переключиться на ветку `feature/flutter-204-scancode-ui`.
2. Запустить локальное окружение, перейти в раздел "Инвентаризация".
3. Нажать кнопку "Сканировать" и ввести тестовый ID `BPDS-TEST-99`.
4. Убедиться, что плашка статуса окрашивается в зеленый цвет.

## 🧪 Чек-лист проверки перед ревью
- [ ] Код компилируется локально без ошибок и ворнингов.
- [ ] Написаны новые юнит-тесты, все старые тесты проходят успешно в CI.
- [ ] Добавлены уникальные `key` идентификаторы для кнопок сканирования (требование QA Automation).
- [ ] Проверил верстку UI на экранах с разным разрешением (отсутствует деформация элементов).

В системе управления разработкой BPDS задача может находиться строго в одном из следующих типизированных и визуально размеченных статусов:

  • Backlog Backlog — Задача заведена, но еще не приоритезирована и не оценена.
  • Refinement Refinement (Уточнение) — Аналитики и техлид прописывают архитектурный контекст, Use Cases и связи. Задача заблокирована для взятия в спринт.
  • Ready for Dev Ready for Development — Спецификация готова, критерии DoD зафиксированы. Задача открыта для разработчика.
  • In Progress In Progress — Разработчик открыл Git-ветку и пишет код.
  • Code Review Code Review / MR — Код отправлен в GitLab. Ожидается аппрув от техлида и пиров.
  • QA Testing QA Testing — Воркер развернут на стейдже, инженеры автоматизации гонят тесты по чеклисту.
  • Ready for Prod Ready for Production — Все тесты пройдены, код вмёржен в main. Ожидается релизный тег.

Footnotes

  1. TBD↩︎

  2. TBD↩︎

  3. TBD↩︎