Аналитик в Agile: груминг, декомпозиция, работа с командой и с неопределённостью

В водопадной картине мира работа аналитика имеет конец: требования собраны, согласованы, подписаны, переданы. В Agile этого конца нет. Требования уточняются, пока фича живёт, а разработка начинается задолго до того, как всё известно. Из этого следует не «документов не надо», а другое: аналитик перестаёт производить документ и начинает производить определённость — порциями, ровно к тому моменту, когда она нужна для следующего решения.

Это статья про механику. Не про ценности Agile (они в Agile и Scrum и ценностях Agile) и не про то, как фасилитировать встречу (это в фасилитации). Здесь — что аналитик физически делает: как выглядит подготовка к грумингу, как резать историю, чтобы каждый кусок был релизуемым, куда девать вопрос, на который ещё нет ответа, и как не стать узким местом, через которое ходит вся информация в команде.

Мы продолжим сквозной пример трека — автовозврат в интернет-магазине. В прототипировании мы превратили «сделайте автовозврат в один клик» в проверенное требование: карточные оплаты, суммы до 3000 руб., две причины, 19% потока заявок, журнал решений с окном отмены 60 минут, SLA 30 минут. Теперь это надо превратить в поток работы для команды на несколько спринтов — и именно здесь ломается большинство хороших требований.

1. Что меняется, когда требования нельзя закончить

1.1. Главная ошибка: тот же документ, только в Jira

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

Причина в подмене цели. Кажется, что задача — описать систему. Настоящая задача — обеспечить следующее решение. Решения бывают разного размера: «берём это в спринт или нет», «как система ведёт себя при отказе банка», «одна таблица или две». Каждое требует своего объёма знания, и он редко совпадает с «описать всё».

1.2. Единица работы — не документ, а решение, которое можно отложить

Полезная привычка: перед любой аналитической работой спросить — какое решение я сейчас обеспечиваю и когда его действительно надо принять? Это принцип последнего ответственного момента: решение принимают не как можно раньше, а как можно позже — но раньше того момента, когда отказ от него станет дорогим.

Требование, написанное до того, как решение стало актуальным, обесценивается: пока оно ждёт, меняется контекст. Это прямое следствие YAGNI в применении к анализу — детальная проработка идеи, которая может не поехать, оплачена дважды: временем на написание и временем на переписывание.

1.3. Два потока: анализ идёт впереди разработки, но не слишком далеко

Работающая модель — два параллельных потока (в литературе dual-track): поток исследования и поток поставки. Аналитик живёт в первом, обслуживая второй. Ключевой параметр — дистанция между потоками. Слишком мало — команда простаивает и берёт в спринт непонятное. Слишком много — вы производите запас требований, который портится.

Обратите внимание на третью секцию. Поток анализа получает вход не только от бизнеса, но и от уже выпущенного: демо S1 меняет критерии S2, а метрика через две недели может отменить S4 целиком. Это и есть причина не прорабатывать глубоко то, что дальше одного-двух спринтов: часть будущих требований вы получите бесплатно, из фактов.

2. Горизонт проработки: определённость как расходуемый ресурс

2.1. Глубина обратно пропорциональна расстоянию

Бэклог — не список одинаково описанных элементов. Это градиент: у ближнего края — готовые к разработке истории с критериями, у дальнего — фразы из одного предложения.

Практическая ценность картинки — в правой части. «Зона перепроработки» — не абстракция: это макеты к фиче, которую отменят, критерии приёмки к идее из «когда-нибудь», подробная схема интеграции с системой, которую заменят. Каждый такой артефакт ещё и вредит дважды: он создаёт ложное чувство обязательства («мы же уже всё описали, давайте делать») и требует поддержки при изменениях.

Обратная ошибка встречается чаще и стоит дороже: ноль проработки на дистанции одного спринта. Команда садится планировать, а история звучит как «сделать автовозврат». Планирование превращается в трёхчасовой сеанс выявления требований с неподготовленными участниками и без нужных людей в комнате.

2.2. Готовность истории: не бюрократический чеклист, а один вопрос

Definition of Ready — идея спорная. Формальный чеклист легко превращается в шлагбаум: «не пущу в спринт без макета», и команда начинает имитировать готовность. Полезная версия DoR — не список полей, а один вопрос:

Может ли команда начать эту работу и не встать через день, если меня не будет?

Если ответ «нет» — назовите ровно то, что заблокирует, и закройте это. Всё остальное в чеклисте — украшение. Для истории S1 из нашего примера ответ раскладывается так:

