Перейти к основному содержимому

О разделе "Доставка и готовность"

Проект может иметь отличный Scrum или Kanban, но без ясных критериев готовности команда тонет в переписке: задачу взяли сырыми требованиями, закрыли без тестов, пользователи узнали о релизе из Twitter.

Раздел 7.25 — про четыре опоры доставки:

  • DoR (Definition of Ready) — можно ли начать задачу;
  • DoD (Definition of Done) — можно ли закрыть и отдать в релиз;
  • Release notes — что сказать пользователям и support;
  • Feature flags — gradual rollout, kill switch, выкат без big bang.

Для кого раздел​

РольЧто найдёте
Junior devПочему задачу вернули в backlog и что дописать
QADoD для тестируемости, release notes об исправлениях
BA / PODoR: AC, макеты, зависимости
ТимлидУровни DoD, CI enforcement, флаги в prod
DevOpsRelease notes для эксплуатации, kill switch при инциденте
DoR и DoD — договорённости команды

Это не бюрократия из учебника. Это общий язык: "готово к работе" и "готово к релизу" означают одно и то же для всех — включая удалённую команду в разных TZ.

Маршрут по разделу​

ШагМатериалСодержание
1Definition of ReadyЧек-лист DoR, Kanban, трекер, связь с аналитикой
2Definition of Done и release notesDoD для web/mobile, уровни, шаблон release notes
3Feature flagsGradual rollout, kill switch, LaunchDarkly, DoD
4Итоги · Чек-листРезюме и самопроверка

DoR — preview​

Definition of Ready — задача достаточно подготовлена, чтобы разработчик или QA начали без недель уточнений. Без DoR в спринт попадают "чёрные ящики" — неясные требования, нет макета, API партнёра не готов.

Типичные пункты DoR:

  • описана ценность для пользователя;
  • есть acceptance criteria (AC);
  • известны зависимости (дизайн, API, доступы);
  • для UI — макет или wireframe;
  • для интеграций — контракт или sandbox.

Подробно — глава 1. Связь со Scrum DoD.

DoD — preview​

Definition of Done — инкремент готов к релизу (или к следующему уровню). Пример для веб-фичи:

  • код в main, PR approved;
  • тесты зелёные в CI;
  • проверено на stage;
  • документация обновлена;
  • release notes черновик (если user-facing).

DoD для mobile и web различается — глава 2. DoD enforced в CI и review, не на плакате (FAQ методологии).

Release notes — preview​

Release notes — что изменилось для пользователя, support и DevOps. Структура:

  1. версия и дата;
  2. новое (ценность);
  3. исправлено;
  4. breaking changes;
  5. известные ограничения;
  6. блок для админов (downtime, флаги).

Хранение — wiki или CHANGELOG.md (техписьмо). Черновик от ИИ — только с факт-чеком.

Feature flags — preview​

Feature flag — переключатель поведения без нового деплоя (или с минимальным):

  • gradual rollout — 5% → 50% → 100% пользователей;
  • kill switch — выключить фичу при инциденте;
  • A/B — эксперименты (аналитика);
  • код в main за флагом вместо long-lived branch (YAGNI).

Инструменты: LaunchDarkly, Unleash, конфиг в K8s — глава 3.

Связь с другими разделами​

Типичные симптомы без дисциплины​

СимптомВероятная причина
"Уточняем третью неделю"Нет DoR / слабые AC
"Закрыли, но на prod не работает"DoD без stage/prod checklist
Пользователи удивлены изменением UIНет release notes
Откат = hotfix ночьюНет feature flag / kill switch
Velocity "скачет"В спринт берут не-ready задачи

Как внедрять​

  1. Соберите текущий устный DoD команды — часто он уже есть, но не записан.
  2. Оформите DoR/DoD на 1 страницу wiki + поля в тикете.
  3. Добавьте 1–2 пункта в CI (тесты, lint) как hard gate.
  4. Шаблон release notes к релизному процессу.
  5. Для одной крупной фичи — пилот feature flag (LaunchDarkly или open source).
Начните с DoR

Одна команда с сильным DoR часто быстрее, чем команда с идеальным DoD, но сырым backlog. Нельзя "доделать" то, что непонятно с начала.

Итог по разделу​

DoR, DoD, release notes и feature flags — связанная система: задача входит подготовленной, выходит проверенной, пользователи информированы, prod получает изменения постепенно и обратимо.

Связанные темы

Последнее обновление
Содержание