Implementation sprint как delivery

1. Спринт — это управление, а не спешка

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

Замороженный SPEC.md уже ответил на что вы строите и зачем. Спринт отвечает на другое — что именно вы делаете сейчас ради показываемого результата за отведённое время. Не разделите эти плоскости — и будете каждый день заново спорить с проектом: сегодня главное импорт CSV, завтра график, послезавтра новая интеграция, и всё срочное разом.

Полезно думать о спринте как о канале, через который спецификация превращается в проверяемые куски работы.

flowchart TD
    A[SPEC.md] --> B[Core flow]
    B --> C[Must-have backlog]
    C --> D[Текущий slice]
    D --> E[Diff + проверка]
    E --> F[Commit]
    F --> G[EVIDENCE_LOG.md]

Здесь самое важное звено — core flow. Именно он диктует, что становится must-have. Для MVP типа Personal CFO core flow звучит как «загрузить CSV, разобрать транзакции, получить месячный отчёт». Для feature in existing codebase — один воспроизводимый пользовательский сценарий. Для migration slice — один pilot-переход плюс валидированный результат, а не «обновить весь мир до последней версии». Для team workflow design — «issue → plan → reviewer-agent → review notes». Формат разный, принцип один: спринт обслуживает один центральный сценарий, а не все хорошие идеи сразу.

Именно поэтому delivery-режим и выглядит чуть скучнее, чем хочется: он каждый день спрашивает не «что ещё улучшить», а «какой минимальный шаг приближает core flow к демонстрации». Скучно? Немного. Работает? Очень.

2. Из spec в backlog: must-have и парковка идей

Спецификация — это не backlog. На этом месте многие и попадаются: открываете SPEC.md, видите умный взрослый текст и почти автоматически верите, что дальше можно просто кодить. Но между спецификацией и реализацией обязательно нужен переводчик — им и становится sprint backlog.

Хороший backlog не обязан быть красивым — он обязан быть прозрачным. В нём видно: что входит в обязательный результат спринта, что улучшает проект, но для показа не критично, и что за пределами отрезка. Трёх зон хватает: must-have, nice-to-have, later.

Ниже — пример для capstone в формате Personal CFO.

# Бэклог спринта — Personal CFO

## Must-have
- M-1 загрузка sample CSV
- M-2 разбор строк и валидация дат
- M-3 месячный отчёт по категориям

## Nice-to-have
- N-1 подсветка повторяющихся подписок
- N-2 экспорт отчёта в PDF

## Позже
- L-1 мультивалютность
- L-2 интеграция с банком

Здесь важно одно. Must-have — это не «всё полезное», а только то, без чего core flow не завершится. Нет месячного отчёта — проект не готов. Отчёт есть, PDF пока нет — проект живёт дальше. PDF не сидит рядом с обязательными кусками лишь потому, что смотрится эффектно.

Очень помогает короткая проверка здравого смысла. У каждой задачи она одна: «если я её не сделаю прямо сейчас, core flow сломается?» «Нет, но было бы приятно» — это nice-to-have. Тянет проект в новую сторону — ей место в Later или в секции LATER самой спецификации.

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

3. Scope freeze: заморозка, которая ускоряет

Самая неприятная правда sprint-режима в том, что лучшие идеи действительно приходят в самый неудобный момент. После freeze правило простое: новая идея не спорит с текущим slice, а уходит в LATER. Freeze нужен не для строгости, а для скорости. Пока scope течёт, скорость не спасёт — вы быстро бежите в разные стороны.

На практике freeze выглядит довольно приземлённо. Заведите отдельный карман для идей, появившихся во время исполнения.

## ПОЗЖЕ
- мультивалютность
- импорт из двух CSV сразу
- PDF-экспорт
- рекомендации по категориям на основе ИИ

Где именно живёт список — не так важно: у кого-то это LATER.md, у кого-то раздел в SPEC.md, у кого-то просто выделенный блок в заметках. Важно другое: новая идея не исчезает и не просачивается в текущий slice.

