Сложный

13 мин

135

Привет, Хабр!

В 2026 году мне кажется, что много кто стал заниматься разработкой, тот же вайбкодинг дал буста, куда ж без него - хотя в рамках этой статьи вряд ли будет что-то для начинающих, эта статья, скорее, для группы более высокого уровня. Однако, отрицать, что в software engineering стало больше людей - неверно. И мне кажется, что некоторые привычные инструменты управления разработкой устарели. Не безнадёжно, но в условиях ускорившейся доставки новых фич, целеполагание и управление на текущий момент действительно отстаёт по методологии.

В статье я хотел бы рассказать не только об одном методе, в рамках которого мы работаем внутри своих проектов и название которого, DNA, я вынес в заголовок, а о комплексном ведении задач внутри, как мы выбираем каким способом достигать целей разного размера. Но DNA, придуманный мной, - считаю его отдельным бриллиантом в короне, которая, конечно же, царапает потолок и вы это поймете далее :)

Почему мы пришли к созданию метода.

Наши проблемы начались тогда, когда я уже не мог поделить таски на персоналии без большой головоломки. Особенно это касалось работ над сложными фичами, где один человек прокопался бы очень долго, а двое уже начинали бы мешать друг другу без каких-то явных рамок, но попытки найти эти рамки знакомыми способами не вышло. Знакомая многим история, я уверен.

Ну и кроме того, не пользоваться всеми благами современных технологий в виде ИИ для ускорения работы не только в плане написания кода, но и именно менеджмента... В общем, я не мог пройти мимо.

Собственно, давайте с DNA и начнём.

А почему, собственно, DNA?

Посмотрите на схему процесса. В живой клетке две нити ДНК удерживаются вместе водородными связями. В нашей методологии две изолированные инженерные спирали (spirals) удерживаются вместе исключительно строго типизированными контрактами (connectors) в точках интеграционных узлов (nodes).

Если в Agile и его подтипах созвоны, ретро, уретро, то DNA - это в большей степени Engineering Management, где исполнители действуют как свободные художники в рамках своей спирали.

Ниже - 9 законов, которыми руководствуется метод.

• Закон 1. Ортогональное разграничение доменов (MECE): Продукт режется по вертикальным бизнес-доменам, исключая пересечение кода и совместное владение. Каждый домен жестко закреплен за своей спиралью.

• Закон 2. Сначала контракт, потом код (Contract-First): Никакой код не пишется до заморозки и версионирования контракта. Изменения вносятся строго через ADR и локальные моки.

• Закон 3. Изоляция реализации, прозрачность прогресса: Внутреннее устройство спирали на усмотрение тех, кто её реализует. Синхронизация через обновление статусов задач. Свобода, но в жёстких рамках.

• Закон 4. Циклы определяются декомпозицией контракта: Шаг итерации диктуется не календарем, а минимально интегрируемыми блоками интерфейсов. Обнаружение скрытой точки зацепления мгновенно останавливает цикл.

• Закон 5. Интеграционный узел = зеленый CI коннектора: Узел считается закрытым только при успешном прохождении контрактных и сквозных (E2E) тестов, а также полной очистке кода от временных маркеров.

• Закон 6. Три стратегии Shared Kernel: Общая инфраструктура (авторизация, UI-компоненты) создается до разделения на спирали, делегируется одному владельцу или выносится во внешний пакет.

• Закон 7. Протокол проверки перед закрытием (Pre-Close): Автоматический контроль пересечения файлов, дублирования зависимостей и соответствия контрактам. Машина сама определяет виновного в сбое без человеческого фактора.

• Закон 8. Интеграционный шлюз с триггерами ретроспектив: Анализ итерации запускается алгоритмом только при наличии аномалий (срыв сроков, переделка контракта). Если всё работает штатно — ретроспектива пропускается.

• Закон 9. Топология ветвления: Изолированная работа ведется в подветвях циклов. Слияние в защищенную ветку фичи происходит автоматически только после успешного выполнения всех проверок на интеграционном узле.

С законами метода понятно, а как с реализацией?

Делать один монструозный метод - плохая идея, не так ли? Я разделил весь DNA на дочерние методы. Не хочется растекаться мыслью по древу, поэтому ниже они будут перечислены в том порядке, в котором они работают, с пояснениями и иллюстрациями.

DNA-DISCO: Фаза сбора информации

Суть процесса: это read-only исследование. Его задача - задушить любимую забаву классического Agile: "а давайте мы щас чет-там запустим, в процессе будем решать как починить". Метод запускается один раз на планируемую к реализации фичу, строго по запросу инициатора и не имеет права трогать прод-код, создавать бранчи или плодить тикеты в Linear (или вашем таск-менеджере). Диско только собирает информацию.

