Материал: Часть 12. MVP

Урок 1 из 5 в модуле «Часть 12. MVP»

Вы просматриваете урок без входа. Войдите, чтобы сохранять прогресс и проходить тесты.

Источник

Часть 12. MVP

MVP-фаза отличается от обычной фазы фичи. Здесь вы просите агента реализовать не один маленький кусок, а оставшуюся часть минимально жизнеспособного продукта. Это рискованно. Делать так стоит только если проектные правила, спецификации, тесты и проверка уже достаточно зрелые.

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

Когда можно пробовать MVP

Подходящий момент:

как минимум две фичи уже прошли полный цикл;
mission.md, tech-stack.md, roadmap.md актуальны;
есть политика тестирования;
есть журнал изменений;
вы готовы проверять большой объём изменений;
дорожная карта содержит чёткие границы MVP.

Неподходящий момент:

первая же фаза проекта;
нет тестов;
дорожная карта расплывчата;
агент уже часто нарушает границы;
вы не можете выделить время на проверку.

MVP-запрос для Qwen Code

/clear
Прочитай @QWEN.md, @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
и все существующие спецификации фич в @specs/.

Мы рассматриваем MVP-ветку.
Пока ничего не реализуй.

Сначала:
1. найди минимальный набор оставшихся пунктов дорожной карты, нужных для MVP;
2. перечисли риски их совместной реализации;
3. задай мне три группы вопросов о границах MVP, решениях и проверке.

После ответов:

Создай specs/YYYY-MM-DD-mvp/requirements.md, plan.md и validation.md.
План должен быть разбит на группы, чтобы я мог просить реализовать его по частям.
Код реализации пока не пиши.

Пример границ MVP

# Требования — MVP

## Границы

MVP должен сделать AgentClinic цельной небольшой демонстрацией:
- главная страница;
- агенты и недуги;
- терапии;
- форма запроса на приём;
- сводка панели управления;
- адаптивные стили;
- тесты критичных маршрутов.

## За границами

- Аутентификация.
- Оплата.
- Отправка писем.
- Интерфейс администрирования для редактирования.
- Внешнее развёртывание.

## Решения

- Использовать таблицы SQLite и начальные данные.
- Отправленные формы сохранять локально.
- Всё рендерить на сервере.
- Использовать существующий макет и CSS-соглашения.

Проверка MVP

Для MVP проверка должна быть жёстче, чем для маленькой фичи:

## Автоматические проверки

- npm run typecheck проходит успешно.
- npm test проходит успешно.
- Тесты маршрутов покрывают /, /agents, /ailments, /therapies и /appointments.
- Тесты базы данных покрывают миграции и начальные данные.

## Ручные проверки

- В свежем клоне можно запустить npm install, npm run seed и npm run dev.
- Основная навигация ведёт на все страницы MVP.
- Форма записи обрабатывает корректный и некорректный ввод.
- На мобильной ширине 375px макет не ломается.
- Журнал изменений описывает MVP-ветку.

## Проверка отклонений

- Аутентификация не добавлена.
- Клиентский фреймворк не добавлен.
- Внешние сервисы не требуются.

Реализация MVP по группам

Даже если спецификация MVP одна, реализацию не обязательно делать одной командой.

Реализуй только группу 1 из @specs/2026-05-05-mvp/plan.md.
Запусти нужные проверки.
Остановись и перечисли изменённые файлы.

Потом:

Реализуй группу 2.
Не редактируй файлы из группы 1, если этого не требует проверка.

Так вы сохраняете контрольные точки, которые удобно проверять.

Когда остановиться: таймбоксинг и откат к последней зелёной точке

MVP-ветка склонна разрастаться. Агент реализует группу 1, потом группу 2, потом начинает «по ходу» поправлять группу 1 под группу 3 — и через час непонятно, в каком состоянии репозиторий.

Заранее зафиксируйте две вещи: бюджет времени и точку отката.

Бюджет времени. Договоритесь с собой (или с командой) о таймбоксе на сессию. Для учебного MVP это 2–4 часа. Когда таймбокс истёк, не «ещё одна группа» — остановка, оценка, решение.

Точка отката. Перед каждой группой задач делайте коммит, даже если он промежуточный. После коммита запускайте npm run typecheck и фиксируйте, что эта точка зелёная:

git commit -m "MVP group 1: agents page"
npm run typecheck
git tag mvp-green-1

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

git reset --hard mvp-green-1

Это не поражение. Это сигнал, что спецификация MVP была недостаточно детальной для конкретной группы — её надо доуточнить отдельной малой фичей вместо того, чтобы добивать в MVP-ветке.

Признаки, что пора остановиться раньше таймбокса:

агент два раза подряд возвращается к одной и той же группе и не закрывает её;

git diff --stat показывает изменения в файлах, которых нет ни в одной группе плана;
после очередной реализации перестают проходить тесты, которые проходили до неё;
агент начинает спрашивать «можно я заодно…» — это значит, граница MVP стала ему мешать, и спецификации надо поправить, а не границу подвинуть.

После MVP спросите о пробелах в спецификации

Один из лучших вопросов:

По реализации MVP скажи, что тебе пришлось вывести самому, потому что это не было явно задано.
Перечисли пробелы в спецификациях и предложи обновления для mission, tech-stack, roadmap или спецификации MVP.
Файлы не изменяй.

Если агент честно отвечает «я сам решил X», это подарок. Запишите X в спецификации, если решение важно.