Коротко: хороший процесс разработки — единый источник правды о пути задачи от идеи до прода: роли, события, оценка и движение Epic-Story-Task.

Хороший процесс разработки — это не бюрократия, а единый источник правды о том, как задача проходит путь от идеи до прода: кто за что отвечает, когда задача готова к работе и когда считается выполненной. Ниже — рабочий каркас воркфлоу, который я выстраивал в командах: роли, события, оценка, и движение сущностей Epic → Story → Task. Его можно взять за основу и адаптировать под себя.

Роли

  • Product Owner (PO) — отвечает за ценность продукта, ведёт бэклог, связывает стейкхолдеров и команду, приоритизирует.
  • Team Lead (TL) — ведёт команду к цели спринта, помогает самоорганизации, снимает блокеры, отвечает за качество и релиз.
  • Аналитик — собирает, структурирует и документирует требования (Wiki / функциональные требования).
  • Разработка — пишет код, тесты, внедряет функциональность.
  • QA-инженер — проверяет результат по критериям приёмки, ищет дефекты до прода, заводит SubBug/ProdBug, отвечает за качество релиза.
  • Стейкхолдер — заинтересованное лицо с полномочиями ставить задачи.

В маленькой команде роли совмещаются (часто функции PO делят аналитик и TL) — это нормально, важно чтобы зоны ответственности были явно закреплены.

Definition of Ready и Definition of Done

Два ключевых соглашения, которые убирают половину хаоса:

  • Definition of Ready (DoR) — когда задачу можно брать в спринт: есть понятное описание, критерии приёмки, оценка, нет неразрешённых вопросов и внешних блокеров.
  • Definition of Done (DoD) — когда задача считается выполненной: код написан и отревьюен, покрыт тестами, прошёл проверку, влит, задеплоен (или готов к деплою), документация обновлена.

Без DoR в спринт попадает «полузадача», которую невозможно оценить. Без DoD «готово» у каждого своё.

Иерархия задач: Epic → Story → Task

  • Epic — крупная бизнес-цель/направление, объединяет много историй (может жить несколько спринтов).
  • Story — пользовательская ценность, формулируется «как <роль>, я хочу <что>, чтобы <зачем>». В идеале story стоит декомпозировать так, чтобы она влезала в один спринт, но это не обязательство: внутри может быть много технических задач, они бывают блокерами друг для друга, а постановка не всегда прозрачна на 100% — поэтому в условиях ограниченного ресурса story вполне может жить несколько спринтов.
  • Task — конкретный технический шаг внутри истории, оценённый в Story Points.
  • SubBug — дефект, найденный в период тестирования в рамках Task (чинится до закрытия истории).
  • ProdBug — баг, найденный уже в проде (отдельный приоритетный поток).

Груминг доводит истории до Task'ов с оценками — чтобы к планированию они были готовы (DoR).

События (ритуалы)

  • Планирование — в начале спринта: берём из бэклога то, что проходит DoR, и разбиваем на задачи в пределах ёмкости команды.
  • Дейли (синк) — короткая ежедневная сверка: что сделал, что планирую, что мешает. Не статус-отчёт начальству, а синхронизация команды.
  • Груминг — подготовка бэклога к следующему спринту: декомпозиция и оценка.
  • Ретро — в конце спринта: что улучшить в процессе.

Оценка в Story Points и ёмкость спринта

Оценивайте задачи не в часах, а в относительных Story Points (SP) — это устойчивее к оптимизму. У команды есть ёмкость спринта (сколько SP реально вытягивает за итерацию, по факту прошлых спринтов) и желательно квоты по типам работ — например, доля на техдолг и баги, а не только на фичи. Это не даёт техдолгу копиться бесконтрольно.

Обязательные технические практики

  • Трекер с обязательными атрибутами: у каждой задачи есть оценка, исполнитель, статус, версия. Не «задачи в Telegram без сроков».
  • Код-ревью перед влитием — всегда.
  • Автотесты на каждое изменение, прогон на каждый релиз.
  • Автоматизированные деплои (CI/CD) — релиз не должен быть ручным подвигом.
  • Документация и онбординг — чтобы знания не жили в головах отдельных людей (снижаем bus factor).

Почему это работает

Когда есть единый регламент (источник правды), прозрачные статусы и числа, обязательные ревью и тесты — задачи перестают теряться, сроки становятся предсказуемее, а прод-баги уходят в легаси-части, а не в новый код. Главное — внедрять постепенно: сначала трекер с атрибутами и DoR/DoD, потом ревью и тесты, потом автодеплой.

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