Архитектурный фильтр: На этом этапе Диско вытаскивает метаданные из графа знаний проекта, ищет то, что мы называем "God Nodes" (сверхсвязанные сущности, где домены гарантированно столкнутся) и Leiden-кластеры кода, которые ложатся в основу будущих изолированных спиралей. Затем через созданные индексы кода и параллельные независимые потоки (бизнес-логика, текущие границы, зависимости, риски) формируется первичный черновик доменов.

Applicability Gate: Завершается процесс жестким бинарным фильтром. Диско проверяет: размер команды от 2 до 6 человек, выделено минимум 2 слабосвязанных домена, у каждого есть потенциальный суровый владелец, в наличии инфраструктура автоматических тестов и требования стабильны хотя бы на один цикл. Если хотя бы один пункт провален - DNA объявляется ненужным, метод выбрасывает отчет о неудаче и все возвращаются к Agile с канбаном. Если тест пройден, создаются артефакты (Dossier) для следующего шага.

DNA-SPLIT: Проектирование стыков и заморозка

Суть процесса: атомарная операция превращения Dossier в жесткий, неизменяемый план параллельного производства. Здесь инициатор фичи ставит свой финальный ОК под окончательным разделением территории по доменам. Самое важное здесь - раздел "Что находится строго за пределами домена": без этого явного перечня "не моей земли" интервенция чужой бизнес-логики неизбежна. На этом же этапе создается файл Shared Kernel - белый список общих файлов инфраструктуры, который защитит спирали от ложных срабатываний детектора пересечений при слиянии веток.

Контрактный диктат: Метод генерирует три обязательных архитектурных решения (ADR): по границам, по количеству и составу циклов $N$, и по стратегии общего ядра (Shared Kernel). Главное действие — фиксация "водородных связей" (об этой аналогии с живой природой я говорил выше). Контракт каждого узла содержит OpenAPI/Protobuf схемы, ссылки на заготовленные заглушки (mocks) и пути к контрактным тестам. Пока оба лидера спиралей не подпишут YAML своими цифровыми идентификаторами, ни один инженер не имеет права написать ни строчки кода реализации.

Развертывание инфраструктуры: Как только контракты зафиксированы, Split проводит финальную сверку границ по графу вызовов, проверяя, не забыл ли никто заложить коннекторы под скрытые связи. После этого в один клик создается защищенная ветка feat/<feature-slug> и разворачивается иерархия в Linear: один мастер-тикет, два под-тикета для спиралей и $N$ заглушек для интеграционных узлов с обязательной меткой integration-node. Если хоть один шаг автоматизации падает, скрипт полностью откатывает все изменения в Git и Linear, не оставляя мусора.

DNA-CYCLE: запуск спирали

Суть процесса: локальный метод лидера конкретной спирали для запуска изолированного витка работы под номером $N$. Никакого согласования со второй стороной здесь нет — контракт уже заморожен на предыдущем этапе. Лидер забирает свой connector-N.yaml, вытягивает из него схемы и пути к тестам, создает локальную незащищенную рабочую ветку feat/<slug>/spiral-id/cycle-N от общей ветки фичи и разворачивает заглушки партнера у себя на машине. С этого момента спираль уходит в автономное плавание.

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

Протокол мид-цикл поправок: Закон №2 запрещает молчаливую мутацию интерфейсов. Если в процессе кодинга инженер понимает, что контракт сломан или не учитывает поле, запускается протокол декомпрессии: работа останавливается, изменения вносятся в YAML-файл текущего цикла, версия контракта повышается по SemVer, а факт изменения фиксируется в contract/changelog.json. После этого оба лидера обязаны переподписать контракт заново. Если правок за цикл накапливается >2, Cycle автоматически принудительно назначит ретроспективу при закрытии и это не будет являться чистым прохождением цикла.

DNA-CLOSE: Интеграционный шлюз

Суть процесса: dna-close — это единственный момент, когда результаты работы двух спиралей технически соприкасаются. Метод вызывается автоматически, как только в Linear закрывается последний тикет, размеченный текущим циклом. Скрипт-детектор вычисляет по логам Linear конкретного инженера, который закрыл эту последнюю задачу, и назначает его ответственным за проведение закрытия узла. Если определить уникального человека не удалось (например, из-за сетевого лага системы), срабатывает жесткий машинный тайбрейк (приоритет отдается спирали А).

