Заголовок намеренно провокационный, но практический вывод — более узкий и прикладной. Agile не умирает, потому что итеративная поставка, кросс-функциональное взаимодействие и петли обратной связи перестали иметь значение. Jira и Confluence не умирают, потому что учёт задач и документация внезапно стали не нужны.
Умирает допущение, что именно эти инструменты являются естественной средой, в которой должна жить работа по доставке ПО. В агентной SDLC они всё чаще оказываются неправильным центром тяжести.
Jira и Confluence остаются полезными системами записи. Они остаются удобными управленческими представлениями. В них по-прежнему можно публиковать планы, согласования, рабочие элементы, сводки и аудиторские следы. Но они становятся всё слабее как первичный субстрат, в котором работа определяется, интерпретируется, исполняется, управляется и развивается смесью людей и программных агентов.
Когда ИИ-агенты начинают участвовать в продуктовом проектировании, дизайне, разработке, тестировании, ревью, релизах, поддержке и операционном управлении, качество подлежащего слоя знаний становится важнее качества тикет-интерфейса. Поэтому для компаний, которые уже планируют внедрение ИИ-агентов и n8n воркфлоу, принципиален не выбор таск-трекера, а архитектура источника истины.
Большинство организаций всё ещё пытаются запустить AI-native модель доставки поверх документационного и таск-стека, спроектированного для ручного просмотра, ручных обновлений и фрагментированной интерпретации.
Настоящая проблема не в Jira и Confluence
Jira и Confluence — не плохие продукты. Во многих компаниях они глубоко полезны. Проблема архитектурная.
Они в основном оптимизированы как workflow-приложения и порталы совместной работы, а не как долговечный, компонуемый и машиночитаемый субстрат исполнения. Это различие звучит абстрактно, но меняет всё.
В традиционной модели, где работают только люди, фрагментированный стек — это больно, но терпимо. Продуктовый менеджер читает бриф в Confluence, создаёт эпики в Jira, инженеры додумывают технические последствия, архитекторы консультируются с другой вики, безопасность смотрит в библиотеку контролей где-то ещё, а эксплуатация в итоге собирает картину рантайм-влияния по кускам. Значительная часть интеграции происходит в головах людей, на встречах, в переписках и институциональной памяти.
Этот процесс всегда был с потерями. Просто потери скрывались за героической работой людей по переупаковке контекста. В агентной среде потери становятся гораздо заметнее.
Агент не может надёжно работать на основе корпоративных ощущений. Ему нужен явный контекст, прослеживаемая структура, стабильные идентификаторы, проверяемые изменения, метаданные владения, привязка политик и доступ к каноническим исходным материалам в формате, который можно предсказуемо парсить и трансформировать.
Именно поэтому центр доставки должен смещаться от SaaS-страниц и тикетов как канонического субстрата — в сторону Git-центричного, markdown-ориентированного и машиночитаемого слоя знаний.
Agile-ритуалы всегда были прокси для координации
Одна из причин, почему заголовок вызывает сопротивление, — квазирелигиозный статус Agile в корпоративном ПО. Но важно отделить ценности от вендорских операционных ритуалов, которые вокруг них выросли.
Спринт-доска — это не agility. Бэклог — это не обучение. Стендап — это не координация. Страница в Confluence — это не общее понимание.
Это интерфейсные соглашения для управления неопределённостью и синхронизации работы в мире, где исходные артефакты были слишком слабыми, разрозненными или двусмысленными, чтобы координироваться сами по себе.
Как только продуктовое намерение, архитектурные ограничения, политики, сервисный контекст, ожидания по тестам, правила релиза и операционные контроли становятся более структурированными и исполняемыми, многие из этих ритуалов перестают быть главным механизмом выравнивания.
Они становятся проекциями. В этом и есть глубинный сдвиг. Центр тяжести перемещается от церемонии к субстрату.
Системы записи — это не системы исполнения
Здесь полезен известный программный паттерн. Мартин Фаулер описывает CQRS как разделение моделей для обновления информации и моделей для чтения информации. Он предупреждает, что паттерн добавляет сложность при неаккуратном применении, но базовое различие здесь крайне полезно.
Jira и Confluence всё чаще имеют смысл как read-side и management-side системы. Они хороши для отображения статуса работы, публикации документации, сбора согласований, предоставления управленческих представлений и операционных сводок. Иными словами, это хорошие query-поверхности.
Но command-сторона агентной доставки — это нечто другое.
Command-сторона — это место, где формулируется намерение, объявляются ограничения, привязываются политики, изменяется код, описываются тесты, обновляются знания, запускаются контроли и автоматизация решает, что делать дальше.
Этой стороне нужны такие свойства:
- версионный контроль;
- диффы и ветвление;
- ревью через pull request;
- машиночитаемость и компонуемость;
- валидация в CI;
- стабильные пути и идентификаторы;
- оценка политик;
- хуки автоматизации;
- локальная и удалённая программируемость.
Git и plain-text структурированные артефакты дают эти свойства гораздо естественнее, чем тикеты и вики-страницы. Это не означает, что Jira и Confluence исчезают. Это означает, что они перестают притворяться главным исполнительным субстратом.
Единый субстрат знаний как новый центр
На смену текущему хаосу приходит не ещё один портал, а единый субстрат знаний, построенный на нескольких долговечных идеях:
- markdown для нарративного контента;
- YAML или близкие структурированные определения для машиночитаемых метаданных;
- Git для версионирования, ревью, ветвления и триггеров автоматизации;
- конвенции структуры репозитория для discoverability;
- CI-валидация для полноты, свежести и соответствия политикам;
- генерируемые представления для множества аудиторий, потребляющих одно и то же знание.
Это важно, потому что доставка ПО страдает не от недостатка текста. Она страдает от недостатка канонического, связанного, проверяемого и исполняемого текста.
Долговечный субстрат должен позволять одному и тому же артефакту быть:
- прочитанным человеком;
- разобранным агентом;
- проверенным в pull request;
- проверенным движками политик;
- трансформированным в тикеты;
- отрендеренным в документационные сайты;
- проиндексированным для поиска и retrieval;
- встроенным в RAG-пайплайны;
- связанным с изменениями кода и инфраструктуры;
- процитированным в согласованиях и аудитах.
Это принципиально другая операционная модель, чем «написать страницу, скопировать куски в тикет, упомянуть политику в другом месте и надеяться, что все обновят всё синхронно».
GitOps должен выйти за пределы инфраструктуры
Большинство людей слышат GitOps и думают о манифестах Kubernetes или деплое инфраструктуры из Git. Это слишком узко. Более сильная идея шире: каноническое намерение системы живёт в версионированных, ревьюируемых декларативных артефактах, а автоматизация реагирует на состояние репозитория как на авторитетный сигнал для следующего действия.
Эта идея не должна останавливаться на инфраструктуре.
Она должна распространяться на весь SDLC:
- продуктовые определения;
- бизнес-правила;
- архитектурные ограничения;
- владение сервисами;
- операционные ранбуки;
- политики деплоя;
- маппинг контролей;
- записи об исключениях;
- ожидания по тестам;
- стратегии релизов;
- заметки о готовности поддержки.
Когда эти артефакты живут в том же управляемом субстрате, что и код и инфраструктура, одновременно улучшаются несколько вещей.
Во-первых, изменения становятся явными. Если определение изменилось, виден дифф. Во-вторых, ревью становится единым: изменение фичи, привязка политики, обновление ранбука и ограничение релиза могут проходить через один pull request. В-третьих, автоматика становится точнее: системе больше не нужно вытаскивать частичные подсказки из разрозненных инструментов. В-четвёртых, улучшается аудируемость: можно проследить, как идея стала реализацией, с привязанным контекстом, а не разбросанными фрагментами. В-пятых, агенты становятся полезнее, потому что работают с каноническими артефактами, а не с устаревшими снимками вики.
Git — это больше, чем контроль версий
Git часто недооценивают в этом обсуждении, потому что его воспринимают как место хранения кода. Но в агентной SDLC Git также является control plane для организационного намерения.
Фаулер проводит полезную аналогию в контексте event sourcing: система контроля версий — это знакомый пример event-sourced системы, где лог коммитов работает как event store, а рабочее дерево — как текущее состояние. Эта аналогия мощно применима и к знаниям о доставке ПО.
Если ключевые артефакты доставки живут в Git, вы получаете несколько преимуществ, напрямую влияющих на управление и точность:
- временную историю того, что команда считала истиной в любой момент;
- атрибутируемую историю изменений: кто, что и почему поменял;
- лёгкую реконструкцию прежних состояний для аудитов и разбора инцидентов;
- ветвление для изучения альтернатив без порчи канонического состояния;
- merge-based ревью для человеческих и автоматизированных контрольных точек;
- детерминированные триггеры автоматизации от изменений репозитория.
Поэтому Git-центричный субстрат ощущается гораздо естественнее для агентной работы, чем база тикетов. Агенты не просто читают страницу. Они участвуют в версионированном, управляемом потоке объявленного намерения.
OKF как пример практической реализации
Google Open Knowledge Format, или OKF, интересен именно тем, что не переусложняет ответ. В своей основе OKF предлагает простую, открытую, вендор-нейтральную структуру: markdown-файлы с YAML-frontmatter, организованные в директории.
Простота — это и есть суть.
Объект знания становится чем-то, что человек может читать напрямую, а программа — надёжно парсить. Он может нести структурированные поля: owner, status, domain, sensitivity, review date, tags, relationships, summary, — и при этом сохранять полное нарративное объяснение в markdown.
Это сочетание важно, потому что большинство корпоративных знаний не является ни чисто структурированным, ни чисто нарративным. Нужно и то, и другое.
Субстрат в стиле OKF даёт практичный способ представлять:
- архитектурные заметки;
- определения продуктовых возможностей;
- бизнес-правила;
- ADR — архитектурные решения;
- каталог сервисов;
- ранбуки поддержки;
- рисковые решения;
- интерпретации политик;
- маппинг контролей;
- операционные процедуры;
- глоссарные термины.
Каждый из них становится долговечным активом, а не изолированной страницей. И что важнее, каждый из них доступен людям и агентам через одно и то же представление.
Где наконец встречаются управление знаниями и управление задачами
Одна из худших привычек enterprise-доставки — рассматривать knowledge management и task management как отдельные вселенные.
- В одной вселенной команды ведут документы.
- В другой — управляют работой.
- В реальности эти две вещи неразделимы.
Задачи имеют смысл только в связи со знаниями: бизнес-намерением, ограничениями, архитектурой, операционными допущениями, контролями, зависимостями и определениями готовности. А знания остаются достоверными только если работа обновляет их в рамках обычной поставки.
Единый субстрат замыкает этот цикл. Задача не обязана быть каноническим домом истины. Она может быть адресуемой единицей исполнения относительно канонической истины.
Например, пакет изменения может указывать на:
- файл определения фичи;
- артефакт бизнес-правила;
- записи затронутых сервисов;
- требуемые документы политик;
- связанные ранбуки;
- ожидаемые классы тестов;
- ограничения релиза;
- необходимые sign-off.
Из этого ядра система может генерировать или синхронизировать:
- элементы бэклога;
- чек-листы имплементации;
- релизные гейты;
- промпты архитектурного ревью;
- промпты threat model;
- тестовые планы;
- дельты документации;
- задачи готовности поддержки;
- аудиторские пакеты доказательств.
Важная инверсия в следующем: задачи генерируются из субстрата и привязываются к нему. Субстрат не восстанавливается постфактум из тикетов. Эта одна инверсия резко снижает дрейф.
Контроли становятся бесшовными, а не церемониальными
Именно здесь появляется настоящая enterprise-ценность. Большая часть управления доставкой сегодня церемониальна, потому что логика контроля хранится в прозе и воспроизводится вручную.
Люди говорят фразы вроде:
- такой тип изменений требует sign-off архитектора;
- эти поля требуют особой обработки;
- сервисам этого класса нужны ранбуки;
- эта фича требует юридического ревью;
- этот путь деплоя нуждается в дополнительной валидации.
Эти утверждения часто существуют на вики-страницах, в библиотеках контролей, таблицах или племенной памяти. Это не управление. Это устремление.
Управление становится реальным, когда правила могут прикрепляться непосредственно к артефактам и изменениям, которыми они управляют. Git и markdown-субстрат сильно упрощают это.
Если определение фичи говорит, что она затрагивает платежи, регулируемые данные, публичный API и критический клиентский сценарий, система доставки может вывести или потребовать:
- более глубокое ревью;
- более сильное тестовое покрытие;
- дополнительную security-валидацию;
- явное планирование отката;
- требования к наблюдаемости;
- обновления документации;
- проверки готовности поддержки;
- sign-off от названных владельцев.
Так выглядит исполняемое управление. И поскольку логика работает на канонических текстовых артефактах, а не на разрозненных UI-полях, её легче инспектировать, диффить, улучшать и переиспользовать.
Точность растёт, когда контекст перестаёт рассыпаться
Самая большая выгода этой модели — не скорость, хотя скорость тоже растёт.
Более значимый выигрыш — точность.
Большая часть потерь в доставке ПО возникает из-за деградации контекста:
- тикет упускает важное бизнес-правило;
- разработчик не видит архитектурное ограничение;
- ревьюер не знает операционные последствия;
- тестовый план пропускает регуляторное условие;
- релизный процесс игнорирует реальный радиус поражения;
- ранбук устарел, потому что никто не вспомнил его обновить.
ИИ может сделать всё это ещё хуже, если ускорит работу поверх неполного контекста. Это та же проблема, что и при настройке сквозной аналитики и лидгена: если данные размазаны по системам, скорость растёт быстрее, чем управляемость.
Единый субстрат повышает точность, потому что даёт агентам и людям лучший слой заземления:
- канонические определения вместо параллельных копий;
- метаданные владения и статуса вместо анонимных страниц;
- прослеживаемые связи между артефактами;
- история репозитория вместо тихих правок;
- машиночитаемые ограничения вместо расплывчатых предупреждений;
- прямая связь между кодом, контролями и вспомогательным знанием.
Иными словами, систему становится легче осмыслять, потому что знание перестаёт растворяться между инструментами.
Будущий интерфейс генерируется, а не ведётся вручную
Именно здесь тезис о «смерти Jira и Confluence» становится точнее. Будущее — это не «нет Jira, нет Confluence, нет дашбордов, нет порталов и нет статусных страниц».
Будущее в том, что эти поверхности всё чаще генерируются, синхронизируются или проецируются из субстрата, а не ведутся вручную как источник истины.
Из одного структурированного слоя знаний можно генерировать:
- executive-сводки;
- планы спринтов и итераций;
- представления рабочих элементов;
- пакеты архитектурного ревью;
- комплаенс-доказательства;
- заметки для передачи в поддержку;
- онбординг-гайды;
- представления developer-портала;
- поисковые индексы;
- коллекции для retrieval и RAG;
- сводки change-risk;
- релизные чек-листы.
Так обычно и зреет архитектура ПО. Мы перестаём размещать интеллект в презентационном слое и переносим его в более качественные подлежащие модели и интерфейсы.
То же самое вот-вот произойдёт с процессом доставки ПО.
Что заменит бэклог как первичный объект?
Скорее всего, не один объект. Скорее — небольшое семейство канонических артефактов.
Можно ожидать, что агентные организации всё чаще будут работать с комбинациями:
- определения продуктовых возможностей;
- предложения изменений;
- бизнес-правила;
- записи сервисов;
- архитектурные решения;
- декларации политик и контролей;
- ранбуки и операционные процедуры;
- ожидания по тестам и релизам.
Элемент бэклога тогда становится представлением работы над этими артефактами, а не объектом, из которого приходится выводить весь смысл.
Это важно, потому что бэклог-элементы намеренно сжаты. Они созданы для координации человеческой работы на верхнем уровне. Они ужасны как единственный субстрат для смешанной человеко-агентной системы, которой нужны нюансы, прослеживаемость и учёт политик.
Это не убивает ценности Agile, а наконец делает их операциональными
Если что, эта модель честнее исполняет часть исходного Agile-намерения, чем корпоративный инструментальный стек, присвоивший этот ярлык.
- «Работающее ПО важнее исчерпывающей документации» никогда не означало «плохо структурированный контекст, разбросанный по инструментам».
- «Готовность к изменениям важнее следования плану» никогда не означало «потерять след, почему изменение произошло».
- «Сотрудничество важнее согласования контракта» никогда не означало «сделать встречи единственным слоем интеграции».
Единый субстрат на самом деле усиливает итеративную поставку, потому что делает изменения легче для ревью, управления, распространения и объяснения.
Он сохраняет гибкость, одновременно снижая неоднозначность. Это гораздо более выгодный обмен, чем текущая модель процесс-театра поверх разрозненных систем.
Практический маршрут миграции
Ни одна крупная организация не включит это за неделю, и это не требуется. Разумный путь — инкрементальный.
Начните с нескольких областей знаний, где точность и переиспользование важнее всего:
- архитектурные решения;
- записи владения сервисами;
- определения продуктовых возможностей;
- политики безопасной разработки и деплоя;
- операционные ранбуки;
- маппинг контролей для чувствительных изменений.
Представьте их в Git-friendly формате с markdown и структурированными метаданными.
Затем добавьте немного автоматизации:
- валидацию обязательных полей;
- проверки свежести артефактов;
- ссылки на pull request и сервисы;
- простые генерируемые документационные представления;
- индексацию для внутренних AI-ассистентов;
- проверки политик, привязанные к конкретным метаданным.
После этого подключите задачи и контроли доставки к этим артефактам. Как только команды ощутят снижение дрейфа и рост ясности, модель начнёт оправдывать себя сама. Именно так мы в маркетинговое агентство Dragon Farm проектируем автоматизацию: сначала — управляемый слой истины, затем — генерируемые представления, уведомления и управленческие дашборды.
Суть не в поклонении Markdown
Markdown не священен. Git не священен. OKF не священен. Важен принцип.
Канонический субстрат доставки должен быть:
- человекочитаемым;
- машиночитаемым;
- открытым и портируемым;
- ревьюируемым;
- версионным;
- управляемым;
- автоматизируемым;
- компонуемым во множество выходных поверхностей.
Прямо сейчас Git-и-markdown-центричный подход — это самый практичный, широко понятный и низкофрикционный способ получить эти свойства.
Jira и Confluence выживут как проекции
Нет, Jira и Confluence, вероятно, буквально не умрут. Но их статус изменится. Они станут downstream-системами, презентационными слоями, управленческими порталами и представлениями записей над более важным субстратом.
А «Agile» выживет только если избавится от идеи, что процесс живёт в церемониях и статусах тикетов. Реальное будущее доставки ПО — это не агентная работа поверх более красивых досок.
Это агентная работа, заземлённая в едином, управляемом и машиночитаемом субстрате знаний, который управляет кодом, контролями, решениями и выходами на всём жизненном цикле. Именно там будет жить настоящая работа. Всё остальное станет представлением.