# Карточка истории в трекере: минимальный набор, без которого работа встанет
id: S1
title: "Автоматический возврат для карточных оплат до 3000 руб."
value: >
  Оператор поддержки не тратит 26 минут на заявки, которые решаются по формальным
  признакам. Ожидаемый охват — 19% потока (около 1600 заявок в квартал).  

# «Что» — проверяемо, «как» — на усмотрение команды
acceptance_criteria:
  - "Заявка с оплатой картой, суммой <= 3000 руб., причиной «передумал» или «не подошёл
     размер», в пределах 14 дней от вручения — решение принимается без оператора"
  - "Хотя бы одно условие не выполнено — заявка идёт в обычную очередь, причина видна оператору"
  - "Деньги отправлены в банк не позже 30 минут после решения; статус виден в заявке"
  - "Повторная отправка одной и той же заявки не создаёт второй возврат"
  - "Функциональность включается флагом autorefund_enabled, по умолчанию выключена"

# Вопросы, на которые ещё нет ответа, но которые не блокируют старт
open_questions:
  - id: Q-41
    text: "Считать 14 дней от даты вручения или от даты отметки курьера?"
    owner: "Марина, руководитель поддержки"
    due: 2026-03-18
    default: "От даты вручения из накладной; если её нет — от даты отметки курьера"
    blocking: false          # решение по умолчанию позволяет писать код
  - id: Q-42
    text: "Кто отвечает клиенту, если банк отклонил возврат?"
    owner: "Марина"
    due: 2026-03-20
    default: "Заявка возвращается в очередь оператора со статусом «отказ банка»"
    blocking: false

# То, что снято с этой истории намеренно
out_of_scope:
  - "СБП и наличные — отдельная история S4"
  - "Отмена решения оператором — S3"
  - "Суммы свыше 20 000 руб. — по регламенту требуют звонка, автоматизации не будет"

links:
  rules: "BR-14 условия автовозврата, BR-15 грейс по срокам"
  contract: "refund-api.yaml v0.3"
  experiment: "H-7 — проверка по данным, 19% пригодных заявок"

Три вещи в этой карточке важнее остальных. Первое — out_of_scope: половина споров на приёмке возникает из-за того, что кто-то считал очевидным включение СБП. Второе — open_questions с решением по умолчанию: работа не блокируется, но неопределённость не потеряна. Третье — ссылки на правила и контракт: сама история умрёт после релиза, а бизнес-правило и словарь должны её пережить (об этом — в документировании).

2.3. Сколько проработки хватает: практические ориентиры

• Текущий спринт: критерии приёмки, состояния и ошибки, контракт интеграции, названный владелец приёмки. Ноль блокирующих открытых вопросов.
• Следующий спринт: нарезано, черновые критерии, вопросы заданы владельцам с датами, зависимости выявлены, порядок величины оценён.
• +2…+3 спринта: понятны цель, границы и главные риски; есть набросок процесса или данных.
• Дальше: одна фраза про ценность. Всё.

Норма для проработки — примерно на 1,5–2 спринта вперёд по объёму. Больше — запас портится; меньше — команда планирует в тумане. Механику right-sizing и оценок разбирает оценка и планирование.

3. Груминг: встреча, после которой команда может начать

3.1. Что это формально и что это на практике

В Scrum Guide 2020 уточнение бэклога (Product Backlog refinement) — не событие, а непрерывная активность: «добавление деталей, оценок и порядка элементам бэклога». Отдельной встречи «груминг» в Scrum нет, и это важно: если вся проработка происходит на одной полуторачасовой встрече в неделю, она гарантированно превратится в чтение тикетов вслух.

Работающая практика — три разных формата, и путать их дорого:

Ошибка — сваливать всё в средний формат. Технические вопросы на восемь человек тратят шесть человеко-часов; спор стейкхолдеров при команде разрушает встречу (см. работу со стейкхолдерами).

3.2. Что аналитик приносит на встречу

Груминг без подготовки — это выявление требований силами восьми человек, самый дорогой способ из существующих. Минимальный комплект подготовки:

1. Цель встречи в одну строку: «выйти с нарезкой автовозврата на истории, которые влезают в спринт, и списком блокеров» — а не «обсудить автовозврат».
2. Схема на одном экране. Диаграмма состояний заявки или sequence обмена с банком. Черновик, от руки — цель в том, чтобы по ней спорили, а не восхищались.
3. Черновик критериев приёмки — намеренно неполный, чтобы команда достраивала.
4. Список открытых вопросов с пометкой, кто владелец и какой у вас default.
5. Факты, а не мнения: «19% заявок подходят по данным за квартал», «средняя обработка 26 минут». Один факт снимает двадцать минут спора.
6. Явно заявленное «чего здесь не будет» — самая сильная часть подготовки.

