Перейти к содержанию

Процесс разработки

Оглавление

Дейли

Ежебудничные звонки для того, чтобы определить статусы задач, решить возникшие вопросы.

Порядок: Дмитрий -> Руслан -> Алена -> Андрей -> Екатерина -> Юрий -> Олеся

Демо

Демонстрация результатов команды за спринт (цикл) с помощью презентации.

Порядок выступающих: Дмитрий -> Руслан -> Алена -> Андрей -> Екатерина -> Юрий -> Олеся

При отсутсвие выступающего роль переносится на следующего, а отсутсвующий переносится на следующий спринт.

Типы задач и шаблоны

Ниже — краткие шаблоны.

Feature

Feature: [Название фичи]

Описание:
[Коротко: цель, контекст, бизнес-ценность]

Критерии приемки:
- [ ] Код написан и покрыт тестами
- [ ] PR и Review пройдены
- [ ] UI/UX соответствует макетам
- [ ] QA протестировал функционал
- [ ] Продукт одобрил
- [ ] Выложено на прод

Технические требования:
[Миграции, API, спецификации]

Связанные задачи:
- Review
- QA
- Баги
- Подзадача 1
- Подзадача 2

Оценка:
- Story Points: [1,2,3,5,8]

Коммуникация: вся переписка и обсуждение по реализации ведутся в основной задаче `Feature` (комментарии к задаче). Ссылки на связанные Bug/Review/QA задачи добавляются к основной задаче.

Review

Review: [Название фичи]

Связанная задача: Feature: [ссылка]

Что проверить:
- [ ] Код соответствует стандартам
- [ ] Тесты покрывают ключевые сценарии
- [ ] Нет security issues
- [ ] Архитектура корректна

QA

QA: [Название фичи]

Чек-лист тестирования:
- [ ] Функциональное тестирование
- [ ] Проверка критериев приемки
- [ ] Регрессия
- [ ] Тестирование ошибок/валидаций

Bug

Bug: [Краткий заголовок]

Связанная фича: [ссылка]
Найден при тестировании: [дата]

Шаги воспроизведения:
1.
2.
3.

Ожидаемый результат:

Фактический результат:

Технические детали:
- Компонент: [backend|frontend]
- Окружение: [prod|stage|contour]

Hotfix

Hotfix: [Краткое описание]

Описание проблемы: [влияние на пользователей]

Приоритет:
- Severity: [critical|high]

Критерии фикса:
- [ ] Проблема решена
- [ ] Протестирован фикс
- [ ] Развернуто на проде
- [ ] Коммуникация с пользователями

Примеры

Ниже два практических примера — как мы разбиваем фичу на frontend/backend и как проводить review/QA при багах из продакшна.

1) Пример: Feature с frontend и backend частью

Общая идея: заводим одну основную Feature-задачу, и внутри неё — явные подзадачи для backend и frontend, отдельные ревью/PR и единый QA, который проверяет интеграцию.

Пример структуры задач:

Feature: []

Описание:

Критерии приемки:
- [ ] Backend: API для создания транзакции + unit/integration tests
- [ ] Frontend: UI соответствует макетам и корректно вызывает API
- [ ] QA 

Связанные задачи:
- Feature — Backend (work-type: feature, component: backend)
- Feature — Frontend (work-type: feature, component: frontend)
- Review — Backend 
- Review — Frontend 
- QA — тестирование

Рекомендации по процессу: - Backend и Frontend — отдельные подзадачи, каждая с собственным component и исполнителем. - Backend обычно делает API и ставит статус Review Ready. После merge backend в интеграционную ветку frontend интегрируется с реальным API (или с контрактным mock'ом при необходимости). - Reviews для backend и frontend проходят отдельно; QA начинает проводить тесты только когда обе части готовы. - Баги, найденные на этапе QA, создаются как отдельные Bug и ссылкой связываются с основной Feature. Для таких багов проставляем work-source: from-feature и component по месту обнаружения. - Главная задача назначается на одного из разработчика, либо на TL или PM.

2) Пример: Review и QA при баге из prod

Когда баг пришёл из продакшна — действуем быстрее и строже. Ниже пошаговый алгоритм.

Алгоритм действий: 1. Triage: on-call или TL воспроизводит проблему (если возможно) и проставляет приоритет (critical/high/medium/low). В поле environment указываем prod. 2. Создать Bug по шаблону с подробными шагами воспроизведения, логами и ссылками на мониторинг/инцидент. 3. Если приоритет = critical|high — заводим Hotfix или помечаем work-source: hotfix и уведомляем on‑call. 4. Реализация: разработчик делает минимальный, безопасный фикс (branch hotfix/...), добавляет unit тесты. 5. Review: ускоренное ревью — назначаем 1–2 ревьюеров, можно проводить с TL. Переназначая задачу. 6. Deploy: сначала в stage/preprod для smoke tests, затем в prod. 7. QA: целевое тестирование в окружении после деплоя; QA закрывает баг только после подтверждения в prod (или в случае отката — после повторного теста). 8. Документация: добавить ссылку на релиз/PR в баг, обновить CHANGELOG/release notes.

