
Комментарии 4
Спасибо за статью!
Подскажите, пожалуйста, какие артефакты передаются от аналитика к разработке? То есть что является результатом работы аналитика помимо текста ТЗ и в каком формате?
У нас сейчас так:
Use cases в виде sequence diagrams ( в нотации mermaid)
Данные - json-schemas
Rest - openapi
Асинхронные интерфесы - asyncapi
dbus - придуманные нами таблицы с описанием интерфейсов
Спасибо за вопрос!
На самом деле всё сильно зависит от конкретной задачи. Где-то основной акцент на бизнес-процессах, где-то на логике бэкенда, интеграциях, фронтенде или изменениях в БД. Поэтому и набор артефактов в постановке может заметно отличаться. Из того, что вы перечислили, мы тоже используем. Помимо этого, в наших постановках встречаются следующие артефакты:
- риски и ограничения, чтобы команда заранее понимала возможные сложности;
- BPMN-схемы, если задача затрагивает бизнес-процесс;
- PlantUML Sequence Diagram (код и сама схема), макеты из Figma, примеры JSON/XML/XSD, ER-диаграммы при изменениях БД;
диаграммы состояний (State Machine), если необходимо описать жизненный цикл сущности;
- C4-диаграммы (Context/Container) встречались, но достаточно редко, обычно для верхнеуровневого описания архитектуры;
- таблицы маппинга данных между системами, ошибок с кодами, условиями возникновения и рекомендациями по обработке;
Универсального набора артефактов, на мой взгляд, не существует. Всё определяется задачей и тем, какая информация нужна команде, чтобы реализовать функциональность.
Спасибо, ценный опыт!
Мы тоже используем как артефакт ТЗ макеты в figma
Как middle-документацию (не входит в ТЗ, но из ТЗ есть ссылка)
С4 - только верхние 2 уровня. третий уровень пытались, но он постоянно отстает от реальности и ценность его сомнительна (именно в процессе разработке). как ретроспективное описание - вполне можно
Как внутреннюю документацию разработчика (не входит в ТЗ, но из ТЗ есть ссылка)
ER
Пробовали, но пока отложили
BPMN
От хаоса к системе: как мы выстроили процесс Discovery (часть 2)