3.3. Сценарий встречи на 50 минут

Два правила, которые делают эту встречу полезной. Вопросы фиксируются, а не решаются на месте: обсуждение «а как считать 14 дней» с участием восьми человек без Марины — чистая потеря, вопрос уходит в список с владельцем. И на встрече не оценивают то, что не поняли: просьба «дайте оценку» при непонятой истории производит цифру-выдумку, которая потом становится обязательством.

3.4. Пять вопросов, которые вытаскивают неявное

Эти вопросы работают почти на любой истории и стоят по минуте каждый:

1. «Что происходит, когда этого ноль? А когда очень много?» Ноль заявок, 4000 заявок, строка в 300 символов, отрицательная сумма.
2. «Что делаем, если внешняя система не ответила?» Не «ошибка», а: показываем что, повторяем сколько раз, кто узнаёт, что видит клиент, в каком состоянии остаётся заявка.
3. «Кто ещё смотрит на эти данные?» Аналитика, бухгалтерия, поддержка, регуляторный отчёт. Здесь всплывают требования, которых не было ни в одном интервью.
4. «Что должно быть в системе до того, как это станет возможно?» Вытаскивает зависимости и молчаливые предположения о существующем состоянии.
5. «Как мы узнаем через месяц, что это сработало?» Нет ответа — история либо не нужна, либо у неё непроверяемая цель.

3.5. Как это звучит: фрагмент груминга

Ниже сокращённая, но реалистичная запись. Обратите внимание, что находка появляется не из документа, а из вопроса разработчика — и что аналитик не защищает свой текст.

Аналитик:  Цель — выйти с нарезкой автовозврата. Вот схема состояний заявки.
           По данным за квартал 19% заявок проходят по формальным признакам:
           карта, до 3000 рублей, две причины, 14 дней.
Разработчик: 14 дней от чего? У нас в базе три даты: создание заказа,
           отметка курьера, подтверждение получения клиентом.
Аналитик:  По регламенту — от вручения. Какая из трёх дат это в базе?
Разработчик: Ни одна надёжно. Подтверждение получения заполнено у 60% заказов.
Аналитик:  Тогда это открытый вопрос к Марине, до 18-го. Мой default:
           берём вручение из накладной, если пусто — отметку курьера.
           Считаем, что это допустимо, потому что смещение максимум на день.
Тестировщик: А если решение принято, а клиент через час пишет «отмените, я передумал
           отменять»? Деньги уже ушли?
Аналитик:  SLA 30 минут на отправку. То есть в течение 30 минут отмена возможна,
           дальше — нет. Это ровно та история S3 про окно отмены, которую я хотел
           отложить. Похоже, откладывать нельзя: без неё поддержка не включит фичу.
Разработчик: Тогда S1 надо резать иначе. Давайте так: сначала автоматическое РЕШЕНИЕ
           с задержкой отправки на 30 минут, а сама отправка — как есть, руками.
           Это неделя, а не три.
Аналитик:  Это лучше моей нарезки. Проверяю с Мариной, что промежуточный вариант
           ей полезен, и переписываю S1 к пятнице.

Три вещи, которые здесь произошли: техническая реальность (три даты в базе) убила формулировку требования; тестировщик нашёл пропущенное состояние; разработчик предложил разрез лучше авторского. Ни одно из этого невозможно получить, читая тикет вслух.

3.6. Антипаттерны груминга

Больше про поведенческую сторону встреч — в фасилитации и антипаттернах Scrum.

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

4.1. Зачем вообще резать

Маленькая история — не самоцель, у неё четыре конкретных эффекта: обратная связь приходит через дни, а не через месяц; оценка попадает точнее (разброс растёт нелинейно с размером); незавершённая работа в системе меньше, поток быстрее (см. Kanban и поток); и, что важнее всего для аналитика, маленькую историю невозможно описать расплывчато — на её масштабе неопределённость видна.

4.2. Вертикально или горизонтально: главное различие

Горизонтальный разрез (по слоям: UI, API, логика, данные) выглядит естественно для того, кто думает архитектурой, и он же — источник самой обидной категории провалов. У такой истории нет пользователя: «ручки API» нельзя показать на демо, нельзя принять по критериям в терминах бизнеса, нельзя выключить, если фичу отменят. Главный риск при этом всплывает в самом конце — в нашем примере это несовместимость СБП, о которой узнают на пятой истории.

