Декомпозиция задач: вертикально или горизонтально, восемь приёмов и границы дробления

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

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

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

1. Два дерева: WBS дробит результат, бэклог дробит ценность

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

WBS (Work Breakdown Structure, ИСР) — иерархическая декомпозиция полного содержания проекта. Её правила разобраны в главе про устав, содержание и WBS: правило 100% (сумма элементов уровня равна родителю — не больше и не меньше), декомпозиция по результатам, а не по действиям, пакет работ на нижнем уровне с одним ответственным и проверяемым результатом, словарь WBS. WBS отвечает на вопрос «из чего состоит проект» и обязана быть полной.

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

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

Рабочая конфигурация: WBS как чек-лист полноты на старте (особенно для нетехнических веток — юридическая проверка, миграция, обучение пользователей, нагрузочное тестирование), бэклог как инструмент поставки. Связь между ними односторонняя: элемент бэклога всегда прослеживается вверх до элемента WBS, обратное неверно — часть пакетов работ никогда не станет пользовательскими историями, потому что не имеет пользовательской ценности (например, «настроенный контур dev/stage/prod»).

2. Горизонтально или вертикально

Это главное различие в теме, и оно решает больше, чем выбор фреймворка.

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

И почти всегда он неверен. Причин четыре, и все практические.

1. Ни один кусок нельзя показать. Половина функции не работает: у неё нет ни ценности, ни обратной связи. Первый момент истины наступает после сборки всех слоёв, то есть в конце — ровно та задержка, ради устранения которой существует итеративность.
2. Интеграция откладывается на конец и там взрывается. Именно на стыках живут расхождения в понимании задачи: фронт ждёт одно поле, бэк отдаёт другое, в БД оно nullable. Каждый слой по отдельности «готов», а функция — нет; переделка на этой стадии дороже всего.
3. Оценка обманчива. Три горизонтальных куска по 8 часов не дают 24 часов работы: интеграция не принадлежит ни одному из них и потому не оценена вообще (раздел 6).
4. Прогресс невозможно измерить. «Бэкенд готов на 100%, фронт на 60%» не отвечает на единственный интересный вопрос: сколько сценариев работает у пользователя. Ответ — ноль.

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

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

3. Три правила, ограничивающие дробление

Дробление ограничено с двух сторон и связано изнутри. Три правила покрывают все случаи.

Правило потолка: элемент должен помещаться в такт управления. Верхняя граница задаётся не абстрактной «сложностью», а тем, как часто вы хотите получать сигнал. Классический ориентир WBS — правило 8/80: трудоёмкость пакета работ между 8 и 80 часами. Второй ориентир практичнее: пакет не длиннее интервала между отчётами, иначе два подряд статуса «в работе» не сообщают ничего. Третий — регламент оценки из предыдущей главы: фича не больше 8, в крайнем случае 16 часов. Все три — одна и та же мысль в разных единицах: максимальное время, которое вы согласны прожить без новой информации.

Правило пола: элемент должен оставаться осмысленным и проверяемым. Нижняя граница — не «часы», а два свойства. Элемент должен иметь проверяемый результат (его можно предъявить и сказать «да» или «нет») и сохранять смысл отдельно — по названию понятно, зачем он существует. Задача «добавить поле в DTO» проверяема, но бессмысленна в отрыве; она не элемент декомпозиции, а шаг реализации, и его место в голове разработчика, а не в дереве. Численный ориентир: если элементов стало столько, что накладные расходы на их ведение сравнимы с работой, вы прошли пол (количественная оценка — в разделе 8).

Правило целостности: сумма детей равна родителю. То самое правило 100%, применённое рекурсивно. «Не меньше» означает, что работы вне дерева не существует; «не больше» — что в дереве нет элементов, не ведущих к результату (классический их вид — gold plating). Правило кажется очевидным и нарушается постоянно: три подзадачи описывают основной сценарий, а обработка ошибок, миграция старых данных и права доступа не попали никуда — и всплывут как «незапланированные задачи».

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

4. INVEST: шесть свойств хорошего элемента

Билл Уэйк предложил мнемонику INVEST как набор свойств хорошей пользовательской истории. Она полезнее, чем кажется, потому что каждое свойство отвечает за конкретный провал.

Два свойства конфликтуют друг с другом, и это стоит знать заранее. Independent против Small: чем мельче срез, тем труднее сделать его независимым — где-то приходится согласиться на порядок. Valuable против Small: тонкий срез рискует потерять пользовательскую ценность. Разрешение конфликта стандартное: жертвуют независимостью (фиксируя порядок явно), но не жертвуют ценностью и проверяемостью — иначе получается горизонтальный срез, переодетый в историю.

5. Восемь приёмов нарезки

Когда элемент слишком велик, вопрос «как его разрезать» имеет конечное число ответов. Приёмы ниже — сводка из паттернов Ричарда Лоуренса и мнемоники SPIDR Майка Кона (Spike, Path, Interface, Data, Rules).

Три замечания, без которых приёмы применяются неправильно.