Автоматический протокол проверки (Закон 7): До проведения слияния веток машина запускает три безжалостных чека:

1. File Overlap Check: Проверяет диффы веток Спирали А и Спирали Б относительно базы. Если обнаружено, что кто-то залез в чужой домен и этих файлов нет в shared-kernel.txt — процесс останавливается.

2. Dependency Drift Check: Фиксирует дублирование новых библиотек. Напрямую не блочит, но выносит предупреждение.

3. Contract Conformance Check: Крутит контрактные тесты. Если упали тесты реализации контракта - виноват конкретный исполнитель. Если они зеленые, но упал сквозной интеграционный тест (E2E) - значит, сам контракт был спроектирован с ошибкой, требуется перепроектирование.

Оценка аномалий и Финал: Если технические тесты пройдены, машина требует заполнения полей честности (Heroic Integration?) в тикете интеграционного узла. Скрипт оценивает триггеры Law 8 (время витка $>10$ дней, наличие правок контракта, факты героической ручной починки кода на стыке). Если триггер сработал — создается черновик ADR ретроспективы, а следующий цикл блокируется до подписания этого документа обоими лидерами. Если аномалий нет — ретроспектива пропускается. В ветку фичи вливаются коды обеих спиралей. Если этот цикл был финальным, ветка фичи автоматически летит в main, мастер-тикет закрывается, а всё состояние фичи переносится в архив .agent/state/dna/_archived/.

Итого на этом этапе

Лейны спроектированы как замкнутый конвейер автоматизированного контроля. Роль человека сведена к двум точкам принятия решений: высокоуровневое проектирование интерфейсов на старте (dna-split) и принятие ответственности при аварийной остановке или изменении контракта в середине пути. Всё остальное время исполнители спиралей находятся в изоляции друг от друга.

Смысл, риски, стоимость внедрения

Любая попытка загнать разработку в жесткие рамки вызывает сопротивление среды. DNA - это не волшебная таблетка, а инструмент с высоким порогом ответственности.

1. Проблема "Смысловой целостности": Контракт как ТЗ

Главный скепсис, возникающий при первом знакомстве с топологией DNA: "Если спирали изолированы, не соберут ли они две идеальные системы, которые не решают бизнес-задачу?"

В DNA контроль целостности полностью смещен с процесса исполнения на процесс проектирования.

• Контракт как Single Source of Truth (SSOT): Контракт (connector-N.yaml) перестает быть просто описанием эндпоинтов. Он становится жесткой спецификацией бизнес-логики и инвариантов (через Post-conditions). Смысловой дрифт купируется до написания кода.

• Двойная спираль (Double Helix): Техническая встреча на интеграционном узле проверяет общее понимание смысла. Если одна из сторон поняла контракт иначе, Law 5 гарантирует падение сквозного интеграционного теста (E2E) при зеленых юнит-тестах.

• Архитектурный надзор: Обязательность ADR для любых изменений интерфейса заставляет участников вербализировать зачем и как меняется система, сохраняя контекст без созвонов.

Риск «Мусор на входе»: Это переносит 80% рисков на фазы dna-disco и dna-split. DNA-Agile защищает от ошибок реализации, но бессилен против ошибок видения. Если на старте допущена логическая ошибка в понимании рынка, вы идеально построите абсолютно бесполезный продукт. Вы по сути получаете «Waterfall внутри итерации» — проектировщик на этапе Split обязан обладать системным видением.

2. Протокол аварийной остановки: Когда нужны «яйца»

Что происходит, когда в середине цикла одна из спиралей понимает, что текущий контракт физически не позволяет реализовать логику ее домена? В этот момент проверяется жесткость скелета методологии. Попытки "договориться в чатике" и тихо поправить схему (Антипаттерн №2) исключены.

Владелец спирали обязан официально остановить выполнение цикла.

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

• Отсутствие "скрытого созвона": Остановка не превращается в митинг "что я делал вчера". Это строго регламентированная сессия перепроектирования между владельцами затронутых спиралей. Обсуждается только один вопрос: почему контракт несовместим с реальностью. Результат - новый коммит в contract/, обновленный DOMAINS.md и подписанный ADR.

Риск «Эффекта Домино»: При слабой первичной декомпозиции стопы будут происходить каждые два дня, превращая разработку в непрерывный архитектурный астронавтизм. Более того, в маленьких командах (2-6 человек) "владелец спирали", регулярно дергающий стоп-кран, неизбежно генерирует психологическое давление. Возникает огромный соблазн скатиться в Антипаттерн №4 (Heroic Patching) — начать подкручивать код втихую, чтобы не признавать ошибку проектирования.