Примечание: если баг из prod не критичный — можно пройти стандартный процесс Bug → triage → план на ближайший спринт, но всегда указывать environment: prod и помечать приоритет/серьёзность.

Review и QA — когда выделять отдельные задачи

Кратко: по умолчанию выделяем отдельные Review и QA задачи для средних и крупных фич, но для мелких изменений достаточно чек-листа в основной Feature.

Когда создавать отдельные задачи:

  • Создавайте отдельные Review и QA задачи как дочерние/связанные к Feature, если:
    • задача ≥ 2–3 SP;
    • затрагиваются несколько компонентов (например, frontend + backend);
    • присутствуют миграции, изменения контрактов API или риск безопасности.
  • Не выделяем отдельные задачи, если это мелкая правка (1 SP), документация или косметика — используйте чек-лист в Feature и стандартный PR-review.
  • Для багов из prod всегда заводим отдельный Bug/Hotfix и отдельную QA-задачу (верификация в окружении) — не экономим на шагах верификации.

Рекомендуемая структура для крупных фич (frontend + backend):

Feature: [X — Main description]
    ├─ Feature — Backend (component: backend)
    │   └─ Review — Backend (work-type: review)
    ├─ Feature — Frontend (component: frontend)
    │   └─ Review — Frontend (work-type: review)
    └─ QA — Integration / E2E (work-type: qa)

Причины: отдельные Reviews дают фокус и ответственность за код в каждой части; единая QA-задача гарантирует полную проверку.

Ownership и переходы:

  • Review назначается конкретному ревьюеру (или TL). После прохождения Review подзадача Review помечается Done.
  • QA назначается инженеру QA; когда все Review-подзадачи завершены, основную Feature переводим в Ready for QA и запускаем QA-задачу.
  • Все Review/QA задачи обязательно ссылаются на основную Feature (ссылка в описании), чтобы сохранять единую историю обсуждения.

Рекомендуемые лейблы и поля:

  • work-type: chore
  • component: backend|frontend
  • work-source: from-feature

Плюсы и минусы:

  • Плюсы: чёткая ответственность, видимость, возможность метрик на Review/QA, параллельная работа команд.
  • Минусы: дополнительная административная нагрузка для очень мелких изменений — поэтому используем правило порога по SP/компонентам.

Практическая рекомендация для команды:

  • Правило: если Feature затрагивает >1 component или оценивается ≥3 SP — создаём отдельные Review и QA задачи; иначе — чек-лист в Feature.

Система лейблов

Обязательные лейблы (использовать всегда):

  • work-type: feature, bugfix, chore, ops, meeting, support, investigation, documentation
  • work-source: planned, triage, hotfix, customer-request, internal-improvement, from-feature
  • component: backend, frontend, infra, design, database

Специфичные для багов:

  • bug-type: regression-bug, feature-bug, legacy-bug, environment-bug, data-bug
  • bug-severity: critical, high, medium, low

Окружения: - environment: prod, stage, contour

Workflow и статусы

Основный поток для Feature: Backlog → ToDo → In Progress → Review Ready → Ready for QA → Ready for Release → Done

Короткие статусы для Review/QA/Bug: To Do → In Progress → Done

Если найден баг в фиче, то создается отдельная задача с багом, откуда он взят, основная задача передвигается In Progress. Новая задача по багу идет по корткому процессу, далее задача обратно возвращается на Ready for QA.

Процесс разработки

  1. Планирование (спринт 2 недели): Product готовит спецификации; команда оценивает в Story Points.
  2. Начало работы: разработчик берёт задачу из ToDo, ставит In Progress и назначает себя.
  3. Завершение разработки: создаётся PR → статус Review Ready → ревью → Ready for QA.
  4. Тестирование: QA использует чек-лист; при багах создаются Bug-задачи.
  5. Релиз: после одобрения Product задача переводится в Done.

Projects

Зачем нужен Project:

  • Project — это уровень инициативы/инициатива (roadmap) вокруг набора связанных задач (Feature, Investigation, важные Bug). Он служит для планирования, приоритизации и отчётности на уровне продукта или большой фичи. Project имеет owner, цель, ожидания по результату и обычно живёт дольше одной задачи/спринта.

Чем Project отличается от Feature:

  • Scope: Project покрывает несколько Feature/Investigation/Bug; Feature — единичная задача по реализации конкретного функционала.
  • Lifetime: Project может длиться месяцы; Feature — обычно укладывается в один спринт или меньше.
  • Owner: Project назначается Product или TL; Feature — обычно назначается конкретный разработчик как исполнитель.
  • Tracking: в Project мы отслеживаем прогресс по вехам (Milestones), риски и общий scope.

Примеры Milestones :

1) Release 1.0 - Goal: публичный релиз core-функционала, API стабильные. - Owner: Dev - Scope: Features A, B, C; Data migration; Integration tests - Exit criteria: все Features в scope 'Done', нет критических багов

2) Beta - Goal: internal beta для 10 клиентов, собрать фидбек. - Owner: PM - Scope: минимальный набор фич + телеметрия - Exit criteria: собраны отзывы от >5 клиентов, критичные баги исправлены

