Сегодня поделюсь прогрессом по SpecaFlow — оркестратору разработки.

Последние две недели я занимался слоем Дизайн: как формируются требования, как принимается визуальное решение и что слой обязан оставить после себя. По ходу упёрся в проблему шире дизайна — на неё и ушло основное время.

Паспорт фазы

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

От этапа оставался только результат — документ или код. А то, как до него дошли, жило в переписке с моделью, которая быстро вытесняется ротацией. Через неделю на вопрос «почему выбрана такая схема» ответить нечем: решение принималось, обсуждалось — и исчезало.

Поэтому я сделал паспорт фазы. Каждый этап заканчивается короткой записью: что решил, каким способом, обо что споткнулся и что оставил следующему. Она хранится отдельно и живёт дольше переписки. У завершённой функции есть общий паспорт: что сделано и какие выводы она оставила.

Вернуться к функции через месяц и понять, на чём она стоит, стало делом одной страницы.

Вернёмся к Дизайну

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

И тут стало видно главное. Слой закончен, но следующий узнаёт о его результате крайне плохо.

Продукт строится слоями: инфраструктура, бэкенд, дизайн, фронтенд. Каждый стоит на предыдущем. Но передавалась между ними автоматическая сводка из первых строк описания каждой функции — сводка написанного, а не заявление о переданном.

В лабораторной песочнице я собрал точки фокуса. Всё, что нужно фронтенду от бэкенда — какие запросы есть, что возвращают, как отвечают на ошибку, что бывает при долгой операции, — описано точно, но внутри документов отдельных функций. Формально информация есть; практически её надо ещё собрать.

Слои были связаны порядком, но не содержанием.

Паспорт слоя

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

В паспорте нет отчёта о работе. Только то, что выходит за границу слоя:

— что теперь существует и из чего состоит; — что можно сделать и что для этого нужно; — как система может отказать — полный список, а не удачный путь; — что происходит мгновенно, а что занимает минуты; — что бывает пустым, а что очень большим.

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

Рядом с каждым пунктом — чем он подтверждён; нечем — помечено как обещание. Чтобы не получить простыню, в паспорт входит только видимое снаружи слоя.

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

Одно решение против удобства

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

Что это дало

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

В сумме процесс стал предсказуемее. Не быстрее — предсказуемее. Для инструмента, который ведёт разработку с ИИ, это важнее.

specaflow.com