Спайк — не «поисследовать». У него обязаны быть таймбокс и вопрос, на который он отвечает. «Разобраться с интеграцией» — не спайк, а бесконечность. «Два дня; выяснить, отдаёт ли смежник остатки по API или файлом раз в сутки; на выходе — переоценка блока» — спайк. Именно так лечится нарушение правила 40% разброса из предыдущей главы: не сужением вилки, а покупкой информации.

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

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

6. Оценка снизу вверх и её систематическая ошибка

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

Отсюда правило из предыдущей главы: считайте двумя способами. Нисходящая оценка (проект целиком по аналогии) и восходящая (сумма листьев) должны сойтись в пределах полутора раз; расхождение больше означает потерянную работу и указывает, где искать. Практическая надбавка за стыки обычно лежит в диапазоне 15–30% и растёт с числом элементов.

Смоделировать это несложно. Модель: чистая трудоёмкость (сумма листьев) не зависит от нарезки, а накладные расходы складываются из постоянной стоимости ведения элемента (завести, описать, проверить, переключить контекст) и стоимости стыков между соседями.

from dataclasses import dataclass, field

OVERHEAD_PER_ITEM = 0.6   # часы: постановка, ревью, приёмка, переключение контекста
SEAM_COST = 1.8           # часы на один стык между соседними элементами одного родителя

@dataclass
class Node:
    """Узел дерева декомпозиции: лист несёт часы, ветка — только детей."""
    name: str
    hours: float = 0.0
    children: list = field(default_factory=list)

def rollup(node):
    """Свод снизу вверх: (чистые часы, накладные часы).
    O(n) по времени, O(h) по памяти под стек рекурсии (n — узлов, h — глубина)."""
    if not node.children:
        return node.hours, OVERHEAD_PER_ITEM
    net = overhead = 0.0
    for child in node.children:
        n, o = rollup(child)
        net += n
        overhead += o
    # k детей у одного родителя дают k-1 обязательных сшивок между собой
    overhead += SEAM_COST * (len(node.children) - 1)
    return net, overhead

def flat_split(total_hours, parts):
    """Плоская нарезка фичи на равные куски — модель «дробим ещё мельче». O(parts)."""
    return Node("фича", children=[Node(f"часть {i}", total_hours / parts)
                                  for i in range(parts)])

print(f"{'кусков':>7} {'часов на кусок':>15} {'чистые':>8} {'накладные':>11} {'итого':>8} {'риск':>7}")
for parts in (1, 2, 4, 8, 16, 40):
    net, over = rollup(flat_split(40.0, parts))
    # грубая мера риска: неизвестность внутри одного куска растёт с его размером
    risk = (40.0 / parts) ** 0.5 * 1.6
    print(f"{parts:>7} {40/parts:>15.1f} {net:>8.1f} {over:>11.1f} {net+over:>8.1f} {risk:>7.1f}")

#  кусков  часов на кусок   чистые   накладные    итого    риск
#       1            40.0     40.0         0.6     40.6    10.1
#       2            20.0     40.0         3.0     43.0     7.2
#       4            10.0     40.0         7.8     47.8     5.1
#       8             5.0     40.0        17.4     57.4     3.6
#      16             2.5     40.0        36.6     76.6     2.5
#      40             1.0     40.0        94.2    134.2     1.6

Числа модельные, но форма кривых верна и подтверждается на практике. Чистая трудоёмкость от нарезки не зависит. Накладные расходы растут линейно по числу элементов и линейно по числу стыков — то есть суммарно быстрее, чем падает риск. Риск, наоборот, убывает как корень: половинное дробление снижает неизвестность внутри куска, но не вдвое. Оптимум лежит там, где предельный выигрыш в риске сравнивается с предельными накладными расходами, — в этой модели между четырьмя и восемью кусками, то есть при размере элемента 5–10 часов. Это и есть арифметическое обоснование правила «8, в крайнем случае 16 часов» из регламента оценки: оно не взято с потолка, а является грубой оптимизацией той же кривой.

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

7. От декомпозиции к расписанию

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

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

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

8. Декомпозиция и ответственность

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

Строки матрицы RACI (глава про делегирование) в классической схеме — это как раз элементы WBS, а столбцы — роли или подразделения. Отсюда полезная проверка: если при заполнении матрицы строка не получает ни одного A, значит, дерево содержит работу-сироту; если строка получает три A, значит, элемент объединяет то, что должно быть разрезано.

Про параллельность стоит сказать отдельно, потому что декомпозицию часто продают как способ ускорения. Дробление не создаёт параллельности само по себе. Куски можно делать одновременно, только если они независимы; зависимые куски, розданные разным людям, дают не ускорение, а ожидание плюс координацию. К этому добавляется закон Брукса: добавление людей к опаздывающему проекту задерживает его ещё больше, потому что число каналов связи растёт как n(n−1)/2, а новичков надо учить. Практический вывод: сначала проверьте независимость, потом раздавайте. Если независимых кусков нет, ускорение достигается не людьми, а сокращением объёма или снятием зависимости — например, договорённостью об интерфейсе и работой на заглушках.

