✅ Документация фазы задач
Фаза задач является финальной фазой процесса разработки на основе спецификаций, преобразуя одобренный дизайн в структурированный план реализации, состоящий из дискретных, выполнимых задач разработки. Эта фаза служит мостом между планированием и выполнением, разбивая сложные системные дизайны на управляемые шаги, которые могут выполняться инкрементально командами разработки или ИИ-агентами.
Как третья фаза в рабочем процессе Требования → Дизайн → Задачи, фаза задач обеспечивает, чтобы вся тщательная работа по планированию и дизайну переводилась в систематический, отслеживаемый прогресс реализации.
Цель и задачи
Фаза задач служит для:
- Преобразования компонентов дизайна в конкретные активности разработки
- Последовательности задач для оптимального потока разработки и ранней валидации
- Создания четких, выполнимых промптов для реализации
- Установления зависимостей и порядка сборки между задачами
- Обеспечения инкрементального прогресса с тестируемыми вехами
- Предоставления дорожной карты для систематической разработки функций
Пошаговый процесс
Шаг 1: Анализ дизайна и идентификация задач
Цель: Разбить дизайн на реализуемые компоненты
Принципы формирования списка задач:
- Обзор компонентов дизайна: Выявить все системные компоненты, которые нужно построить или изменить
- Отображение на артефакты кода: Определить, какие файлы, классы и функции нужно создать или изменить
- Учет требований тестирования: Планировать создание тестов вместе с реализацией
- Последовательность для ранней валидации: Упорядочить задачи для быстрой валидации основной функциональности
- Ссылка на требования: Оставлять ссылку на конкретные требования, которые реализуются, обеспечивая связь между задачей и пользовательской ценностью
Принципы создания задач:
- Фокусироваться на конкретных активностях (написание, модификация, тестирование кода)
- Каждая задача должна производить рабочий, тестируемый код
- Задачи должны строиться инкрементально на базе предыдущих работ
Шаг 2: Структурирование и иерархия задач
Цель: Декомпозировать задачи на подзадачи
Принципы организации задач:
- Максимум два уровня: Использовать только задачи верхнего уровня и подзадачи (избегать вложенности)
- Логическая группировка: Группировать связанные задачи под осмысленными категориями
- Последовательные зависимости: Упорядочивать задачи так, чтобы каждая строилась на предыдущей работе
- Тестируемые инкременты: Каждая задача должна приводить к тестируемой функциональности
Определение последовательности выполнения задач:
- Основное сначала: Строить основную функциональность перед опциональными функциями
- Риск сначала: Решать неопределенные или сложные задачи рано
- Ценность сначала: Реализовывать высокоценные функции, которые можно быстро протестировать
- Ориентированная на зависимости: Уважать технические зависимости между компонентами
- Основа сначала: Основные интерфейсы и модели данных перед зависимыми компонентами
- Подход снизу вверх: Утилиты нижнего уровня перед функциями верхнего уровня
- Последовательность, основанная на тестах: Тесты вместе с реализацией или перед ней
- Точки интеграции: Планировать подключение компонентов по мере их построения
Шаблон иерархии задач:
## Задача
[Детали задачи, ссылки на требования и дизайн]
- [ ] 1.1 [Подзадача реализации]
- [Детали подзадачи, ссылки на требования и дизайн]
- [ ] 1.2 [Следующая конкретная задача]
- [Детали подзадачи, ссылки на требования и дизайн]
## Следующая задача
- [Детали задачи, ссылки на требования и дизайн]
- [ ] 2.1 [Подзадача реализации]
- [Детали подзадачи, ссылки на требования и дизайн]
Шаг 3: Определение и спецификация задач
Цель: Обогатить детали подзадачи информацией:
- Четкая цель: Какой конкретный код нужно написать или модифицировать
- Детали реализации: Конкретные файлы, компоненты или функции для создания
- Прослеживаемость требований: Ссылка на конкретные требования, которые реализуются
- Прослеживаемость дизайна: Ссылка на дизайн, который реализуется
- Критерии приемки: Как узнать, что задача завершена
- Ожидания тестирования: Какие тесты должны быть написаны или обновлены
Шаг 4: Валидация и уточнение
Критерии качества задач:
- Выполнимые: Могут быть выполнены без дополнительных уточнений
- Конкретные: Четкие о том, какие файлы, функции или компоненты создавать
- Тестируемые: Приводят к коду, который можно тестировать и валидировать
- Инкрементальные: Строятся на предыдущих задачах без больших скачков сложности
- Полные: Покрывают все аспекты дизайна, которые требуют реализации
Вопросы валидации:
- Может ли разработчик начать разработку из этого описания задачи?
- Производит ли эта задача рабочий, тестируемый код?
- Четко ли выявлены требования, которые реализуются?
- Строится ли эта задача логично на предыдущих задачах?
- Подходящий ли объем задачи (не слишком большой, не слишком маленький)?
Чек-лист качества
Перед финализацией списка задач проверить:
Полнота:
- Все компоненты дизайна покрыты задачами реализации
- Все требования адресованы одной или несколькими задачами
- Задачи тестирования включены для всей основной функциональности
- Задачи интеграции соединяют все компоненты
Ясность:
- Каждая задача имеет четкую, конкретную цель
- Описания задач указывают, какие файлы/компоненты создавать
- Ссылки на требования включены для каждой задачи
- Критерии завершения неявные или явные
Последовательность:
- Задачи упорядочены для уважения зависимостей
- Ранние задачи устанавливают основу для последующей работы
- Основная функциональность реализуется перед опциональными функциями
- Задачи интеграции идут после реализации компонентов
Реализуемость:
- Каждая задача подходящего размера для реализации
- Нет задач, требующих внешних зависимостей или ручных процессов
- Сложность задач увеличивается постепенно
Устранение проблем планирования задач
Проблема: Задачи слишком расплывчатые
Симптомы: Разработчики не могут начать разработку из описаний задач Решение: Добавить более конкретные детали реализации, имена файлов/компонентов
Проблема: Зависимости задач неясны
Симптомы: Задачи не могут быть завершены, потому что предварительные условия отсутствуют Решение: Обозреть последовательность задач и добавить отсутствующие задачи основы
Проблема: Не ясна связь Задачи с Требованиями
Симптомы: Сложность прослеживания задач обратно к пользовательской ценности Решение: Добавить ссылки на требования и валидировать покрытие
Шаблон документа
# Задачи "[Краткое название функциональности]"
## [Название задачи]
[Детали задачи, ссылки на требования и дизайн]
- [ ] 1.1 [Подзадача реализации]
- [Детали подзадачи, ссылки на требования и дизайн]
- [ ] 1.2 [Следующая конкретная задача]
- [Детали подзадачи, ссылки на требования и дизайн]
## [Название следующей задачи]
- [Детали задачи, ссылки на требования и дизайн]
- [ ] 2.1 [Подзадача реализации]
- [Детали подзадачи, ссылки на требования и дизайн]
## Чек-лист качества списка задач
*(Заполняется перед финализацией списка задач)*
| Критерий | Выполнено | Комментарий |
| ------------------------------------------------------------------------ | --------- | ----------- |
| Все компоненты дизайна покрыты задачами реализации | ☐ | |
| Все требования адресованы одной или несколькими задачами | ☐ | |
| Задачи тестирования включены для всей основной функциональности | ☐ | |
| Задачи интеграции соединяют все компоненты | ☐ | |
| Каждая задача имеет четкую, конкретную цель | ☐ | |
| Описания задач указывают, какие файлы/компоненты создавать | ☐ | |
| Ссылки на требования включены для каждой задачи | ☐ | |
| Для каждой задачи определены критерии завершения | ☐ | |
| Задачи упорядочены с учетом зависимостей | ☐ | |
| Ранние задачи устанавливают основу для последующей работы | ☐ | |
| Основная функциональность реализуется перед опциональными функциями | ☐ | |
| Задачи интеграции следуют после реализации компонентов | ☐ | |
| Каждая задача имеет подходящий размер для реализации | ☐ | |
| Отсутствуют задачи с внешними зависимостями или ручными процессами | ☐ | |
| Сложность задач возрастает постепенно | ☐ | |