Модуль 0.6. Процесс работы системного аналитика в команде разработки
Scrum/Kanban, backlog, DoR/DoD, релизы
Ваша ценность как системного аналитика (SA) резко растёт, когда вы управляете не только содержанием требований, но и их прохождением через процесс: от идеи в бэклоге до стабильного релиза и наблюдаемости в проде. В модуле закрепляем роли SA в Scrum/Kanban, правила формирования backlog, Definition of Ready/Done, релизные практики и «линию обороны» против рисков.
Картина целиком: как требование проходит от идеи до продакшена
Поток работ (simplified):
Discovery → Backlog (Epic/Feature) → Refinement (Story/Task/Spike) → DoR → In Progress → Code Review → Ready for Test → UAT → Release/Deploy → Observe (SLI/SLO) → Learn/Change
Ответственность SA на каждом шаге:
- Discovery. Вы уточняете бизнес-цели, риски, ограничения, формируете Vision/BRD-ссылки, грубый BPMN/C4.
- Backlog/Refinement. Декомпозируете в Story, оформляете SRS-разделы, ER, DMN, OpenAPI/AsyncAPI, NFR, AC/BDD, поднимаете RTM-связи.
- DoR-контроль. Проверяете полноту «входа» (см. чек-лист ниже).
- Спринт/Разработка. Отвечаете на вопросы Dev/QA, синхроните изменения в SRS/контрактах, держите RTM в актуале.
- Тестирование/UAT. Обеспечиваете тестируемость: AC/BDD, тестовые данные, критерии приёмки.
- Релиз. Валидируете релизные заметки и матрицу версий SRS/OpenAPI/Events, участвуете в решениях по feature flags/canary/rollback.
- Эксплуатация. Проверяете SLI/SLO, корректность логирования/трассировок/алертов, собираете обратную связь в Change Request.
Scrum: как SA встроен в церемонии и артефакты
Церемонии и вклад SA
-
Backlog Refinement (еженедельно, 60–90 мин).
Вносите и защищаете модели (BPMN/DMN/ER/Sequence, C4 L2), AC/BDD, NFR; фиксируете зависимости и внешние контракты. -
Sprint Planning (раз в спринт, 60–120 мин).
Подтверждаете DoR по выбранным Story, уточняете допущения, назначаете «SpecLink» и версию контрактов. -
Daily (ежедневно, 15 мин).
Отвечаете на блокеры Dev/QA; SLA ответа SA — до конца рабочего дня. -
Sprint Review.
Проверяете соответствие реализованного AC/BDD; фиксируете изменения в SRS/RTM. -
Retrospective.
Вносите улучшения процесса требований: где споткнулись, чего не хватало (диаграммы, тестовые данные, схемы).
Планирование и декомпозиция
Единицы планирования: Epic → Feature → Story → Task/Spike.
Хорошая Story для SA содержит:
- Ссылку на SRS-разделы, диаграммы, глоссарий.
- Контракты: OpenAPI/AsyncAPI версии MAJOR.MINOR.PATCH и миграции.
- AC/BDD (Given/When/Then).
- NFR: p95 latency, throughput, error-rate, RTO/RPO, безопасность и наблюдаемость.
- Данные: ER-сущности, домены, тестовые наборы.
Kanban: когда нет спринтов
Канбан-доска и колонки
Рекомендуемый поток: Backlog → Analysis → Spec Ready → Dev → Code Review → Test/UAT → Release → Done.
SA владеет колонками Analysis и Spec Ready; переход в Dev — только при DoR=OK.
WIP limits и метрики
- WIP для Analysis/Spec Ready: ограничивайте 1–2 элемента на SA, иначе теряется фокус.
- Цикл-тайм: «от Analysis до Spec Ready» — целевой SLA ≤ 3 рабочих дня на стандартную Story.
- CFD/Control Chart: отслеживайте залипание на «Analysis» — признак плохого входа или скрытых зависимостей.
Backlog: правила гигиены и типы работ SA
Типы карточек с участием SA
- Feature/Story: продуктовая функциональность.
- Integration: отдельный тип для внешних API/событий (с контрактами).
- Non-Functional: NFR/Observability/Безопасность.
- Data Contract: изменения ER/глоссария/экспорта/CDC.
- Spike: исследование/PoC; выходом должен быть ADR/рекомендация.
Поля карточки (обязательно)
SpecLink, ContractVersion, DataImpact, NFR Tag(s), Test Ref, Risks/Assumptions, Dependencies, Rollback/FF plan.
DoR/DoD: чек-листы «входа» и «выхода»
Definition of Ready (DoR) — для входа в разработку
- В SRS описана область и термины; есть BPMN/UseCase/Sequence (по необходимости).
- ER и глоссарий обновлены; определены домены/ключи; тестовые данные готовы.
- Контракты: OpenAPI/AsyncAPI со схемами запрос/ответ, ошибками, пагинацией, лимитами; стратегия версионирования.
- NFR: измеримые SLO (p95 latency/RPS/error-rate), RTO/RPO, логирование/трейсинг/метрики, требования безопасности.
- AC/BDD: не менее 3 ключевых сценариев, включая негативные.
- RTM: требование привязано к Story/Тесту/Мониторингу.
- Зависимости: внешние API/данные согласованы; есть ADR или CR при спорных решениях.
Definition of Done (DoD) — для выхода из разработки/тестов
- Реализовано ровно то, что в SRS/AC; пройдены все BDD.
- Документация обновлена: SRS/OpenAPI/AsyncAPI/ER с bump версий и CHANGELOG.
- Observability: логи/метрики/трейсинг — по требованиям; алерты заведены.
- Безопасность: маскирование PII, роли/права, аудит-логи.
- Релизные заметки: миграции/совместимость/FF/rollback.
- RTM/Матрица версий — обновлены; ссылки в Jira валидны.
- Для интеграций — контрактные тесты/совместимость с N-1/N+1 версиями.
Релизы: от релизного плана к безопасным выкладкам
Планирование релиза (по спринтам или по потоку)
- Релизная ветка и теги: привязка версий SRS/OpenAPI/Events к версии релиза.
- Матрица совместимости: какие клиенты на каких версиях работают, сроки EOL.
- Миграции данных: скрипты, обратимость, проверка длительности и блокировок.
Стратегии поставки
- Feature Flags / Dark Launch. Включение/выключение по сегментам; SA описывает поведение при OFF.
- Canary / Progressive Delivery. SA определяет контрольные SLI и критерии остановки/отката.
- Backward Compatibility. «Два контракта на время миграции»; SA фиксирует период и правила удаления старого.
Релизный чек-лист SA
- Release notes согласованы: что меняется, риски, влияние на клиентов/данные.
- Матрица «Версия ПО ↔ SRS/OpenAPI/Events» обновлена.
- Проверены алерты/дашборды по SLI; включены эвенты аудита.
- План отката: технический и по данным (в т.ч. идемпотентность повторов).
Практические примеры
Пример A. API «Возврат платежа» (Scrum)
- Story: «Как оператор, я инициирую возврат…»
- SpecLink: SRS-PAY-Refund v2.1.0
- OpenAPI: POST /refunds (идемпотентен по Idempotency-Key), GET /refunds/{id}; ошибки 400/409/422/504.
- NFR: p95<2с, 3 retry с экспоненциальной паузой, timeout PSP 10с, аудит-лог.
- AC: BDD 5 сценариев (успех/конфликт/таймаут/повтор/PSP-ошибка).
- Observability: метрики refund_latency_p95, refund_error_rate, трассировки с correlation-id.
- DoR: OK → в спринт.
- DoD: контрактные тесты пройдены с N-1; релизные заметки содержат окно удаления поля legacyCode через 2 релиза.
Пример B. Канбан-интеграция с 3PL
- Колонки: Analysis→Spec Ready→Dev→CR→Test→Release.
- WIP Analysis=1. SA держит одну интеграцию; цикл ≤ 5 дней.
- DataImpact: справочник «Склады», ER пересогласован; SLA на событие ShipmentDelivered ≤ 1 мин.
Риски процесса и как их снимать
-
Scope creep в спринте.
Признак: постоянные «быстрые» изменения в Story.
Меры: CR-процесс, заморозка требований после DoR, перенос в следующий спринт. -
Скрытые зависимости.
Признак: «всплыли» внешние API/данные.
Меры: шаблон Story с обязательными полями Dependencies/Assumptions; early-sync с внешними командами. -
Отсутствие измеримых NFR.
Признак: «медленно/нестабильно» в проде.
Меры: чек-лист NFR в DoR, связка с SLI/SLO и алертами. -
Разрыв спеки и кода.
Признак: OpenAPI/ER не совпадают с реализацией.
Меры: docs-as-code, линтеры/CI, запрет релиза без bump/CHANGELOG. -
Плохие тестовые данные.
Признак: баги «только в проде».
Меры: каталог тест-данных, маскирование PII, генераторы фикстур. -
Непрозрачные релизы.
Признак: неясно, что выкатываем и как откатывать.
Меры: релизный чек-лист SA, FF/canary, матрица совместимости.
Календарь SA (рекомендуемый ритм)
- Пн: Plan/Refinement (EPIC/Feature), обновление RTM/SpecLink.
- Вт–Чт: Анализ/спецификация, ответы Dev/QA, синк по интеграциям.
- Ср: Design review/3-Amigos; обновление диаграмм/контрактов.
- Пт: Проверка DoR будущих Story, релизный чек-лист, обновление SLI/SLO/алертов.
Мини-шаблоны
Шаблон Story с полями SA
Title: <Глагол + Ценность + Объект> SpecLink: <SRS/...#anchor> ContractVersion: <OpenAPI 2.4.0 / AsyncAPI 1.3.1> DataImpact: <Сущности/Справочники/CDC> NFR: <p95/RPS/Error/RTO/RPO/Sec/Obs> AC/BDD: <ссылка на .feature> TestData: <набор/генератор> Dependencies: <внешние API/данные/фичи> Risks/Assumptions: <...> FF/Canary: <plan> Rollback: <plan>
ADR (решение по процессу/интеграции)
Context → Decision → Consequences → Alternatives → Links (Jira/PoC/Metrics)
Вопрос–Ответ
Q1: Чем DoR отличается от DoD?
A: DoR — условия «входа» в разработку (готовность спеки/контрактов/данных/NFR). DoD — условия «выхода» (всё реализовано/протестировано/задокументировано/наблюдаемо).
Q2: Кто «владеет» DoR/DoD?
A: Команда. SA владеет частью про спецификации, контракты, NFR, данные и тестируемость.
Q3: Нужно ли SA оценивать Story по Story Points?
A: Да, участвуете. Вы поясняете сложность интеграций/данных/NFR; итог — командный консенсус.
Q4: Когда вводить Feature Flags?
A: Всегда при рисковых фичах/миграциях. SA обязан описать OFF-поведение и ограничения.
Q5: Как зафиксировать «готовность к релизу»?
A: Релизный чек-лист + матрица версий + наличие алертов и SLI; сторожевые BDD пройдены.
Q6: Канбан или Scrum для аналитики?
A: В продуктовых командах чаще Scrum (ритм/пакетирование), для интеграций/поддержки — Kanban (поток/лимиты WIP). Часто гибрид: разработка по Scrum, сопровождение интеграций — Kanban.
Домашнее задание и артефакт модуля
Артефакт: ваш индивидуальный процесс-гайд (1–2 страницы) и чек-листы DoR/DoD под ваш проект.
- Сформируйте шаблон Story (см. п.10.1) с обязательными полями для SA.
- Настройте в Jira поля SpecLink, ContractVersion, DataImpact, NFR, TestRef, Dependencies.
- Опишите ваш поток (Scrum или Kanban): колонки/статусы/правила переходов, WIP-лимиты.
- Согласуйте релизный чек-лист SA с Dev/QA/DevOps и добавьте к Definition of Release.
- Зафиксируйте SLA для ответов на вопросы Dev/QA (например, до конца дня).
- Включите DoR/DoD в шаблон доски и в Definition of Workflow.
Критерии зачёта: DoR/DoD покрывают спецификации/контракты/данные/NFR/observability; в Jira настроены поля; описан поток и релизный чек-лист; согласовано с командой.