Вертикальный разрез даёт узкую, но полную функциональность: тонкая полоска через все слои. Проверка одной фразой: выключите всё остальное — этот кусок всё ещё можно отдать пользователю? Ответ «нет» означает, что перед вами задача внутри истории (и это нормально, задачи нужны — просто не путайте их с историями).

4.3. Каталог разрезов: чем именно резать

Наиболее практичный набор — SPIDR Майка Кона (пять способов разрезать историю) и расширенный список Ричарда Лоуренса (Humanizing Work Guide to Splitting User Stories). Ниже — те же паттерны на нашем примере.

Два предостережения. Первое: «по нефункциональным» не значит «безопасность потом» — требования, которые нельзя доклеить (изоляция данных, аудит, персональные данные), в первый же кусок и входят, см. нефункциональные требования. Второе: «спайк отдельно» не должен превращаться в спайк вместо работы; у спайка есть таймбокс и форма ответа.

4.4. Дерево решений: как выбрать разрез

Последняя ветка — самая ценная. Большинство плохих нарезок не результат незнания паттернов, а результат отсутствия проверки: разрезали и не спросили себя, кому от каждого куска станет лучше.

4.5. Пример целиком: бэклог автовозврата

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

Что здесь сделано осознанно. S1 включает задержку отправки — искусственное ограничение, которое позволяет выпустить полезный кусок, не решая пока вопрос отмены; это классическая тонкая вертикаль. S2 стоит выше S4, хотя S4 приносит больше пользователей: без журнала поддержка не включит флаг, а значит ценность S1 равна нулю. Порядок в бэклоге определяется не размером ценности, а тем, что открывает поток. Про формальные методы приоритизации — приоритизация.

4.6. Проверка нарезки скриптом

Две ошибки нарезки видны автоматически: история, которая не доходит до пользователя, и зависимости, из-за которых «независимые» истории на деле образуют цепочку или цикл. Проверка — обычная топологическая сортировка (алгоритм Кана).

Псевдокод:

для каждой истории:
    если ни один слой не наблюдаем пользователем или внешней системой -> горизонтальный разрез
построить граф зависимостей
пока есть узлы с нулевой входящей степенью:
    снять узел, уменьшить степени соседей, записать в порядок
если остались узлы -> цикл зависимостей
самая длинная цепочка = глубина, при которой ценность появляется последней

"""Проверка разреза бэклога: наблюдаемость каждой истории и связность зависимостей."""
from collections import deque

# layers: слои, которые история затрагивает; observable: кто увидит результат
BACKLOG = {
    "SP-1": {"layers": {"spike"}, "observable": "команда", "depends": []},
    "S1": {"layers": {"ui", "api", "logic", "db"}, "observable": "оператор", "depends": []},
    "S2": {"layers": {"ui", "logic", "db"}, "observable": "оператор", "depends": ["S1"]},
    "S3": {"layers": {"ui", "api", "logic"}, "observable": "оператор", "depends": ["S1"]},
    "S4": {"layers": {"logic"}, "observable": "оператор", "depends": ["S1"]},
    "S5": {"layers": {"ui", "api", "logic", "db", "bank"}, "observable": "клиент", "depends": ["SP-1", "S1"]},
    "S6": {"layers": {"ui", "db"}, "observable": "руководитель", "depends": ["S2"]},
}

USER_FACING = {"ui", "bank", "report"}  # слои, результат которых кто-то видит снаружи


def review(backlog: dict) -> list[str]:
    """Возвращает список замечаний к нарезке. O(V + E) по времени и памяти."""
    problems: list[str] = []

    # 1. Горизонтальный разрез: история не выходит за пределы кода
    for key, story in backlog.items():
        if story["layers"] & USER_FACING or story["layers"] == {"spike"}:
            continue
        problems.append(
            f"{key}: ни один слой не наблюдаем ({sorted(story['layers'])}) — "
            f"похоже на горизонтальный разрез; кто увидит результат?"
        )

    # 2. Топологическая сортировка: цикл или слишком длинная цепочка
    indegree = {k: 0 for k in backlog}
    children: dict[str, list[str]] = {k: [] for k in backlog}
    for key, story in backlog.items():
        for dep in story["depends"]:
            indegree[key] += 1
            children[dep].append(key)

    depth = {k: 1 for k in backlog}
    queue = deque(k for k, d in indegree.items() if d == 0)
    order: list[str] = []
    while queue:
        node = queue.popleft()
        order.append(node)
        for child in children[node]:
            depth[child] = max(depth[child], depth[node] + 1)
            indegree[child] -= 1
            if indegree[child] == 0:
                queue.append(child)

    if len(order) != len(backlog):
        stuck = sorted(set(backlog) - set(order))
        problems.append(f"цикл зависимостей среди {stuck} — нарезка нереализуема")

    longest = max(depth.values())
    if longest > 3:
        chain = [k for k, d in sorted(depth.items(), key=lambda kv: kv[1]) if d == longest]
        problems.append(f"цепочка глубиной {longest} (хвост: {chain}) — ценность придёт поздно")

    independent = [k for k, d in indegree.items() if d == 0 and not backlog[k]["depends"]]
    problems.append(f"можно начать параллельно: {sorted(independent)}")
    return problems


