Что остается после спринта разработки
Это не пустой файл и не универсальный шаблон. Состав уточняется под задачу, но базовая структура передачи остается предсказуемой.
Один результат, две точки зрения
Разработчику нужны воспроизводимая сборка и код. Владельцу продукта нужны критерии, ограничения, риски и понятный следующий маршрут.
проект/
├─ ОПИСАНИЕ.md
├─ ИЗМЕНЕНИЯ.md
├─ исходники/
├─ тесты/
├─ настройки/
├─ скрипты/
├─ документы/
│ ├─ 01_объем-и-приемка.md
│ ├─ 02_архитектура.md
│ ├─ 03_запуск-и-развертывание.md
│ ├─ 04_результаты-проверки.md
│ ├─ 05_риски-и-технический-долг.md
│ └─ 06_тз-следующего-этапа.md
└─ примеры/
└─ безопасные-тестовые-данные/- 01
Работающая демонстрационная сборка
Критический сценарий можно запустить и проверить в согласованной среде.
- 02
Репозиторий исходного кода
Структурированный код без привязки результата к одному компьютеру разработчика.
- 03
Инструкция запуска и развертывания
Зафиксированы зависимости, конфигурация и порядок получения рабочей версии.
- 04
Схема архитектуры и интеграций
Понятно, как связаны компоненты, устройства, сервисы и потоки данных.
- 05
Требования и критерии приемки
Обязательный результат отделен от идей, которые можно перенести на следующий этап.
- 06
Реестр рисков и технического долга
Временные решения, ограничения и неизвестные не прячутся внутри кода.
- 07
Результаты проверки критического сценария
Зафиксировано, что проверялось, в каких условиях и с каким результатом.
- 08
Актуализированное ТЗ и план задач
Следующий этап опирается на факты прототипирования, а не на исходные догадки.
- 09
Оценка следующего этапа
Понятны возможный объем, профиль команды и архитектурные развилки.
- 10
Сессия передачи
Внутренняя команда или следующий подрядчик получает контекст и отвечает на вопросы.
Точный перечень материалов, права на код и формат передачи фиксируются в договоре и в согласованном объеме конкретного этапа.