Проведи проект через GSD: от требований до верификации

Навигация по видео

1. 00:00Почему одного написания кода недостаточно▶
2. 01:50Этапы SDLC и роль человека▶
3. 07:39Потеря контекста в длинных проектах▶
4. 09:06GSD и Superpowers: два способа организовать работу▶
5. 11:57Поток GSD: от проекта до верификации▶
6. 30:00Артефакты, фазы и волны выполнения▶
7. 42:16Код-ревью, верификация и ручная приёмка▶
8. 49:00Новая сессия читает сохранённый контекст▶
9. 1:01:55Реальный запуск, ошибки интеграции и быстрые исправления▶
10. 1:21:23Когда GSD оправдан, а когда процесс слишком тяжёлый▶
11. 1:23:08Superpowers: навыки для короткого workflow▶
12. 1:33:17От спецификации к плану реализации▶
13. 1:39:39Делегирование, тесты и код-ревью▶
14. 1:47:07Проверка приложения и выводы▶
15. 1:59:23Как выбрать процесс под масштаб задачи▶

Выбери главу: видео выше начнётся с нужного момента.

Сначала зафиксируй контекст, потом проси писать код

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

Карта проекта перед первой фазой

• Названы пользователь, его задача и наблюдаемый итог сценария.
• Записаны обязательные требования, ограничения и то, что сознательно не входит в первый релиз.
• Есть дорожная карта с фазами; у каждой фазы один результат, который можно проверить.
• Для каждой фазы указаны зависимости, риски и способ ручной приёмки.
• Определено, какие действия агент может выполнить сам, а какие требуют явного решения человека.

Бриф для обсуждения проекта с агентом

Пользователь и его задача: [кто и какой сценарий проходит]
Результат первой версии: [что пользователь сможет сделать]
Обязательные требования: [список]
За пределами текущей версии: [список]
Технические и бизнес-ограничения: [данные, интеграции, сроки, бюджет]
Риски и неизвестные: [список]
Фаза 1: [результат, границы, критерии приёмки]
Что агент может делать сам: [разрешённая область]
Что требует моего подтверждения: [деплой, доступы, расходы, внешние действия]
Как проверим фазу вручную: [сценарий и ожидаемый результат]

Строй фазы как проверяемые обещания

План фазы — не перечень технологий и не обещание «сделать экран». Сформулируй результат в поведении: например, пользователь создаёт запись, видит её после обновления страницы и получает понятную ошибку при неверных данных. Раздели независимые части на волны только там, где у них нет конфликтующих изменений. После каждой волны проверь результат, зафиксируй принятое решение и только затем переходи дальше.

Проверяй фазу до следующего шага

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

Используй быстрые исправления по их настоящему масштабу

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

Выбирай GSD и Superpowers по сложности, а не по названию

Для проекта с несколькими зависимыми этапами и долгим контекстом полезны подробная дорожная карта и артефакты GSD. Для ограниченной задачи удобнее компактный цикл Superpowers: уточнить идею, сохранить спецификацию, составить план, реализовать, проверить и завершить работу. Репозиторий GSD сейчас архивирован, поэтому перед установкой и использованием проверь актуальный способ поддержки выбранного workflow.