Подборка пропущенного с Global Agile Summit 2026

Эти семь я посмотрел на следующий день после завершения Global Agile Summit 2026. Для участия в прямых сессиях вопросов и ответов первого дня требовался предварительный билет, который я пропустил, пока слоты не закрылись; выступления Итана Чейзина и Адама Гутса я не смог найти на YouTube — похоже, это эксклюзивы Oikosofy Library. Пять пропущенных сессий и две запоздавшие из библиотеки, просмотренные подряд. Здесь всплыли и две мысли с начала недели: туда, где выполнение становится дешевле, туда смещается суждение; прямое наблюдение за пользователями до сих пор подает косвенный сигнал. Но на этот раз спикеры конкретно показали, как эти мысли проявляются в рабочей неделе.

Джефф Паттон — Почему мы создаем не то, что нужно (вопросы и ответы)

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

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

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

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

Его главный аргумент — в том, что первоначальные авторы Манифеста Agile в основном продавали часы консалтинга, а не выпускали продукт, и поэтому оптимизировали работу под сотрудничество с тем, кто им платил, а не под ценность для конечного пользователя. Это тот вид исторического утверждения, над которым я еще долго буду размышлять. Манифест до сих пор полезен. А структуру стимулов, породившую его, стоит честно признать.

Шон Воллак — К вашей компании только что присоединился самый быстрый инженер в истории

Подготовленное выступление Воллака мне уже приходилось слышать раньше — выполнение сжимается, суждение становится узким местом, ИИ — бензопила, а лесоруб всё равно выбирает дерево. Большая часть прямой сессии вела тот же аргумент под другим названием. Новыми были операционные моменты.

Фраза, которая соответствует тому, как я работаю со своими агентами, — это слова самого Воллака: «Эта штука — самая быстрая печатная машинка, которую я видел в жизни». Это совпадает с тем, что на самом деле делает моя оркестровка — быстрая на клавиатуре, без собственного суждения. Воллак озвучил и более сложное утверждение: ИИ никогда не обладал и никогда не будет обладать субъектностью, а пара «субъектность плюс ответственность» — это та единица, которая на самом деле делает кого-то ответственным за произведённое. Оба остаются с человеком-рецензентом, который нажимает кнопку.

Метафора авиадиспетчерского управления стала новым элементом. Скорость самолета уже не является ограничением. Управление воздушным пространством — вот ограничение. Мой конвейер новостей о крупных кошках может пропустить через свои циклы проверки больше единиц за день, чем я вручную. Узкое место не в том, сколько самолетов могут лететь. А в том, каким из них я даю разрешение на посадку, в каком порядке и по каким критериям. Та же самая форма на самописном оркестраторе соцсетей, который я написал наряду с этим. Та же самая форма на стеках агентов, которые я создаю для основной работы — код-ревью, расследование тикетов, генерация тест-планов. Узкое место решений смещается; исполнительная мощность становится фоном.

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

Макс Пьехота — Автономная фабрика программного обеспечения

Это была скорее 25-минутная сессия вопросов и ответов, чем сольное выступление с тезисами, и фактическое содержание под названием «фабрика» оказалось более узким, чем я ожидал. Аргумент Макса заключался в том, что правильный способ управления ИИ-агентами — это не мягкие навыки и текстовые ограничения, а спецификации поведения в стиле BDD и фитнес-функции: детерминированные зелено-красные тесты, над которыми агент итерирует, пока не пересечет порог.

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

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

Рамка «фабрики» в названии не совсем подходит. Панель её не развила, а коннотация командной пропускной способности не подходит к той разновидности сольной оркестровки, которой занимаюсь я. Фрагмент о фитнес-функции переносится независимо от этого.

Дейв Вестгарт — Vibe UX (вопросы и ответы)

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

Markdown как интерфейс — вот что я хочу сохранить. Концепция Вестгарта: дизайн-системы исчезают, но markdown-файлы, которые могут читать агенты, долговечны. Кодифицируй паттерны, которые хочешь видеть соблюденными, как читаемые агентом спецификации — конвенции именования, правила разметки, проверки доступности, регистр текстов — и подавай их в рабочий контекст агента так, как если бы ты вручил человеку-подрядчику руководство по стилю. Большая часть моей собственной инфраструктуры уже похожа на Markdown, оформлена как документация для людей. Переформулировка Вестгарта меняет аудиторию — те же файлы, другой читатель. Небольшая переформулировка, реальное практическое последствие для того, как я структурирую контракты агентов, которые пишу для себя.