Есть тонкий нюанс. Freeze не запрещает упрощать по ходу — наоборот, локальное упрощение нормальная часть управляемой доставки. Обязательная задача разрастается — ужимайте её до минимальной рабочей версии, которая всё ещё держит core flow. Для Personal CFO можно поддержать один CSV-формат вместо трёх. Для Landing Optimizer — только Markdown-экспорт, CSV на потом. Это не нарушение freeze. Это защита freeze.

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

4. Риск и блокер — это не синонимы

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

Удобно держать различие в очень простой таблице.

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

Ниже — короткий фрагмент заметки о состоянии спринта.

## Открытые риски
- даты могут приходить в двух форматах: `YYYY-MM-DD` и `DD/MM/YYYY`

## Текущий блокер
- нет проверочного `sample.csv` с проблемной строкой

## Следующий шаг
- добавить sample-файл и тест на разбор обеих дат

Почему здесь важен именно один шаг? Потому что многозадачность на delivery почти всегда маскирует растерянность: записали пять «следующих действий» — значит, ещё не решили, с чего начать. А sprint любит определённость.

Claude в этой точке действительно полезен — но как помощник по прояснению тумана, не как начальник проекта. Попросите его собрать открытые риски из SPEC.md и EVIDENCE_LOG.md, увидеть, какой blocker реальный, а какой просто неприятный. Приоритет за вами: только вы знаете, что критично для core flow.

5. Глубина контроля — по размеру проекта, не умнее

Контроль в sprint-режиме не должен превращать вас в менеджера атомной станции. Junior-capstone не требует трёх досок, двенадцати статусов и драматической диаграммы зависимостей. Но вариант «я всё помню» обычно кончается тем, что в памяти держится одна усталость. Глубина контроля зависит не от любви к таблицам, а от размера и риска проекта: маленькому хватит короткого контура; проекту с legacy, миграционным куском, CI, несколькими ветками и кучей файлов контур углубляется. Не умнее — глубже: чуть больше наблюдаемых осей.

Ниже — хороший практический ориентир.

То есть Junior-проекту обычно хватает пяти вещей: backlog, понимание core flow, список рисков, meaningful commits и freeze. Middle/Senior почти всегда добавляет blockers, session names, branches, checks run и remaining work — не для солидности, а потому что сложность реально выше.

Вот пример очень простого sprint board для Junior-уровня:

# Контроль спринта

- must-have: M-1, M-2, M-3
- optional: N-1, N-2
- risks: BOM в CSV, два формата дат
- commits: только по одному проверенному slice
- scope freeze: yes

Та же идея чуть глубже — для более тяжёлого проекта:

# Контроль спринта

- branch: feature/csv-parser
- session: exec-w2-parser-fix
- checks run: pytest, type-check
- blocker: sample data для второй даты
- remaining work: summary report + README quickstart

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

6. Naming — не косметика, а инструмент выживания

Sprint разваливается не только от плохого планирования — он прекрасно разваливается и от мутной истории изменений. Не можете через три дня сказать, что сделали, почему это был отдельный шаг и где смотреть последствия, — delivery уже неуправляема.

Начну с коммитов. В sprint-режиме хороший commit — это один логический, уже проверенный кусок результата. Не каждая правка. Не каждая сохранённая строка. Один завершённый мини-срез, который читается и понимается. Свалите в один коммит «чуть поправил parser, добавил export, поменял README, убрал старый код и поправил стили» — это не commit, а археологический слой.

Ниже — пример нормальной короткой истории.

feat: add CSV upload endpoint          # вход в core flow
test: cover BOM-prefixed CSV import    # фиксируем риск
fix: handle UTF-8 BOM in parser        # минимальный багфикс
docs: update quickstart with sample    # синхронизируем запуск

Здесь видно не только что менялось, но и зачем. Это особенно выручает, когда вернётесь к проекту после паузы или будете готовить walkthrough.

С ветками логика похожая. Имя ветки описывает рабочий поток, а не ваше душевное состояние. feature/csv-import, fix/utf8-bom, docs/demo-quickstart лучше, чем final-final-real, new-one, try2. Да, смешно один раз. Нет, не смешно через четыре дня.