for line in review(BACKLOG):
    print(line)

S4: ни один слой не наблюдаем (['logic']) — похоже на горизонтальный разрез; кто увидит результат?
можно начать параллельно: ['S1', 'SP-1']

Скрипт честно поймал S4: «причина не подошёл размер» описана как изменение в логике, а не как наблюдаемое поведение. Формулировку надо переписать: «оператор видит, что заявки с причиной “не подошёл размер” закрываются автоматически на тех же условиях». Мелочь, но именно из таких мелочей на приёмке возникает «а как это проверять?»

Сложность обеих проверок — O(V + E) по времени и памяти, где V — истории, E — зависимости; на бэклоге любого реального размера это доли секунды. Смысл не в алгоритме, а в дисциплине: проверка запускается перед планированием, а не после демо.

4.7. Что делать с историей, которую нельзя разрезать

Бывает: требуется вся инфраструктура, или бизнес-ценность возникает только целиком (регуляторный отчёт, миграция). Три работающих ответа:

1. Тонкая вертикаль (walking skeleton). Один самый простой сценарий насквозь, с примитивной реализацией каждого слоя — идея Алистера Кокберна. Проверяет архитектурные стыки на неделе, а не на третьем месяце.
2. Явное признание большого элемента. Иногда честнее сказать «это большая штука на три спринта, вот три контрольные точки», чем расклеить её на семь фальшивых историй.
3. Разделение «работает» и «полностью соответствует». Первый кусок закрывает 80% случаев с явным ограничением, остальное — отдельно, с зафиксированным решением, что до тех пор делается вручную.

4.8. Антипаттерны декомпозиции

5. Работа с неопределённостью

5.1. Три вида «мы не знаем» — три разных лекарства

Слово «неопределённость» скрывает три разные вещи, и лечатся они по-разному. Путаница здесь приводит к тому, что доменный вопрос отдают разработчику на исследование, а техническую неизвестность обсуждают со стейкхолдером.

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

Отдельная категория, которую полезно различать: сложность против запутанности. Лиз Кио в «Estimating Complexity» предлагает простую шкалу — от «делали это много раз» до «никто в мире этого не делал». Если задача в верхней части шкалы, требования вообще не пишутся заранее: сначала эксперимент, потом требование. Попытка описать неизвестное подробно даёт документ-фантазию.

5.2. Открытый вопрос — полноценный элемент работы

Главный практический приём этого раздела: вопрос без владельца и даты — это не вопрос, а надежда. Открытые вопросы живут не в голове аналитика и не в чате, а в трекере рядом с историей, с четырьмя обязательными полями: текст, владелец (человек, не отдел), дата, решение по умолчанию.

Дисциплина простая:

• Один владелец. «Уточнить у бизнеса» не работает; работает «Марина, до 18-го».
• Дата, привязанная к решению, которое вопрос блокирует, а не «когда-нибудь».
• Решение по умолчанию всегда, даже плохое: default превращает блокировку в риск.
• Блокирующий или нет — единственная метка, которая нужна команде.
• Цена ожидания названа вслух: «если ответа нет до 18-го, делаем по default, переделка — примерно день». Это превращает «мне некогда» стейкхолдера в осознанный выбор.

5.3. Жизненный цикл открытого вопроса

Состояние «ПоУмолчанию» — самое важное и самое опасное. Оно позволяет команде не стоять, но накапливает долг: чем дольше решение живёт без подтверждения, тем дороже его отменять. Практика — раз в спринт просматривать список таких решений и добиваться подтверждения по тем, где цена отмены уже выросла.

5.4. Решение по умолчанию: как оно выглядит в критериях