Другая тактика, которую стоит попробовать, — правило остановки. «Поставь точку — мне нужно, чтобы ты сделал эту часть. Я это забираю, а потом снова приступаю к работе». Агент выполняет ограниченный фрагмент; человек его подхватывает и продолжает. Я делаю это неформально под давлением уже сейчас; превращение этого в часть контракта агента остановило бы режим отказа, когда агент перебегает к работе, которая должна была бы быть моей.

Сессия вопросов и ответов с участниками выявила также паттерн дневного кредитного лимита: небольшие, повторяющиеся сессии ИИ-прототипирования на фиксированном бюджете токенов вместо неограниченного «выжигания». Ограничение бюджета навязывает дисциплину, которую трудно навязать себе самому.

Итан Чейзин — Бизнес-обоснование расширения полномочий сотрудников

Выступление, которого не было на YouTube. Чейзин потратил десятилетие на изучение около 7000 организаций примерно в 250 странах, по его подсчетам, и его вывод — тот самый, на который большинство авторов, пишущих об agile и лидерстве, намекает, не называя: переменная, которая стабильно коррелирует с более высокими финансовыми результатами, — это культура, ориентированная на расширение полномочий, а не страна, не отрасль, не послужной список руководящей команды.

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

Больше всего мне понравился тезис о менеджерах среднего звена. Менеджеры ответственны примерно за 70% вовлеченности сотрудников, на основе ежедневного взаимодействия. Изменения сверху вниз — это модно, но рычаг — посередине. И именно там происходит та работа, которой занимаюсь я. «Теперь ты переходишь от менеджера к лидеру». Эта формулировка почти точно соответствует тому, как я описываю свою склонность: я предпочитаю руководить и вмешиваться только тогда, когда это необходимо для работы. Чейзин дал мне форму бизнес-обоснования для этой склонности.

Еще один фрагмент, который он упоминает вскользь, — Project Aristotle, вывод Google о том, что психологическая безопасность является важнейшим фактором, определяющим продуктивность команды; его цитировали так часто, что слова утратили свою значимость. Вклад Чейзина — операционный уровень: психологическая безопасность — не лозунг, это отсутствие конкретного вида наказания за раннее выявление рисков. Фреймворк Six Boxes, который он использует (управляй ожиданиями и обратной связью; обеспечивай инструменты и ресурсы; устанавливай последствия и стимулы), переводит сторону работодателя в этой сделке в разряд наблюдаемых обязанностей.

Умар Иджаз — Инди-игры: естественная среда для agile (вопросы и ответы)

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

Циклы обратной связи не масштабируются — это сквозная линия. Иджаз собрал свою первую группу для плейтеста из восьми человек, найденных на игровых фестивалях, в университетах и других сообществах. И вел это на Discord, который пришлось создать самому, так как существующие сообщества не подходили. Плейтест наблюдательный и структурированный: тестировщик взаимодействует с игрой в реальном времени, а разработчик наблюдает, задает открытые уточняющие вопросы, не наговаривает. Явно противопоставил это «речевому» направлению: пост в LinkedIn, который увидели 300 человек из 8000 подписчиков. Один ответ.

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

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

Я давно слежу за индустрией, а не являюсь инди-разработчиком. Книги Шрайера — часть моего мировоззрения о том, как создаются продукты, а инди-дисциплины Иджаза подходят для сольной работы, такой как моя, благодаря масштабу, а не медиуму.

Адам Гутс — Ежедневный agile на строительной площадке: значимые метрики

Строительный трек, только библиотечный, пятьдесят две минуты метрик стройплощадки. Этот я чуть не пропустил. Фреймворк переносится чище, чем я ожидал.

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

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

Перенос на мою команду поддержки прямой. Большинство метрик пропускной способности тикетов — запоздалые. Инверсия PPI от Гутса — это опережающее индикаторное дополнение: отслеживай не закрытые баги и незавершённые расследования тикетов с прикреплённым «почему нет». Заблокировано выше по цепочке, ждет дизайна, переоценено как малозначимое. Не данные для обвинений. Диагностические данные — что блокирует что дальше. Я планирую попробовать это при следующем проходе по бэклогу багов.

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

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

Что показала догнательная выборка

Две вещи, которые я возьму на заметку. Инверсия PPI от Гутса пригодится при следующем проходе по бэклогу — отслеживай незакрытые баги и незавершённые расследования с прикреплённым «почему нет». Переформулировка Вестгарта «markdown-как-интерфейс» — небольшая поправка в настройке агентов, которую я и так пишу для себя. Обе — из выступлений, которые я чуть не пропустил.