Стос недодивленого з 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-як-інтерфейс» - менша поправка в риштуванні агентів, яке я й так пишу для себе. Обидві — з виступів, які я мало не пропустив.