Модуль 8.1. Agile/Lean для SA
Темы: Scrum/Kanban, эпики/фичи/стори, спайки, definition mapping. Артефакт: структурированный backlog. Практика: декомпозиция эпика в сториз.
Системный аналитик (SA) — связка «бизнес ↔ команда». В Agile/Lean вы обеспечиваете поток ценности: формулируете проблему, режете её на вертикальные инкременты, прописываете AC/NFR, держите Definition of Ready/Done, управляете рисками через спайки и политики Kanban. Этот модуль — практическая инструкция без воды.
Картина мира: Scrum и Kanban — что важно именно SA
Scrum (итерации и коммитмент)
- Ивенты: Refinement → Planning → Daily → Review → Retro.
-
Роль SA:
- Refinement: готовите DoR, AC/BDD, схемы API/событий, NFR, риски.
- Planning: помогаете слайсить фичи и зафиксировать критерии «готово».
- Review: демонстрируете поведение на AC/фича-файлах; собираете фидбек.
- Retro: улучшаете DoR/DoD, Definition Mapping (см. ниже).
Kanban (поток и ограничение WIP)
- Политики: визуализация, лимиты WIP, классы обслуживания, SLE (Service Level Expectation), pull.
- Метрики: lead time, cycle time, throughput, CFD (cumulative flow diagram).
- Роль SA: формализуете классы обслуживания (expedite/fixed date/standard/intangible), определяете Definition of Ready для входа в колонку «Разработка», согласуете политики выхода (Definition of Done).
Норма: в продуктовых командах часто гибрид: Scrum-ритуалы + Kanban-метрики и лимиты.
Единицы работы: эпик → фича → юзер-стори → сабтаски
Определения
- Эпик: крупная цель/исход бизнес-метрики (недели–квартал).
- Фича: полезный кусок ценности, который можно релизить (дни–2 недели).
- Юзер-стори: вертикальный инкремент поведения «для персоны»; проходит Design–Build–Test–Release.
- Сабтаски: технические шаги (API, миграции, тесты, контент).
INVEST и SPIDR
- INVEST (для стори): Independent, Negotiable, Valuable, Estimable, Small, Testable.
- SPIDR (слайсинг): Spikes, Path (счастливая тропа), Interfaces, Data, Rules.
Вертикальные vs горизонтальные срезы
- Вертикаль (правильно): минимальный рабочий поток end-to-end (UI/API/БД/события/логика) → можно демонстрировать/выкатывать.
- Горизонталь (антипаттерн): «сначала БД», «потом API», «потом UI» — тормозит ценность.
Спайки (Spike): управляем неизвестностью
- Зачем: исследовать/подтвердить риск (технология, протокол, интеграция, объёмы), чтобы уменьшить вариативность оценки и сформулировать DoR для последующих стори.
- Формат: гипотеза → вопросы → план эксперимента → критерии завершения → артефакт (PoC, замеры, решение).
- Выход: конкретные решения и ограничения, обновлённые AC/NFR, иногда — отказ/перепроектирование.
Пример: «Spike: gRPC bidirectional streaming с лимитом p95<150мс, 500 RPS» → PoC + метрики + черновик контракта.
Definition Mapping: как свести «готово» на всех уровнях
Definition Mapping — таблица соответствия уровня работы и определений готовности (DoR/DoD) + артефактов, которые должны существовать. Это снимает противоречия «мы думали, что готово».
|
Уровень |
DoR (на входе) |
DoD (на выходе) |
Артефакты |
|---|---|---|---|
|
Эпик |
Цель/метрика, границы, риски, high-level архитектура |
Фичи определены и оценены, roadmap согласован |
One-pager, контекст C4 L1, KPI |
|
Фича |
Persona/JTBD, value, NFR, зависимости |
Релизные критерии, включён флаг/откат, документация |
Vision, контракт API, событийная схема |
|
Стори |
AC/BDD, макеты/флоу, тест-данные, DoR чек-лист |
AC/BDD зелёные, лог/метрики, документация, демо |
.feature, SRS-фрагмент, RTM, дашборд |
|
Сабтаск |
Ясная цель, связь со стори |
Юнит/контракт тесты, ревью |
PR, тесты, миграции |
Правило: любая стори без AC/BDD, без инструментации (лог/метрики/trace) — не проходит DoR.
Структурированный backlog (артефакт)
Минимальный шаблон карточки (Jira/YouTrack)
- Type: Epic/Feature/Story/Spike/Bug
- Title: коротко, по-доменному
- Description: «Как [персона], я хочу [цель], чтобы [ценность]» + контекст
- Acceptance Criteria (Given/When/Then)
- NFR: latency, availability, security, data freshness…
- Links: SRS/OpenAPI/AsyncAPI, диаграммы, макеты, .feature
- Dependencies / Blocks
- Class of Service: Standard/Fixed Date/Expedite/Intangible
- Risk: H/M/L + описание
- Size: Story Points или T-shirt
- Owner: контакт
- DoR/DoD чек-боксы
Пример структурного вида (YAML, фрагмент)
epic: "E-101 Оплата и Возвраты v1"
kpi: {checkout_cnv_abs: "+1.5pp", refund_lt_p95: "<2m"}
features:
- key: F-201 "Создание платежа"
nfr: {p95_latency: "2.5s 08-23", availability: "99.9%/q"}
stories:
- key: S-301 "Оплата минимальной суммой"
ac:
- "Дано заказ O1… Когда POST /payments amount=0.01… Тогда 201 и событие payment.authorized.v1"
bdd: "tests/bdd/payments/create_payment.feature::Сценарий: Успех 0.01"
links: {openapi: "/v1/payments", er: "payment ER v2"}
cos: Standard
size: 3
- key: S-302 "Идемпотентность платежа"
ac:
- "Повтор с тем же Idempotency-Key → тот же paymentId"
cos: Standard
size: 3
- key: S-303 "PSP недоступен → 202"
cos: FixedDate
nfr: {queue_lag_p95: "<=5s"}
size: 5
- key: F-202 "Создание возврата"
stories:
- key: S-311 "Частичный возврат ≤ captured"
size: 3
- key: S-312 "Лимиты ролей оператора (ABAC)"
size: 5
spikes:
- key: SP-01 "PoC PSP v2 gRPC"
exit: ["метрики", "библиотека клиента", "черновик контракта"]
Декомпозиция: как резать эпик быстро и правильно
Алгоритм (30–60 минут на фичу)
- Сформулируйте outcome (метрика/поведение).
- Нарисуйте user flow (с «ошибочными» ветками).
- Выделите вертикали: Happy Path (минимум) + 2–3 альтернативы.
- Для каждой — напишите AC (Given/When/Then) и NFR.
- Проверка INVEST и DoR.
- Расставьте зависимости/классы обслуживания (есть ли fixed date?).
- Привяжите инструментацию (лог/метрики/trace).
Хитрости слайсинга
- Сначала правила (business rules) — минимальный набор, без кастомизаций.
- Отдельной стори — идемпотентность и ошибки/202 (если блокируют релиз).
- Вынесите интеграцию с внешней системой в фичу со «заглушкой» (contract-first), затем заменить на real.
- Отложите «дорогие» NFR в отдельные стори, если есть безопасная деградация.
Оценка и приоритизация (Lean-подход)
WSJF (упрощённый)
- Value (бизнес-ценность), Time Criticality, Risk Reduction/Opportunity Enabler, / Job Size.
- Работает, когда сравниваете много. Для коротких очередей — достаточно классов обслуживания и фикс-дат.
Little’s Law и WIP
WIP = Throughput × Lead Time.
Снижая WIP (лимиты Kanban), понижаете lead time → быстрее обратная связь. SA следит, чтобы не «раздували» Refinement/Design-In-Progress.
Метрики потока
- Lead/Cycle time p50/p85; Throughput/неделю; CFD; % блокирующих карт.
- Для backlogs: stale rate (карты без апдейта > 30 дней) — симптом гниения.
Риски и анти-паттерны (и что делать)
|
Анти-паттерн |
Симптом |
Что делать |
|---|---|---|
|
Горизонтальные слои |
UI/DB/API отдельно, нечего демить |
Резать вертикали; «Happy Path» + альтернативы |
|
«Вода» вместо AC |
«Готово», но споры на демо |
AC в Gherkin, .feature как источник правды |
|
Стори-монолит |
> 5 дней на реализацию |
Further slicing по SPIDR |
|
Спайк без выхода |
«Исследовали», но непонятно что дальше |
Явные критерии выхода, артефакт решения |
|
Отсутствие DoR |
Взяли сырьё в спринт |
DoR-чек-лист; стоп-фактор на планинге |
|
Переполненный WIP |
Много «в работе», мало «done» |
Лимиты, pull-правила, резка задач |
|
Нефункциональные забыты |
p95/ошибки в проде |
Включить NFR в Definition Mapping и AC |
|
Канбан без политик |
Хаос приоритетов |
Классы обслуживания, SLE, правила эскалации |
Роль SA в ритуалах (пошагово)
- Backlog Refinement: готовите карты по DoR; приводите данные/макеты/контракты; отмечаете риски/зависимости; предлагаете вертикальные срезы.
- Sprint Planning: убеждаетесь, что каждая выбранная стори демонстрируема; фиксируете DoD/инструментацию.
- Daily: снимаете блокеры (внешние доступы, ответы систем), синхронизируете требования.
- Review: демите против AC/BDD; собираете фидбек; фиксируете follow-up.
- Retro: обновляете Definition Mapping, DoR/DoD и политики потока.
Артефакт: «Структурированный backlog» (чек-лист)
- Эпик: цель/метрика, границы, риски, C4 L1.
- Фичи: value, NFR, зависимости, класс обслуживания.
- Стори: AC (Gherkin), BDD-файл, ссылки на SRS/OpenAPI/ER/макеты.
- DoR: поля формы заполнены; тест-данные; owner; риски; инструментация.
- DoD: AC зелёные; логи/метрики/trace; документация; демо.
- Спайки: критерии выхода; артефакт решения.
- Политики Kanban: WIP-лимиты; SLE; классы обслуживания; правила expedite/fixed date.
- Метрики: lead/cycle, throughput, CFD; stale rate.
Практика: «Декомпозиция эпика в сториз» (60–120 мин)
Входной эпик: «Как покупатель, я хочу оплачивать заказ картой, чтобы сразу получить подтверждение»
Ограничения: p95 POST /payments < 2.5с (08–23), fallback 202 при недоступном PSP, идемпотентность.
Шаги:
- Нарисуйте user flow (Happy Path + PSP timeout + decline).
- Сформируйте 3–4 фичи (например, «Создание платежа», «Страница результата», «Идемпотентность», «Деградация 202»).
- Для каждой фичи разрежьте 6–10 стори (вертикально), каждой — AC и NFR.
- Отметьте классы обслуживания (есть ли fixed date?) и зависимости.
- Проставьте DoR/DoD, добавьте ссылки на контракты/макеты/.feature.
- Сверьте с Definition Mapping (таблица выше).
- (Опционально) оцените WSJF; установите WIP-лимиты для колонок.
Критерии зачёта:
- Каждая стори демонстрируема, имеет AC/BDD и NFR.
- Есть вертикальные срезы Happy Path и альтернатив.
- DoR/DoD заполнены; инструментация указана.
- Отмечены риски и зависимости; классы обслуживания определены.
Вопрос–Ответ
В: Чем фича отличается от стори?
О: Фича — релизуемая часть ценности (может включать несколько стори). Стори — минимальный вертикальный инкремент, проходящий весь цикл и закрывающий часть поведения.
В: Когда делать спайк, а когда обычную стори?
О: Спайк — если есть значительная неопределённость (технология/протокол/объёмы) и нельзя оценить стори. Выход спайка — решение/замеры/контракт. Без этого спайк — пустая трата времени.
В: Как вписать NFR в Agile?
О: NFR — часть DoR/DoD и AC. Для сложных NFR делайте отдельные стори (перф-тесты, кэш, ретраи). Отслеживайте через observability-спецификацию.
В: Что делать с багами и техдолгом?
О: Явные типы карточек; для техдолга — intangible класс обслуживания; лимит доли долга в спринте или отдельный поток с WIP-лимитом.
В: Как бороться с «долго в работе»?
О: Снижать WIP, уменьшать размер стори, ограничивать незавершённый дизайн/рефайн, вводить SLE и «aging WIP» алерты.
В: Можно ли разрабатывать без макетов/прототипов?
О: Не рекомендуется. Минимум — low-fi wireframe и user flow; иначе растёт риск переделок.
Шпаргалка (коротко)
- Режьте вертикально; каждый инкремент — демонстрируемая ценность.
- AC/BDD + NFR — в каждой стори (DoR).
- Спайк = вопрос → эксперимент → решение (а не «подумаем»).
- Definition Mapping: синхронизируйте DoR/DoD и артефакты на всех уровнях.
- Kanban-политики: WIP-лимиты, классы обслуживания, SLE.
- Мерьте lead/cycle/throughput, смотрите CFD, тушите «aging WIP».
- Обязательна инструментация: логи/метрики/trace — часть «готово».