9. Где дробление начинает вредить

Раздел 6 дал количественную границу, здесь — качественные признаки того, что вы её прошли.

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

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

10. Типичные ошибки

11. Как это выглядит в проде

Продуктовая команда, восемь человек. Правило команды на одной строке: «элемент бэклога — это то, что можно выкатить и показать, и что делается не дольше трёх дней». Всё, что не проходит проверку, режется по приёмам из раздела 5 прямо на груминге; если после двух попыток разрезать не получается — вместо элемента ставится спайк на день. Раз в квартал команда сверяется с чек-листом нетехнических веток (миграция, документация, обучение, нагрузочное, юридическая проверка) — это остаток WBS, который бэклог не покрывает.

Интеграционный проект с внешним подрядчиком. Здесь ведут именно WBS: конкурс требует календарного плана с этапами и актами, а границы работ между двумя организациями надо зафиксировать до начала. Дерево разложено до пакетов по 40–60 часов с одним ответственным и словарём WBS, каждая строка сопоставлена с матрицей ответственности. Внутри своего пакета подрядчик режет вертикально и работает итерациями — контракт этому не мешает, потому что фиксирует результат пакета, а не способ его получения.

Где не сработало. Команда перешла на «мелкие задачи» после ретроспективы, где решили, что задачи слишком крупные. Средний размер упал с трёх дней до двух часов, количество тикетов в спринте выросло с 18 до 90. Через два спринта: планирование стало занимать полдня, треть тикетов дублировали друг друга, ни один не был предъявляем отдельно (резали горизонтально), а поставка замедлилась. Вернулись к трёхдневному размеру и вертикальному резу, добавив единственное правило — «каждый элемент проходит от интерфейса до базы». Скорость восстановилась за спринт.

Мини-итог

• Разные цели требуют разных разрезов. Нарезка под оценку, под параллельность, под обратную связь и под ответственность — разные; универсального дерева не бывает.
• Два дерева, и их нельзя смешивать: WBS дробит результат и обязана быть полной, бэклог дробит ценность и принципиально неполон. Рабочая связка — WBS как чек-лист полноты на старте, бэклог как инструмент поставки.
• Вертикальный срез почти всегда лучше горизонтального: тонкий, но целый кусок работает в проде, снимает интеграционный риск сразу и даёт обратную связь после каждого шага. Горизонталь законна только для инфраструктуры, сквозных технических замен и навязанных контрактом границ.
• Три правила ограничивают дробление: потолок (помещается в такт управления: 8–16 часов оценки, интервал между отчётами, правило 8/80), пол (проверяемый результат и самостоятельный смысл), целостность (сумма детей равна родителю). Критерий «достаточно мелко» звучит так: команда даёт оценку, в которую верит, и называет, что предъявит.
• Восемь приёмов покрывают почти все случаи: шаги процесса, бизнес-правила, CRUD, вариации данных, интерфейсы и платформы, основной сценарий против краевых, нефункциональные требования отдельно, спайк. Начинать — с тончайшего сквозного пути.
• Восходящая оценка систематически оптимистична, потому что работа на стыках не принадлежит ни одному листу; накладные расходы растут линейно по элементам и стыкам, а риск падает как корень — отсюда оптимум в районе 5–10 часов на элемент и вред от дробления за его пределами.
• Дерево — карта ответственности и вход в расписание. Один владелец на элемент; если владельца нельзя назначить, элемент разрезан неправильно. Дробление само по себе не даёт параллельности: сначала независимость, потом раздача.

Источники

• Wake B., «INVEST in Good Stories, and SMART Tasks» — шесть свойств хорошего элемента работы.
• Lawrence R., «Patterns for Splitting User Stories» — исходный набор приёмов нарезки.
• Cohn M., «User Stories Applied» и мнемоника SPIDR — компактная версия тех же приёмов.
• Cockburn A., «Walking Skeleton» — тончайший сквозной путь через все слои и интеграции.
• Patton J., «User Story Mapping» — карта историй как способ не потерять целое при дроблении.
• PMI Practice Standard for Work Breakdown Structures — правило 100%, пакеты работ, словарь WBS, правило 8/80.
• Brooks F., «The Mythical Man-Month», 1975 — координационные издержки и почему дробление не равно ускорению.
• Как справиться с декомпозицией задач и не перестараться — практика нарезки и границы дробления.

Что дальше

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

И отдать её можно очень по-разному. Можно передать задачу («сделай вот это вот так»), можно передать решение («реши сам в этих границах»), можно передать ответственность за результат целиком — это три разных операции с тремя разными подготовками и тремя разными рисками. Следующая глава разбирает уровни делегирования и то, почему их называют вслух; матрицу RACI, её родственников и правило «ровно один Accountable на строку»; шаблон постановки задачи, где каждый блок закрывает конкретное место поломки; контрольные точки, отличающиеся от микроменеджмента тремя свойствами; и обратное делегирование — механику, из-за которой чужие задачи незаметно переезжают на стол менеджера.

Читайте: Делегирование и распределение ответственности: уровни, RACI, контрольные точки