3. Сводная матрица критических рисков

Вывод и Экономика внедрения

Это метод для среды, где люди рассматриваются как высококачественные специалисты, а не социальные элементы в смысле "эгегей, команда!". Ответственность размыта не на абстрактную "команду", а зафиксирована в коде: если твой коммит пересек границу чужого домена или сломал контракт - ты виноват и метод (главный или дочерний) это зафиксирует.

Это не замена Scrum для всех подряд. Это альтернатива для команд, где уровень инженерной зрелости уже позволяет заменить часть процессных ритуалов контрактами, CI-проверками и явной архитектурной ответственностью. Вы меняете внутреннюю элегантность кода на этапе быстрой доставки (Black Box реализации) на внешнюю скорость и железобетонную жесткость стыковки на интеграционных узлах.

Результаты внутреннего внедрения

Контекст внедрения

• Команда: 3 инженера + 1 Tech Lead.

• Проект: Платформа дистрибуции оборудования и анализа потребностей заказчиков

• Период: 3 месяца (апрель-июнь 2026).

• Нагрузка: Через DNA прогнано 7 сложных эпиков (от 2 до 4 изолированных бизнес-доменов в каждом).

Метрики

Это не академический benchmark и не статистически значимое исследование. Это внутренние operational metrics одной команды за 3 месяца. Их задача - показать направление, а не доказать универсальную эффективность метода.

Вместо Agile-попугаев мы замеряли три параметра: скорость доставки ценности (Time-to-Market), качество стыковки и предсказуемость релизов. Результаты трёх месяцев эксплуатации протокола сведены в таблицу ниже:

Качественные изменения среды

Помимо сухих цифр, за полгода изменилась сама ДНК (да простят читатели за такой финт) взаимодействия внутри команды:

1. Стали разговаривать на другом уровне: Из лексикона полностью исчез вопрос "А что мне делать дальше?". Теперь у нас: "Где мой Connector-yaml? Дайте контракт!".

2. Мерж стал более управляемым и морально легче: Закон №7 (Pre-Close Validation) убрал синдром тревожности перед мёрджем.

3. Ретро по делу: За 3 месяца обязательная психотерапия на созвонах сменилась триггерами Law 8. Ретро собиралась всего трижды - только когда метод фиксировал аномалии. Если цикл прошел штатно, то команда молча и радостно идет дальше, экономя время.

4. ADR как воздух: Документирование решений в формате decisions/NNN-*.md стало рефлексом. Любой коммит, меняющий логику стыковки, теперь прозрачен и имеет автора, что исключает появление неопознанного кода.

Где метод пасует (честно о минусах)

DNA - метод не для всего. За время использования мы нащупали его границы:

• Апфронт-оверхед (Upfront investment): Фазы dna-disco и dna-split требуют минимум 1 рабочий день лида и архитекторов на глубокий анализ графа вызовов и проектирование интерфейсов. Если фича мелкая, тратить время на DNA - бессмысленно. Метод не подходит для потоковой обработки мелких багов.

• Кривая обучения (Learning curve): Команде, привыкшей к расслабленному Scrum, требуется пройти через 2-3 болезненных цикла, чтобы научиться сначала проектировать, а потом кодить. На первых порах у инженеров без системного мышления возникает ментальный ступор при необходимости жестко версионировать контракты до реализации.

• Инфраструктурный налог (Tooling dependency): Метод физически не работает без жесткой обвязки автоматизации. Если у вас нет времени или квалификации написать CI-скрипты для контрактных тестов, детекции аномалий и автоматического контроля пересечения файлов - DNA мгновенно деградирует в оверкилл-Kanban.

Финальный вердикт

Было непросто придумать, сложнее переучить коллег, но когда мы распробовали... Ух. Да, метод требует очень высокой доли ответственности на этапе его запуска при работе над фичей какой-то. И ещё метод требует очень большого количества инструментов при подготовке этого запуска. У нас внутри эти инструменты есть и нам в целом проще.

Главный инсайт: перестаньте планировать задачи. Начните планировать интерфейсы, где задачи встретятся.

Если вы узнали свою ситуацию - попробуйте. Если нет - возможно, вам пока не нужен DNA, и это нормально.

В первую очередь, я поделился DNA для тех, кто уже действительно понимает бенефиты отчасти автоматизированной разработки и хочет перейти на более высокий уровень управления и достижения новых целей для своих проектов. Ознакомиться со всеми документами по методу вы сможете здесь.

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

Спасибо за внимание.