av
3849f084be
Тип goal и индекс ROADMAP.md убраны: цель — зонтик над параллельными направлениями, а у проекта на одного человека список работ линеен. Роадмап при этом наполовину дублировал беклог, а «что уже умеет» отвечают спеки и git log индекса. Секция «Готово» удалена, а не перенесена. Вместо цели — ось «стадия проекта»: build (беклог это план стройки, порядок строк значит зависимость, секция одна) и support (очередь правок, порядок значит важность, секции — полки домена). Стадия объявляется ключом [tasks] stage, меняется командой stage, без неё check отказывает: порядок строк нечем прочитать. Ушли теги goal:/decomposed, поле «Секция», раздел «Завершение», флаги --goal и edit --section. Версия раскладки 2 → 3, перевод проекта расписан записью журнала.
157 lines
13 KiB
Markdown
157 lines
13 KiB
Markdown
# Порции, разбор и расстановка
|
||
|
||
Процедура шагов 2–4 груминга. Рамка и правила — [SKILL.md](../SKILL.md).
|
||
|
||
Начинается всё с `tasks.py check` (и `check --fix`, если дрейф накопился) —
|
||
результат идёт строкой в доклад.
|
||
|
||
## Шаг 2. Разбор вопросов
|
||
|
||
`tasks.py list --questions` — всё, что накопилось. Порядок по каждому вопросу:
|
||
|
||
1. **Проверь, не отвечен ли он уже** — решением, документом, соседним
|
||
изменением, самим ходом сделанной с тех пор работы. Отвеченный вопрос не
|
||
выносится человеку: это самая частая находка и она не требует ничьего
|
||
решения.
|
||
2. **Сформулируй развилку** с вариантами и последствием каждого, рекомендация —
|
||
первым вариантом.
|
||
3. **Вынеси пачкой** через `AskUserQuestion`, не больше трёх за раз.
|
||
4. **Запиши ответ в тело задачи, опустоши раздел «Вопросы»**, сними тег
|
||
(`edit <slug> --rm-tag question`), **перепиши «зачем»**: «Решено: …» на вопрос
|
||
«почему это лежит в беклоге» уже не отвечает. Опустошение раздела — не
|
||
уборка, а условие взятия: правило и причина в скилле `task-track`,
|
||
[references/task-format.md](../../task-track/references/task-format.md).
|
||
|
||
**Вопросы на верхних строках очереди разбираются вне очереди порции** — здесь
|
||
же, даже если сама задача в порцию переоценки не попала. Иначе правило «задача с
|
||
открытым вопросом в работу не берётся» создаёт стимул вопрос не записывать, лишь
|
||
бы не вычеркнуть задачу из ближайшей работы.
|
||
|
||
## Шаг 3. Что перестало быть важным
|
||
|
||
Цель — выкинуть то, что перестало быть задачей, и вернуть остальному честное
|
||
состояние. Не «пересмотреть всё», а «пересмотреть порцию до конца».
|
||
|
||
### Порция и правило остановки
|
||
|
||
- **5–8 задач за порцию.** Размер обоснован усталостью, а не пропускной
|
||
способностью, и менять его не надо — **надо брать несколько порций**.
|
||
- **Отбор порций по порядку:**
|
||
1. **свежее** — заведённое с прошлого груминга: оно ещё не проходило ни одной
|
||
проверки на нужность. Свежесть меряется git'ом, как и залежалость, — датой
|
||
появления файла в истории;
|
||
2. дальше **по залежалости** — `list --stale`;
|
||
3. по потребности — одна секция целиком, один тег (партия ревью), список от
|
||
человека.
|
||
- **Останавливайся на границе порции**, даже если «ещё чуть-чуть осталось».
|
||
Между порциями — промежуточный доклад.
|
||
|
||
### Что делать с каждой задачей
|
||
|
||
Сперва то, что не требует ничьего решения:
|
||
|
||
1. **Проверь, не сделано ли уже.** Задача, реализованная попутно в соседнем
|
||
изменении, — самая частая находка. Смотри код, документацию, историю коммитов
|
||
по ключевым словам. Удаление «как реализованной» деструктивно и без следа
|
||
(в `REJECTED.md` реализованные не пишутся), поэтому порог улики жёсткий:
|
||
`close <slug> --implemented` только имея **конкретный коммит или строку
|
||
документа**, закрывающие задачу, и ссылка идёт в доклад. Есть лишь косвенные
|
||
признаки — не удаляй сам, вынеси в пачку вопросов. Сделана частично → задача
|
||
сжимается до остатка: тело правишь редактором, заголовок и «зачем» — через
|
||
`edit`.
|
||
2. **Проверь, не отменена ли решением.** Документ, ADR или архивное изменение
|
||
мог закрыть вопрос иначе — тогда `close <slug> --reason "<ссылка на
|
||
решение>"`. Задача закрывается не только коммитом.
|
||
3. **Проверь пересечения.** Две задачи об одном — содержимое в одну, вторую
|
||
`close <slug> --reason "слита с <другой-слаг>"`. Смотри **шире порции**:
|
||
интейк дедуплицирует новое против существующего, но никогда не пересматривает
|
||
уже лежащее, и две задачи с одной причиной могут лежать рядом месяцами.
|
||
4. **Пере-кластеризуй по общей причине.** Несколько задач, оказавшихся симптомами
|
||
одного дефекта, сливаются в одну — это находка, которую интейк дать не мог.
|
||
5. **Гигиена полей** — протухшее «зачем», вопрос в прозе, снятый ответ, свойство
|
||
репозитория в рамках, предписание процесса в теле, тип, разошедшийся с
|
||
задачей, границы вместо реализации в разделе «Затрагивает». Список и правила —
|
||
в скилле `task-track`. **Груминг — то самое место, где беклог добирает тип и
|
||
разделы его схемы:** требовать их на входе значило бы выгонять в заметки то,
|
||
что должно лежать задачей, а к взятию в работу они уже обязательны (`ready`).
|
||
Блок здоровья `check` печатает, сколько записей готово к взятию, — по этому
|
||
числу и видно, добрал ли груминг.
|
||
|
||
Гигиена — **побочный продукт, а не предмет**. Тридцать полей вместо трёх
|
||
решений о важности означают, что груминг не состоялся.
|
||
|
||
Затем — то, что решает человек:
|
||
|
||
6. **Жива ли она вообще.** Контекст мог измениться: ушла зависимость, отпал
|
||
сценарий, обошли иначе. Здесь и звучит вопрос, выкидывать ли.
|
||
7. **Тот ли тип.** Заводилась починкой, а после разбора оказалось, что
|
||
поведение никогда и не было заявлено, — это `feature`. Тип, оставшийся от
|
||
прошлой формулировки, врёт ровно там, где по нему отбирают, и требует не тех
|
||
разделов.
|
||
8. **Задача ли это по-прежнему.** Не проходит `ready` по существу, а не по
|
||
недописанным разделам → `edit <slug> --type research` и опустошённый раздел
|
||
«Вопрос», то есть сырьё; дальше штурм. Разрослась → это несколько задач,
|
||
дальше декомпозиция.
|
||
9. **Не подешевела ли она.** Сделанная с прошлого раза работа меняет цену
|
||
**других** задач: рядом с только что тронутым кодом та же работа стоит меньше.
|
||
Это довод и на шаге 4 — задача, внезапно подешевевшая, поднимается в очереди
|
||
не потому, что стала важнее, а потому, что окно открыто.
|
||
|
||
### Храповик на залежавшихся
|
||
|
||
Сильно залежавшаяся задача — сигнал сама по себе: её либо ни разу не собирались
|
||
делать, либо нечем взять. Измеряй наблюдаемым — датой последней правки из git
|
||
(`list --stale` ставит такие первыми); счётчик «сколько грумингов пережила»
|
||
нигде не хранится.
|
||
|
||
Задача из верхних строк `--stale`, которую и этот заход оставляет без изменений,
|
||
**либо двигается (меняет полку, поднимается в очереди, уходит с причиной), либо
|
||
остаётся с явно записанной причиной**, почему её держим (`move <slug> --reason
|
||
…` — без `--section` секция берётся текущая). Молчаливое «оставить как есть» на
|
||
давно неподвижной задаче — это решение не принимать решение; запись причины
|
||
превращает его в осознанное и не даёт тому же вопросу всплыть на следующем
|
||
груминге.
|
||
|
||
## Шаг 4. Что важно сейчас — расстановка
|
||
|
||
Разбирается **верх очереди**, а не весь беклог: первые три-пять строк каждой
|
||
секции. Ниже пятой строки порядок всё равно перестаёт что-либо значить.
|
||
|
||
1. **Покажи текущий верх** — `list`, по секциям, в том порядке, в каком строки
|
||
лежат.
|
||
2. **Спрашивай сравнением, а не оценкой.** «Что из этих двух делают раньше»
|
||
имеет проверяемый ответ, «насколько важна эта задача» — нет. Веди попарно и
|
||
сверху: что первое, что после него.
|
||
3. **Двигай командой, с причиной** — `move <slug> --after <другой> --reason …`
|
||
или `move <slug> --first --reason …`. Довод берётся из перечня в
|
||
[SKILL.md](../SKILL.md#приоритет-как-его-расставляют): сломано сейчас,
|
||
разблокирует остальное, дешевеет от сделанного, дорожает от ожидания,
|
||
названо человеком.
|
||
4. **Проверь верх на готовность** — `tasks.py ready <слаг> …` по первым строкам.
|
||
Задача, стоящая первой и не проходящая `ready`, — это очередь, которая врёт:
|
||
взять её нельзя. Либо дописывается здесь же, либо уступает место.
|
||
|
||
Пример одной итерации:
|
||
|
||
> **Верх секции «Игра», сейчас в таком порядке:**
|
||
> `board-render-once` · `draw-before-full-board` · `move-parse-strict`
|
||
>
|
||
> 1. Что делаем первым?
|
||
> - `draw-before-full-board` *(рекомендую)* — ничья объявляется на неполном
|
||
> поле: игра врёт о результате, это сломано сейчас
|
||
> - `board-render-once` — печать поля дублируется; мешает всякой правке
|
||
> отрисовки, то есть разблокирует остальное
|
||
> - оставить как есть
|
||
> 2. `move-parse-strict` — третьей или выше?
|
||
> - Оставить третьей *(рекомендую)* — ошибка ввода видна игроку сразу
|
||
> - Поднять второй: тот же разбор трогает `board-render-once`, окно открыто
|
||
|
||
Каждый вариант несёт причину — ту самую, что уедет в `--reason`.
|
||
|
||
## Что делать, если разбирать нечего
|
||
|
||
Беклог пуст или в нём три задачи и все живые — груминг кончается за минуту, и
|
||
это законный исход. Скажи строкой: очередь такая-то, сдвигать нечего. Придумывать
|
||
работу, чтобы груминг «состоялся», — ровно тот ритуал без выгоды, от которого
|
||
процесс избавлялся.
|