Пара плагинов с намеренно проведённой границей: av-dev-tasks отвечает за то, что делаем и в каком порядке, av-dev-pipeline — за то, как ведём одну задачу. Зависимости между ними нет: управление задачами работает и с ручным исполнением, пайплайн — на проекте с любым учётом задач. - av-dev-tasks — преемник av-dev-backlog: цели вместо приоритетов, спринт под одну цель с заморозкой набора, различение вопроса и блокера, каденция «вопросы — разбор — переоценка — набор». Раскладка docs/tasks с items/, PLAN.md, BACKLOG.md, SPRINT.md, REJECTED.md; проверенное из av-dev-backlog перенесено, не переписано. - av-dev-pipeline — вынос того, что лежало копиями в healthlog и jellybit (3628 строк) и уже разошлось: цикл SDD, конвейер ревью с обязательным триажем, прогон нескольких задач разом. Проектная специфика вынесена в файл-бриф, charter'ы несут метод. Коммит фиксирует состояние на момент ревью: три прохода нашли блокирующие дефекты (нет шага, заводящего бриф; git rebase на занятой worktree ветке; sprint drop пишет наполовину) — они чинятся следующими коммитами. Сохранено как база, от которой видно правки.
15 KiB
name: session description: Ритуал между спринтами и ведение самого спринта: разбор накопившихся вопросов, разбор прошедшего спринта про процесс, переоценка задач порциями, выбор цели и набор нового спринта с заморозкой. Плюс правила по ходу спринта — что врывается в замороженный набор, чем вопрос отличается от блокера, когда задача выходит из спринта, что считается сделанным и что идёт в доклад. Использовать, когда просят закрыть или начать спринт, собрать набор, разобрать вопросы, провести груминг/переоценку/ретроспективу, решить «что делать дальше» или доложить итоги. Формат и содержимое задач — скилл tasks.
Сессия между спринтами
Работа идёт спринтами: набор задач под одну цель, замороженный до конца
спринта. Между спринтами — одна сессия из четырёх шагов. Этот скилл владеет
ритуалом: как сессия проводится и как спринт ведётся. Форматом и содержимым
задач владеет скилл tasks, выполнением задачи — пайплайн проекта.
Почему не Scrum
Терминология близка — спринт, груминг, определение готовности, ретроспектива, — и это удобно: не нужно изобретать слова. Но добрая половина Scrum существует ради синхронизации людей, которых здесь нет.
Не берём: тайм-бокс (спринт ограничен объёмом, а не временем), velocity и оценки в очках, ежедневный стендап (стендап — это и есть диалог), планирование отдельно от груминга (владелец беклога один), роль скрам-мастера.
Берём: цель спринта, заморозку набора, определение готовности, груминг — каждое потому, что снимает решение, которое иначе принимается заново каждый раз. Ретроспективу берём содержанием, но не отдельным ритуалом: она шаг той же сессии. Процесс личный, синхронизировать некого, а отдельная встреча ради трёх вопросов — та самая плата ритуалом без выгоды.
Роли
Человек выбирает цель спринта, разбирает вопросы, держит право на необратимое и на истину в самих данных.
Агент — оркестрация. Он собирает набор под названную цель, ставит задачи, принимает отчёты и докладывает. Кто именно делает задачу — исполнитель, сабагент, пайплайн — дело проекта; сессия про это не знает и знать не должна.
Единицы
- Цель — то, ради чего набирается спринт. Файл
[goal], перечисленный вPLAN.md. Цель постоянна: живёт, пока живёт направление. - Задача — то, что мерджится целиком и даёт видимую пользу.
- Вопрос — решение человека. Не останавливает начатую работу, но блокирует
взятие задачи в спринт. Живёт внутри файла задачи разделом «Вопросы» и тегом
question. - Блокер — состояние, когда спринт не может продолжаться ни одной задачей.
- Спринт — набор задач под одну цель, замороженный до его конца.
Вопрос, блокер, необратимое
| Что это | Когда спрашиваем | Что останавливает | |
|---|---|---|---|
| Вопрос | решение человека | на сессии, пачкой | взятие задачи в спринт |
| Блокер | спринт не может продолжаться ни одной задачей | немедленно | всё |
Право на необратимое — третье и отдельное: что именно необратимо, называет
CLAUDE.md проекта, и спрашивается оно всегда, независимо от спринта.
Блокер определяется исходом, а не одновременностью. Встали разом или
высыпались из спринта по одной — если продолжать нечем, это блокер: спринт
распускается (sprint close --dissolve --reason …), человек спрашивается
немедленно. Иначе спринт, из которого задачи вышли поштучно, выглядел бы штатно
завершённым, а вопросы тихо ждали бы сессии.
Отличать вопрос от застревания:
Есть остаток, который доводится без ответа, — задача продолжается, вопрос записывается в файл. Остатка нет — задача выходит из спринта.
С двумя оговорками, без которых тест ошибается:
Остаток, который материализует нерешённое — записывает в хранилище, журнал, витрину или наружу состояние, зависящее от неотвеченного вопроса, — не остаток. Решение поднимается до начала записи: откатить запись дороже, чем подождать ответ, а иногда невозможно.
Пол для остатка: остаток, из которого пропала польза, названная в хуке, — это не сделанная задача, а вышедшая из спринта.
Заморозка набора
Цель одна. Набор служит ей; задача, не служащая цели, в спринт не попадает,
даже если взять удобно (sprint take это и запрещает). Задача с открытым
вопросом в набор не берётся.
Новая работа падает в беклог, а не в идущий спринт. Решение «врываться или отложить» принимается один раз правилом, а не заново каждый раз. Врывается только два класса:
- Необратимый ущерб — потеря, порча или утечка данных: то, что не чинится доделкой потом.
- Сломан общий станок — красная проверка, на которой стоит определение готовности всех задач набора. Это не новая работа, а починка того, на чём делается вся остальная.
Что в проекте считается необратимым ущербом и что — общим станком, называет
CLAUDE.md проекта. Не названо — спрашиваем человека, а не решаем сами.
Конец спринта — когда каждая задача набора либо сделана, либо вышла с
записанной причиной. Не «все сделаны»: иначе одна застрявшая задача держит
спринт бесконечно. Пустой набор закрывается sprint close — скрипт не даст
закрыть непустой.
Ведение спринта целиком — исходы задачи, определение готовности, приёмка, доклад — references/sprint.md.
Сессия: четыре шага в этом порядке
Это зависимость, а не список.
- Разбор вопросов.
- Разбор прошедшего спринта — про процесс, а не про задачи.
- Переоценка задач порциями.
- Выбор цели и набор спринта. Цель называет человек, набор собирает агент и показывает до старта работ.
Процедура каждого шага, размер и отбор порции, храповик на залежавшихся, формат интерактива и доклад — references/cadence.md.
Инструмент
Тот же tasks.py, что у скилла tasks — оба скилла в одном плагине, путь
общий: tk="$CLAUDE_PLUGIN_ROOT/skills/tasks/scripts/tasks.py". Сессии нужны
прежде всего:
python3 $tk check # с этого начинается любая сессия
python3 $tk list --questions # шаг 1: что накопилось
python3 $tk list --tag sprint:<слаг> # шаг 3: урожай прошедшего спринта, первая порция
python3 $tk list --stale # шаг 3: дальше по залежалости
python3 $tk list --goal <слаг> # шаг 4: кандидаты под названную цель
python3 $tk sprint start --goal <слаг> # шаг 4
python3 $tk sprint take <слаг> … # шаг 4: набор
Правки задач делаются мутациями (edit, move, close), а не редактором:
руками правится только тело файла. Это правило скилла tasks, здесь оно не
пересказывается.
Стимулы, которые процесс создаёт
Правило, которое можно обойти в свою пользу, будет обойдено. Известные обходы и защиты:
- Скрыть блокер — он останавливает всё и выглядит как провал исполнителя. Защита: тест про остаток плюс прямая запись, что объявление блокера неудачей не считается.
- Не записать вопрос на задаче-кандидате, чтобы не вычеркнуть её из ближайшего набора. Защита: вопросы кандидатов разбираются на той же сессии вне очереди порции.
- Занизить критерии приёмки, раз они пол. Защита: расхождение критериев с сутью — дефект критериев, правит их приёмщик, а он не исполнитель.
- Сжать задачу до остатка и отчитаться «сделана». Защита: пол для остатка — польза, названная в хуке.
- Занизить урожай — не заводить найденное по ходу. Защита: поимённая сверка отчётов ревью со списком заведённого, составленным не отчитывающимся: каждая отложенная находка имеет либо слаг, либо строку «не заведена: причина». Нулевой урожай при непустом отчёте виден сразу.
Стимулы внутри пайплайна задачи (занизить требования к проверке, пропустить проход) принадлежат ему и защищены там же.
Слоты проекта
Сессия не знает ни языка, ни сборки, ни CI. Проект обязан дописать в
CLAUDE.md:
- Пайплайн задачи — чем задача выполняется и что входит в его определение готовности. Сессия требует только форму: пайплайн пройден + критерии приёмки проверены поимённо.
- Общий станок — какая проверка, покраснев, врывается в замороженный спринт.
- Необратимое — что спрашивается у человека всегда.
- Где живёт разбор процесса (шаг 2): журнал промахов конвейера, ADR или раздел документации. Нет такого места — шаг 2 производит его первым же заходом, иначе выводы сессии живут один контекст.
- Как критерии приёмки переживают удаление файла задачи — файл удаляется при закрытии, поэтому критерии копируются туда, где их увидит приёмщик (предложение об изменении, описание ветки, тело коммита). Куда именно — решает проект.
- Ориентир по размеру спринта, если он замерялся. Умолчание — 5–8 задач, и это ориентир, а не закон.
Числа проекта (сколько задач в спринте, сколько времени на задачу, каков прирост беклога) — предмет шага 2, а не константы этого скилла.
Чего этот скилл не делает
Не пишет код и не выполняет задачи. Не заводит и не переоформляет задачи сам по
себе — формат и содержимое ведёт tasks (сессия зовёт его операции). Не решает
за человека, какая цель следующая. Не двигает набор идущего спринта.