MADTeacher Задачи из спецификации
Разбей план, спецификацию или PRD на независимые задачи для реализации, используя подход вертикальных срезов.
Вертикальный срез — это тонкий, но законченный путь через все необходимые уровни системы: данные, бизнес-логику, API, интерфейс, тесты, интеграции и наблюдаемое поведение.
Не разбивай работу горизонтально по слоям вроде:
- отдельно схема данных;
- отдельно API;
- отдельно UI;
- отдельно тесты.
Каждая задача должна давать самостоятельный, проверяемый и по возможности демонстрируемый результат.
Процесс
1. Собери контекст
Используй все, что уже есть в текущем контекстном окне:
- план;
- PRD;
- спецификацию;
- описание функции;
- описание бага;
- пользовательские истории;
- уже принятые решения;
- ограничения;
- технический контекст;
- обсужденные зависимости;
- открытые вопросы.
Не начинай с повторного интервью, если в текущем контексте уже достаточно информации для первичной декомпозиции.
Если пользователь передал внешний документ, текст задачи или ссылку на доступный источник, используй его как исходный материал.
2. Изучи кодовую базу, если это полезно
Если кодовая база, документация, тесты или другие материалы доступны, изучи их, чтобы понять текущее состояние системы.
Особенно проверь:
- какие модули уже существуют;
- какие точки расширения можно использовать;
- какие похожие сценарии уже реализованы;
- какие тестовые подходы уже применяются;
- где проходят границы компонентов;
- какие зависимости могут повлиять на порядок задач.
Не спрашивай пользователя о том, что можно надежно выяснить из доступных материалов.
3. Сформируй вертикальные срезы
Разбей работу на задачи-трассеры.
Каждая задача должна быть узкой, но завершенной. Она должна проходить через все необходимые уровни реализации и давать наблюдаемое поведение.
Задачи могут быть двух типов:
- AFK — задача может быть реализована автономно без участия пользователя;
- HITL — для задачи требуется участие человека: продуктовая развилка, архитектурное решение, дизайн-ревью, подтверждение контракта, согласование поведения или другой ручной выбор.
По возможности предпочитай AFK-задачи. Отмечай задачу как HITL только тогда, когда без человеческого решения действительно нельзя безопасно двигаться дальше.
4. Покажи черновую декомпозицию пользователю
Сначала представь предлагаемую разбивку в виде нумерованного списка.
Для каждого среза покажи:
- Название: короткое и описательное;
- Тип: HITL или AFK;
- Заблокировано: какие задачи должны быть выполнены раньше, если такие есть;
- Покрываемые пользовательские истории: если они есть в исходном материале;
- Проверяемый результат: что можно будет увидеть, проверить или принять после выполнения задачи.
После списка задай пользователю вопросы:
- Подходит ли уровень детализации: задачи не слишком крупные и не слишком мелкие?
- Правильно ли определены зависимости?
- Нужно ли какие-то задачи объединить?
- Нужно ли какие-то задачи разделить?
- Правильно ли отмечены задачи HITL и AFK?
- Не пропущены ли важные пользовательские сценарии, крайние случаи или технические ограничения?
Итерируй декомпозицию, пока пользователь не подтвердит, что структура задач подходит.
5. Сформируй финальный набор задач
После утверждения декомпозиции сформируй задачи в порядке зависимостей: сначала блокирующие задачи, затем зависящие от них.
Используя шаблон ниже запиши в markdown-файлы каждую задачу и сохрани в директории docs/tasks в корневой директории проекта.
Если у задач еще нет внешних идентификаторов, ссылайся на них по номерам из текущей декомпозиции.
Родительская задача
Укажи исходный план, PRD, спецификацию, функцию или баг, из которого получена задача.
Если явная родительская задача отсутствует, то этот раздел можно опустить.
Что нужно реализовать
Кратко опиши вертикальный срез.
Описывай end-to-end поведение, а не послойную реализацию.
Плохо:
Добавить таблицу, затем endpoint, затем экран.
Хорошо:
Пользователь может создать черновик сущности, увидеть его в списке и открыть карточку с сохраненными данными.
Пользовательский или системный результат
Опиши, какой наблюдаемый результат появится после выполнения задачи.
Результат должен быть проверяемым независимо от других задач, насколько это возможно.
Критерии приемки
- Критерий 1
- Критерий 2
- Критерий 3
Критерии должны описывать наблюдаемое поведение системы, а не внутренние детали реализации.
Зависимости
Укажи, какие задачи должны быть выполнены раньше.
Если зависимостей нет, напиши:
- Нет — можно начинать сразу.
Тип задачи
AFK или HITL.
Если задача HITL, явно укажи, какое человеческое решение или подтверждение требуется.
Заметки по реализации
Добавь только те технические заметки, которые помогают выполнить задачу.
Не включай конкретные пути к файлам и фрагменты кода, если они могут быстро устареть.
Заметки по тестированию
Опиши, что нужно проверить.
Включи:
- какие сценарии покрыть тестами;
- какие внешние поведения проверить;
- какие регрессии предотвратить;
- какие похожие тестовые подходы уже есть в проекте, если это известно.