3) API Stabilization - Goal: зафиксировать публичное API и покрыть интеграционными тестами - Owner: Dev - Scope: задачи по доке API, тестам - Exit criteria: API contract tests green

Практика: связывайте Feature и Bug с соответствующим Milestone, помечайте баги work-source: from-feature — это даёт возможность метрики по качеству релиза.

Работа с багами и хотфиксами

  • При нахождении бага QA — создаёт Bug по шаблону с шагами воспроизведения и логами.
  • Фичу переводят в Bug Fix, разработчик фиксит, QA ретестит.

  • Для критичных инцидентов — оформляем Hotfix.

  • Если баг найден во время тестирования конкретной фичи: создайте Bug по шаблону и обязательно укажите

    • work-source: from-feature (или пометку, откуда пришёл баг),
    • component (backend/frontend) и приоритет по факту. В поле описания/комментарии укажите ссылку на основную Feature-задачу и все шаги воспроизведения.

  • Передайте баг разработчику (назначьте или отметьте в комментарии) для triage и оценки — это позволяет учитывать, сколько багов появилось в рамках конкретной фичи и оценить качество релиза.

  • Вся дальнейшая коммуникация по багу (дискуссии, решение спорных моментов, ссылка на PR) ведётся в основной Feature-задаче: создайте комментарий с ссылкой на Bug или добавьте заметку в основной задаче, чтобы сохранить единую историю обсуждения.

Вахтовый метод поддержки

На каждый спринт выделяется по одному разработчику из фронтенда и из бэкенда. Эти два человека совместно отвечают за приём и обработку хотфиксов, инцидентов и срочных задач в рамках спринта.

Обязанности on‑call (front + backend):

  • мониторинг инцидентов и оповещений;
  • приём входящих запросов с triage / hotfix статусом;
  • быстрое локальное расследование и, при необходимости, оперативный фикс;
  • оформление Hotfix-задачи и передача информации в PR/issue;
  • при эскалации — уведомление Team Lead.

Процесс передачи вахты:

  • Передача ответственности планируется на понедельник.
  • При форс-мажоре on‑call отвечает до передачи следующему инженеру в конце спринта.

Составы: - Дмитрий - Андрей - Руслан - Юрий - Алена - Екатерина

Составы могут меняться.

Работа со сложными задачами

Признаки: оценка > 8 SP, непонятные требования, технические риски, внешние зависимости.

Рекомендуемый порядок для сложных задач:

  1. Обсуждение (scoping): краткая синхронизация с Product и TL — цель, ограничения, критерии успеха.
  2. Investigation: заводим задачу Investigation, собираем варианты решений, риски и оценки. В рамках исследования можно подготовить PoC или небольшие прототипы.
  3. Контрольный звонок (sync): после завершения investigation проводим короткий митинг (15–30 минут) с владельцем задачи, TL и исполнителями, обсуждаем результаты, окончательно согласуем границы работ и решение.
  4. Разработка: только после успешного контрольного звонка задача переводится в ToDo и берётся в работу.

Процесс в деталях:

  • Создайте Investigation с целью и ожидаемым результатом (3–8 sp по estimate).
  • В конце investigation подготовьте краткий отчёт и/или PR с демонстрацией результатов.
  • Назначьте контрольный звонок; в нём фиксируем решение, риски и критерии приёмки.
  • После звонка разбиваем задачу на подзадачи и оцениваем в Story Points.

Пример шаблона Investigation:

Investigation: [Тема]

Цель исследования: [что выяснить]

Вопросы:
- [ ] Технические варианты
- [ ] Риски и ограничения
- [ ] Зависимости
- [ ] Оценка сложности

Участники: Разработчики, TL, Product
Estimate: [3-8 sp]

Оценка и планирование

Story Points: 1,2,3,5,8 (Fibonacci).

Пример расчёта команды (4 человек): общая capacity = 120 pts → Фичи 84 pts / Поддержка 12 pts / Буфер 24 pts. Пример расчета команды (2 человек) вахтовиков: общая capacity = 60 pts → Фичи 12 pts / Поддержка 36 pts / Буфер 12 pts.
Пример расчета на всю команду: общая capacity = 180 pts → Фичи 96 pts / Поддержка 48 pts / Буфер 36 pts.

Метрики и отчетность

Собраны view для информативности и помощи. - Текущего цикла баги - Текущего цикла фича баги - Текушего цикла работа по срочным и из поддержки задач - Предыдущего цикла бага - Предыдущего цикла выполненные задачи - Предыдущего цикла фича баги - Предыдущего цикла работа по срочным и из поддержки задач

Практические правила

  • Для разработчиков: ежедневно обновлять статусы, помечать Blocked при проблемах, использовать лейблы, участвовать в вахтах.
  • Для QA: использовать чек-листы, создавать баги с полным описанием, приоритетно тестировать хотфиксы.
  • Для вахтовой команды: мониторить оповещения, быстро реагировать, документировать действия и передавать контекст.

Постоянное улучшение

  • Еженедельные ретроспективы
  • Калибровка оценок
  • Анализ метрик поддержки
  • Обучение новых членов

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