С именами сессий в Claude — та же история. В прошлых модулях мы уже говорили: имя сессии должно отражать workstream. К середине недели открыто три безымянных сессии — и вы не помните, где какое решение принималось. Простое exec-w2-csv-parser или fix-w2-bom-regression экономит удивительно много времени.

И ещё один маленький, но важный критерий. Если сообщение коммита и имя сессии не помогают через сутки восстановить контекст — их выбрали лениво. Sprint ленивые имена не любит.

7. EVIDENCE_LOG.md как параллельный журнал спринта

Привычка вести EVIDENCE_LOG.md по ходу уже должна идти рядом со sprint-ритмом. Здесь важна ещё одна его функция: по этому файлу ревьюер восстановит логику must-have-решений — что вы сделали, чем проверили, где помог Claude, а что сознательно оставили за человеком.

Важно понимать, что EVIDENCE_LOG.md — не дубль git history. Git скажет, какие файлы менялись. EVIDENCE_LOG.md объясняет, зачем вы это делали, как проверяли и где именно помогал Claude. Это другой слой: не техническая история проекта, а история инженерных решений.

Хорошая запись туда короткая, не дневник на две страницы. Четырёх опор вполне хватает: что делали, где помог Claude, чем проверили и что осталось за человеком.

## 2026-05-24 — M-2 parse + validate

- Claude помог разрезать задачу на два шага и проверить diff на выход за scope.
- Сделано: parser принимает CSV с BOM и нормализует даты.
- Проверил: `pytest tests/test_parser.py -q`, smoke import на `sample.csv`.
- Решение человека: мультивалютность не добавлял, перенёс в `LATER`.

Эта запись занимает меньше минуты, но делает очень много полезного: видно, какой slice вы закрыли, как держали scope и чем подтверждали результат. Этого хватает, чтобы не превращать ревью в археологию.

8. Claude в sprint: помощник, но не водитель

Claude в sprint полезен не тем, что быстро генерирует код, — это лишь видимая часть. Его настоящая ценность в том, что он уменьшает туман: собирает состояние, предлагает более мелкую нарезку, смотрит на diff без авторской слепоты, объясняет failing check, обновляет заметку. То есть он отлично работает как ускоритель ясности.

Например, хороший запрос на старте рабочего отрезка выглядит так:

Прочитай `SPEC.md` и текущий `EVIDENCE_LOG.md`.
Разбей must-have M-3 на 3 минимальных шага.
Не добавляй новых фич.
Для каждого шага укажи файлы и короткую проверку.

Или так:

Посмотри текущий diff.
Ищи только выход за scope и пропущенные проверки.
Не предлагай новый функционал.
Верни максимум 3 коротких замечания.

Такие запросы очень хорошо вписываются в управляемую работу: они не отдают управление, а снимают лишнюю когнитивную нагрузку. Вы по-прежнему решаете, что брать, что отклонять и когда коммитить.

А вот что sprint переносит плохо, так это внезапное желание «усилить проект технологиями». Поставить в неделю исполнения новый plugin, завести новый hook, подключить незнакомый MCP-сервер или собрать ещё одного кастомного агента ради портфолио — это не ускорение delivery, а новая ветка сложности в самый дорогой момент. Это как менять кроссовки на ролики на середине забега: выглядит инновационно, кончается обычно плохо.

Продвинутые механизмы допустимы только при одном условии: вы уже умеете ими пользоваться, и они снимают реальную боль. Reviewer subagent для многофайлового diff — нормальный ход. Отлаженный hook на форматирование — тоже. А «давайте заодно упакуем это в plugin, чтобы выглядело командно» — нет, не сейчас.

Когда sprint прозрачен, Claude действительно ускоряет работу. Когда мутный — просто помогает вам быстрее мутить дальше. Поэтому главный вопрос не «что ещё может Claude», а «какой узкий кусок неопределённости он сейчас может убрать». Держите планку — и execution sprint перестаёт быть гонкой на выживание и становится управляемой доставкой готового core flow.

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