Default — не «сделаем как-нибудь», а зафиксированное поведение, которое можно проверить и отменить. Оно попадает в критерии приёмки как обычный сценарий, с пометкой источника:

# Основание: Q-41, решение по умолчанию от 18.03 (ответа Марины к сроку не было).
# Отменяемо: правило BR-14, вынесено в конфигурацию, переделка — около дня.
Сценарий: Отсчёт 14 дней при отсутствии даты вручения
  Дано заявка на возврат по заказу, дата вручения в накладной не заполнена
  И отметка курьера о доставке — 2026-03-02
  Когда клиент создаёт заявку 2026-03-15
  Тогда заявка не проходит автоматическое решение по сроку
  И оператор видит причину «срок считался от отметки курьера, дата вручения отсутствует»

Последняя строка — приём, который экономит часы разборов: система сообщает, по какому основанию приняла решение. Когда через месяц Марина скажет «мы так не договаривались», разговор пойдёт от факта, а не от воспоминаний. Как это связано с приёмкой — в приёмке, как критерии становятся тестами — в TDD и BDD.

5.5. Обратимость решения определяет цену анализа

Полезная рамка — деление решений на односторонние и двусторонние двери («type 1 / type 2» из письма акционерам Amazon за 2015 год). Дверь в две стороны: ошиблись — вернулись, цена — часы. Дверь в одну сторону: миграция данных, публичный контракт API, схема с потерей информации, обещание клиенту в договоре.

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

5.6. Спайк: как поставить, чтобы он закончился

Спайк — исследование с обязательствами. Формула из четырёх строк:

id: SP-1
question: "Поддерживает ли API банка частичный возврат по СБП без реквизитов от клиента?"
timebox: "2 дня, до 2026-03-19"
answer_form: "Да/нет + фрагмент запроса и ответа + что меняется в S5"
decision_it_unblocks: "Идёт ли S5 в квартал или переносится"

Без question спайк превращается в «поизучать»; без answer_form — в устный рассказ, который через неделю никто не воспроизведёт; без decision_it_unblocks он вообще не нужен. И правило, которое стоит защищать: результат спайка — знание, а не код. Прототип из спайка не едет в прод без переписывания, иначе вы получите постоянную «временную» реализацию (подробнее — в прототипировании).

6. Аналитик внутри спринта: чем занят, пока команда пишет код

6.1. Три потока одновременно

Перекос в первый поток — типичная ловушка: аналитик становится службой поддержки команды и перестаёт готовить следующий спринт, после чего команда планирует в тумане, вопросов становится больше, и петля затягивается. Признак, по которому это ловят: на планировании регулярно обсуждают то, что должно было быть выяснено неделю назад.

6.2. Путь вопроса, который возник в середине спринта

Ключевая обязанность аналитика в спринте — маршрутизация вопросов, а не их аккумулирование в себе. Разница между хорошим и плохим сценарием — в том, чем всё заканчивается.

Разберите этот сценарий по шагам — в нём три отдельных приёма. Шаг 3: аналитик не даёт разработчику ждать, а выдаёт обратимое решение. Шаг 4: вопрос попадает в систему, а не в память. Шаг 6: владельцу сообщают цену ожидания, и именно это обычно приносит ответ за сутки. Шаг 9: ответ закрепляется в бизнес-правиле с версией, а не только в комментарии к тикету — через полгода спросят снова.

6.3. Изменение прилетело в середине спринта: протокол

Изменения — не катастрофа и не «нам же можно, мы гибкие». Гибкость означает, что изменение обрабатывается по правилам, а не проносится мимо. Рабочий протокол из пяти шагов:

1. Понять, что это. Новое требование, уточнение существующего или дефект понимания? Уточнение края («а если суммы ровно 3000?») — обычная работа, дописываем критерий. Новое требование — идёт в бэклог и в приоритизацию, а не в текущую историю.
2. Оценить цену сейчас против цены потом. Иногда доклеить дешевле, чем отдельной историей; иногда наоборот. Считает команда, не аналитик единолично.
3. Показать обмен. «Влезет, если S4 уходит из спринта» — решение владельца продукта. Молча раздувать историю — способ провалить спринт и потерять доверие к оценкам.
4. Зафиксировать письменно в истории: что изменилось, кто попросил, что взамен.
5. Обновить критерии и предупредить тестировщика. Изменение без обновлённого критерия — гарантированный спор на приёмке.

Отдельный красный флаг: обходной канал. Стейкхолдер пишет разработчику напрямую, тот делает «мелочь» за час, история расходится с критериями, а на приёмке выясняется, что поведение не то, которое согласовано. Лечится не запретами, а видимостью: любая договорённость, которая меняет поведение системы, попадает в историю в тот же день.

