Три изменения одной версией, потому что все три про одно — можно ли оценить задачу, не открывая код. PLAN.md → ROADMAP.md. Слово «план» значило в репозитории три разных вещи: оглавление целей, план реализации внутри задачи и PLAN.json разовой адаптации. Переименовано целиком — ключ конфига tasks.plan → tasks.roadmap, --index roadmap, --roadmap-sections, --roadmap. Старый ключ в docs/.pm.json не игнорируется молча: скрипт останавливается кодом 3 и называет переименование, иначе проект искал бы опечатку там, где на самом деле версия канона. Род работы — тег kind:feature|fix|chore|research, вторая ось поверх типа записи. В один префикс их не свести: идея бывает про функцию, эпик функцией и является. Дом — тег, потому что теги здесь единственный механизм разметки, а list --kind работает даром; цена принята — в строку индекса род не попадает. Словарь закрыт, иначе он разъедется на bug/bugfix/fix/defect. Отдельно легализован chore: у него «что станет наблюдаемо иначе» отвечается разработчику, а раньше такие задачи либо не заводились, либо придумывали себе пользовательскую пользу — и это второе хуже, оно проходит проверку. Раздел «Затрагивает» — границы, которых изменение касается: эндпоинт, таблица и миграция, формат на диске, публичный тип пакета. Без него задача оценивается по объёму текста, а не по объёму поверхности. Механизируется только наличие непустого раздела: полноту перечня машина не видит. Род и границы требуются к взятию в спринт, а не к заведению — тот же приём, что уже работает для критериев приёмки, и по той же причине. check о пропаже только напоминает: иначе два живых проекта покраснели бы на 98 задачах, заведённых до этого решения. Плюс правила языка задач: англицизм, у которого есть русское слово, заменяется; термин не из паспорта, архитектуры или конвенций вводится строкой или не употребляется; задача, которую не удаётся сказать просто, чаще всего не одна задача. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6.8 KiB
Декомпозиция и мозговой штурм
Обе операции превращают одну запись в несколько (или в ноль). Разница во входе: декомпозиция дробит готовую задачу или эпик, штурм прорабатывает идею, которая ещё не задача.
Тест декомпозиции
Задачу можно дробить, только если части удовлетворяют обоим условиям:
- Мерджатся независимо. Часть Б не требует, чтобы часть А была уже влита. Есть порядок «сперва А, потом Б, иначе не собрать» → это не декомпозиция, а план реализации: шаги остаются внутри одного файла.
- Каждая даёт видимую пользу. Часть, полезная только в комплекте с другой, — не самостоятельная задача. Пользу проверяй тестом «готова к взятию» (task-format): что станет наблюдаемо иначе именно от этой части и какие у неё собственные критерии приёмки.
Не проходит хотя бы одно — не дроби. Ложная декомпозиция плодит файлы, которые нельзя взять поодиночке, и переоценка потом склеивает их обратно.
Цель наследуется. Все части несут goal: родителя: декомпозиция не меняет
того, чему работа служит. Если у части цель другая — это признак, что дробили не
по той границе, либо что часть вообще из другой работы.
Что делать с родителем
После разделения родитель не остаётся третьей висящей строкой:
- части полностью замещают его →
close <slug> --reason "разложена на a, b".REJECTED.mdздесь — не «выкинули», а именно тот след, что переживает запись: через квартал вопрос «куда делась задача X» отвечается строкой со ссылками на наследников, а не археологией git; - родитель осмыслен как зонтик →
edit <slug> --type epic, тело — ссылки на задачи-части, своих шагов у него нет. Эпик не берётся в спринт и живёт ровно до тех пор, пока не закрыта последняя часть.
Зонтик, который перестал быть временным и описывает направление, а не работу, —
это уже цель, а не эпик. Тип на месте не меняется (цель живёт в другом
индексе): заводится [goal] в ROADMAP.md, задачи получают --goal <новый слаг>,
эпик закрывается с причиной-ссылкой.
Когда декомпозиция случается посреди спринта
Задача, которая переросла в эпик, распознаётся до того, как под неё заведено
предложение об изменении: иначе его придётся выбрасывать. Она помечается
[epic], выходит из набора (sprint drop … --reason "переросла в эпик"), уходит
на декомпозицию, а спринт продолжается остальными. Части заводятся сразу, но в
текущий набор не добавляются — набор заморожен.
Мозговой штурм идеи
Идея ([idea]) не проходит тест «готова к взятию»: неясно, что именно делаем.
Штурм проясняет — и это generative-операция, а не applicative.
Applicative-штурм («перечисли задачи, следующие из идеи») выдаёт очевидное: перечисляется то, что уже видно в формулировке. Ценное — на уровень выше.
- Сперва — формы, а не задачи. Предложи три разные постановки идеи и назови компромисс каждой: что она даёт, чем платит, что оставляет за бортом. Если получилась одна постановка — штурм не состоялся, это applicative.
- Вынеси формы пользователю через
AskUserQuestionс компромиссами. Рамку выбирает он: это продуктовое решение, не механика. - Назови цель. Выбранная форма служит какой-то цели — существующей или
новой. Идея, для которой цель не находится, скорее всего уезжает в
REJECTED.md, а не заводится задачей. - Только выбранную форму дроби по тесту декомпозиции выше и проставь критерии приёмки: без них наследники останутся идеями под другим именем.
«Выкинуть» — полноправный исход штурма, а не его неудача. Проработка, честно показавшая, что пользы нет или она несоразмерна цене, — это результат: идея уезжает с этой самой причиной, и та причина гасит её повторное появление.
Доклад
- Идея/задача на входе, выбранная рамка (для штурма), задачи-наследники со слагами, целями и секциями.
- Судьба родителя: удалён / стал эпиком / стал целью / выкинут с причиной.
tasks.py checkпосле правок.- Границы покрытия: какие постановки рассмотрены и какие сознательно отброшены — чтобы штурм не пришлось повторять с нуля.