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 — один пілотний перехід плюс валідований результат, а не «оновити весь світ до останньої версії». Для 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 самої специфікації.

Тут є ще один важливий психологічний момент. Парковка ідей — не звалище забутих думок, а спосіб поважати хорошу ідею, не руйнуючи поточну доставку. Ви її не викидаєте — чесно кажете: «не зараз». Для 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: додати CSV upload endpoint          # вхід у core flow
test: покрити BOM-prefixed CSV import    # фіксуємо ризик
fix: обробити UTF-8 BOM у parser         # мінімальний багфікс
docs: оновити quickstart із 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 і щоденний контроль уже видно, спливає наступне неприємне запитання: цього взагалі достатньо для показу чи ми просто ще раз сказали собі «ну майже готово».