6.4. Аналитик как узкое место

Самая распространённая системная проблема роли: вся информация ходит через одного человека. Симптомы — очередь вопросов к аналитику, разработчики без контекста, отпуск как остановка работы. Что снижает риск:

• Прямой доступ команды к экспертам. Ваша задача — не быть каналом, а сделать так, чтобы разработчик мог сам спросить Марину о мелочи и знал, что записать результат надо в тикет.
• Знание живёт в артефактах, а не в вашей голове: правила с номерами, словарь терминов, схемы рядом с кодом (см. моделирование данных).
• Парная работа над нарезкой. Резать историю вдвоём с разработчиком быстрее и точнее, чем принести готовую нарезку на встречу.
• Тестировщик как второй читатель критериев. Он найдёт непроверяемое раньше всех и бесплатно.

7. Что чаще всего ломается именно в Agile

Четыре классических поломки требований (из обзора трека) в гибком процессе принимают специфические формы. Гибкость их не устраняет — она их прячет.

7.1. Неявные требования маскируются под «уточним в процессе»

Фраза «разберёмся по ходу» легитимна, когда за ней стоит план: кто разберётся, к какому моменту, что делаем, пока не разобрались. Если плана нет, это отложенный сюрприз: работу берут в спринт, на третий день выясняется, что нет ответа, и история встаёт. Проверка: каждое «уточним» на груминге должно превратиться в открытый вопрос с владельцем и default до конца встречи. Не превратилось — вы не отложили работу, вы её потеряли.

7.2. Противоречия стейкхолдеров всплывают на демо

В водопаде противоречие ловит согласование документа — медленно, но ловит. В Agile документа нет, и два стейкхолдера с разным пониманием одинаково кивают на груминге. Расхождение проявляется на демо: «а почему автомат вернул деньги без звонка?» — и это уже готовая работа. Профилактика: пока история в подготовке, ответить на вопрос «кто ещё считает, что у этого поведения есть последствия для него», и получить от каждого не «ок», а формулировку своими словами. Разница между кивком и пересказом — примерно спринт работы. Механика разрешения — в работе со стейкхолдерами.

7.3. «Хотелки» приходят прямо в спринт, мимо бэклога

Короткий цикл создаёт иллюзию, что просьбу можно вставить в любой момент. Аналитик здесь — фильтр не по власти, а по вопросам: чья задача, что происходит сейчас без этого, сколько таких случаев, как поймём, что помогло. Половина просьб отваливается на втором вопросе. Формулировка, которая работает лучше отказа: «давай запишем как элемент бэклога с этой целью, и обсудим приоритет против S4 — что откладываем?» Приоритет — не ваше решение, но обмен показать обязаны вы.

7.4. Непроверяемые критерии проходят под флагом гибкости

«Должно быть удобно», «работать быстро», «интуитивно понятно» — в Agile такие формулировки проскакивают чаще, потому что «мы же не пишем ТЗ». Итог — спор на приёмке без арбитра. Единственная проверка: можно ли по этому критерию написать тест, не задав ни одного вопроса? Нельзя — переформулируйте в наблюдаемое поведение или число со способом измерения (см. нефункциональные требования).

7.5. Бэклог без карты: 200 историй, никто не помнит зачем

Мелкая нарезка без верхнего уровня даёт свалку: элементы есть, целостной картины нет, дыры в сценарии не видны, приоритизация вырождается в «что кричит громче». Лечится картой историй (user story mapping): сценарий пользователя по горизонтали, детализация по вертикали, релизы — горизонтальными срезами. Карта заодно отвечает на вопрос, которым мучаются на каждом планировании: что можно выкинуть и всё ещё получить работающий путь.

7.6. Псевдовертикальные разрезы и мини-водопад в спринте

Две скрытые формы. Первая: история названа от пользователя, а внутри — одна таблица («как оператор, хочу, чтобы решение сохранялось в БД»). Проверяется вопросом «что увидит оператор, если это выпустить одно?». Вторая: спринт, внутри которого последовательно идут анализ, разработка и тестирование одной большой истории — формально Agile, фактически двухнедельный водопад с тестированием в последний день. Признак: тестировщик всегда занят в конце спринта, а история регулярно не успевает.

8. Где нужен формальный документ, а где хватит доски

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

Практическое правило: рисуйте на доске, фиксируйте решение письменно, и различайте то, что умрёт с релизом, и то, что должно его пережить. История, критерии, схема на груминге — расходный материал. Бизнес-правило, определение термина, контракт и обоснование необратимого решения — постоянный. Именно поэтому в карточке из раздела 2.2 есть блок links: он вытаскивает переиспользуемое знание из умирающего тикета. Развёрнуто про уровни формальности — в документировании и UML для аналитика; классическая формальная сторона — в требованиях к архитектуре.

9. Как понять, что процесс анализа работает

Пять наблюдаемых признаков. Смотреть на них стоит как на симптомы для разговора, а не как на KPI: любая из этих метрик, превращённая в цель, немедленно портится.

Отдельно полезно раз в квартал посмотреть на список решений «по умолчанию, не подтверждённых»: если он растёт, у вас накапливается долг требований, который однажды предъявят целиком. Про инженерные метрики потока — в DORA и метриках.

10. Мини-итог и чеклист

Аналитик в Agile производит не документ, а определённость к сроку. Из этого следует всё остальное: глубина проработки падает с расстоянием до разработки; готовность истории определяется одним вопросом «команда сможет начать без меня»; истории режутся вертикально, потому что горизонтальный кусок нельзя ни показать, ни принять, ни отменить; открытый вопрос живёт в трекере с владельцем, датой и решением по умолчанию; глубина анализа тратится на необратимое, а не на заметное.

Чеклист перед тем, как отдать элемент бэклога в спринт:

• Я знаю, какое решение эта проработка обеспечивает и когда его надо принять.
• Ценность истории сформулирована через наблюдаемый результат для конкретной роли.
• Если выключить все остальные куски, этот всё равно можно отдать пользователю.
• Критерии приёмки проверяемы: по каждому можно написать тест без вопросов.
• Описаны ноль, много, отказ внешней системы, отсутствие прав и повторный запрос.
• Явно записано, чего в этой истории нет (out_of_scope).
• У каждого открытого вопроса есть текст, владелец-человек, дата и default.
• Ни один блокирующий вопрос не остался открытым.
• Названы необратимые решения внутри истории — им уделено больше внимания.
• Бизнес-правила и термины вынесены из тикета туда, где переживут релиз.
• Тестировщик прочитал критерии и не нашёл непроверяемых.
• Понятно, по какой метрике через месяц узнаем, что это сработало.

Источники

• Scrum Guide 2020 — scrumguides.org (уточнение бэклога как непрерывная активность, а не событие).
• Mike Cohn. Five Simple but Powerful Ways to Split User Stories (SPIDR) — mountaingoatsoftware.com.
• Richard Lawrence, Peter Green. The Humanizing Work Guide to Splitting User Stories — humanizingwork.com (полный каталог паттернов и дерево решений).
• Bill Wake. INVEST in Good Stories, and SMART Tasks — xp123.com.
• Jeff Patton. User Story Mapping — jpattonassociates.com (карта историй, срезы релизов, «что можно выкинуть»).
• Alistair Cockburn. Walking Skeleton — alistair.cockburn.us.
• Gojko Adzic. Specification by Example — gojko.net (примеры как общий язык вместо спецификации).
• Ellen Gottesdiener, Mary Gorman. Discover to Deliver — discovertodeliver.com (структурированная проработка на нескольких горизонтах).
• IIBA. Agile Extension to the BABOK Guide — iiba.org (роль анализа в гибких подходах, горизонты планирования).
• Liz Keogh. Estimating Complexity — lizkeogh.com (шкала «делали много раз → никто в мире не делал» и что писать вместо требований).
• Cynefin framework — en.wikipedia.org (почему в сложной области сначала эксперимент, потом описание).
• Donald Reinertsen. The Principles of Product Development Flow — reinertsenassociates.com (размер партии, цена задержки, стоимость запаса требований).
• Martin Fowler. Yagni — martinfowler.com.
• Amazon. Письмо акционерам за 2015 год — aboutamazon.com (решения-двери в одну и в две стороны).
• Dan North. Introducing BDD — dannorth.net (как разговор о примерах заменяет спор о формулировках).

Что дальше

Всё, что описано выше, ведёт к одному моменту: команда говорит «готово», а бизнес смотрит и решает, то это или не то. Именно здесь предъявляют счёт за каждую неточную формулировку, непроверяемый критерий и решение по умолчанию, которое никто не подтвердил. Дальше — как устроена приёмка, которая заканчивается решением, а не спором: кто принимает, по каким основаниям, что делать с расхождениями и как заранее лишить спор почвы.

Приёмка: как проверить, что сделали именно то, и как избежать споров