Кент Бек — легенда інженерії програмного забезпечення. Один із засновників Extreme Programming, автор TDD, співавтор JUnit і підписант Agile Manifesto. У розмові на подкасті The Pragmatic Engineer він з дивовижною відвертістю повернувся до історії народження маніфесту, пояснив, чому сама назва «agile» була помилкою, як рух перетворився на прибуткову, але порожню індустрію «чарівних пігулок» та чому без технічного фундаменту вся ця гнучкість нагадує людину, яку вперше поставили на сноуборд на вершині лавини.
Як народився Agile Manifesto — і чому перше ім’я в списку нічого не означає
Наприкінці 90‑х у професійній спільноті визрів відкритий конфлікт. З одного боку — «дорослий» Rational Unified Process з товстими методичками, інструментами за мільйони доларів і водоспадними практиками. З іншого — група практиків, які вже тоді будували ітеративну, гнучку розробку, але кожен у своєму таборі: XP, Scrum, Feature-Driven Development та інші.
Бек згадує, як ця неформальна опозиція спершу зустрілася в Норвегії, плаваючи на поромі вздовж фіордів, щоб з’ясувати: чи мають вони достатньо спільного, аби виступати разом. Висновок був: так, але его та розбіжностей забагато.
Наступний крок — запрошення до Snowbird. Там, у горах, зібралися 17 людей з «здоровими его», як делікатно формулює Бек. Перша частина зустрічі йшла погано: кожен намагався протягнути «своє» в загальний текст, пропозиції суперечили одна одній, напруга росла. Група пішла на перерву, а в кімнаті лишилися Мартін Фаулер і Джим Хайсміт.
Коли всі повернулися, сталося те, що Бек називає «магічним моментом». На стіні вже висів каркас тексту:
«Ми цінуємо це понад те…» — формат протиставлення,
і чотири конкретні пункти — усе це вже було.
Це ядро маніфесту стало тим компромісом, якого не могли досягти у великій кімнаті. Потім група додала принципи. Власний вклад Бека в цю частину мінімалістичний: він пригадує, що єдине слово, яке точно його, — «щоденна» у фразі про щоденну взаємодію з користувачами.
Далі постало практичне питання: в якому порядку розташовувати імена під текстом. Варіанти були політичними за визначенням, тож зійшлися на найменш конфліктному рішенні — алфавітному порядку. Так вийшло, що прізвище Beck йде першим, і Бек формально став «першим підписантом», хоча сам наголошує: це чиста випадковість сортування, а не відображення ролі.
Ефект публікації він описує як миттєвий. Інтернет-бум ще не встиг луснути, всі шукали підходи, які дозволили б розробляти швидко, з опцією маневру, а не зацементованими планами. Маніфест потрапив у нерв моменту: дав спільну мову тим, хто вже працював по‑іншому, і сильний маркер ідентичності всім, хто підписувався онлайн.
Але саме тут, на рівні назви, за словами Бека, і було закладено майбутню проблему.
«Agile» як невдала назва: коли марка не захищається
Окрема дискусія в Snowbird точилася навколо того, як назвати новий спільний підхід. Комусь спало на думку слово «agile». Бек був проти й залишається проти досі.
Його ключова претензія: назва не захищається. Формулювання він зводить до простого тесту:
ніхто не скаже: «я не agile, я люблю негнучку (rigid) розробку» або «я прихильник інфлексибл девелопменту».
Це слово неможливо заперечити в нормальній діловій розмові. Отже, кожен може назвати себе agile‑командою, навіть якщо їхня практика взагалі не має нічого спільного із тим, що мали на увазі автори маніфесту.
Для контрасту Бек порівнює це з власним брендом Extreme Programming. Він навмисно обрав слово «extreme», щоб відсіяти випадкових: воно звучить різко, з викликом, і передбачає високий бар’єр входу.
У його логіці:
кожен скаже, що він agile, навіть якщо точно ні. Але ти ніколи не назвеш себе extreme‑програмістом, якщо ти ним не є.
«Extreme» натякає на серйозну підготовку — так само, як екстремальні види спорту. Не можна просто вперше стати на сноуборд на вершині лавини. Спершу роки тренувань, досвіду, дослідження ризиків. Лише потім — спуск. Це слово вбудовано стримує самозванців.
«Agile» ж, навпаки, нічого не стримує. В результаті, підсумовує Бек, термін пройшов шлях від місткого і надихаючого до повністю розмитого:
сьогодні це слово не просто нічого не означає, воно означає вже щось негативне.
Вибух agile-індустрії та «чарівні обіцянки» без техніки
Agile Manifesto був задуманий як спільний знаменник різних підходів. Але дуже швидко навколо нього виросла інша реальність — комерційна індустрія сертифікацій, масштабованих фреймворків, дорогих трансформацій. Те, що часто критикують як «snake oil»: продукт, який обіцяє чудеса, при цьому не розв’язуючи базових проблем.
Бек не приховує, що цього боявся ще при створенні тексту. Він наполягає: маніфест — лише перетин ідей людей у кімнаті, далеко не повна карта ремесла. Сам він після того написав «книги і книги» про технічні практики, без яких гнучкість не тримається.
Його головний закид до після‑agile‑світу — спроба продавати організаційну «гнучкість» без інженерного фундаменту. Формула звучить різко:
без фундаменту технічних навичок ти можеш казати, що зможеш переплановувати, додавати фічі в будь‑якому порядку, але якщо в тебе немає технічних скілів… це як поставити людину на вершину лавини на сноуборді вперше.
Обіцянка «ми можемо реалізувати будь‑яку фічу в будь‑якій послідовності» — це не маніфест, а наслідок щоденної праці над якістю коду, дизайном, інфраструктурою, власними інструментами. У його трактуванні це означає:
вміти швидко й надійно писати код маленькими шматками;
уміти проектувати так само поетапно;
навчитися зберігати та нарощувати опціональність системи;
бути здатним створювати власні інструменти, коли стандартних бракує.
Це важко. Це роки навчання. І це, за досвідом Бека, не те, що зазвичай викладають на класичних програмах з інформатики чи моделює перший роботодавець молодого розробника.
На цьому фоні особливо різко виглядає контраст із частиною комерційної agile‑екосистеми. Бек прямо говорить:
були люди, які були готові казати: «ні, ні, не переживайте, це легко, будь‑хто може це робити. Вдвічі більше роботи за пів часу». З моєї точки зору, це просто брехня.
Він не заперечує саму ідею продуктивності: так, у принципі можливо зробити «вдвічі більше за пів часу». Але це, підкреслює він, вимагає важкого, свідомого прокачування технічних і командних компетенцій — а не купівлі сертифіката чи впровадження модної рамки.
Коли бренд отруює ідею
Бек визнає, що «agile» зробив неймовірно багато для популяризації альтернативи водоспаду. Але водночас сам термін — тепер гиря на нозі. Слово, яке мало бути прапором змін, перетворилося на ярлик, від якого дедалі частіше відхрещуються ті, хто практикує, по суті, те саме.
Причин кілька, і всі вони проглядаються крізь його розповідь.
По‑перше, нечіткість бренду. Якщо кожен може назватися agile, референт зникає. Під одним і тим самим прапором опиняються невеличкі команди, які щодня говорять з користувачами і тримають систему під суцільними автоматизованими тестами, та гігантські бюрократичні організації з десятками ролей, обрядовими мітингами й роками техборгу. Ззовні вони однаково «agile».
По‑друге, розрив між деклараціями і практиками. Маніфест говорить про робочий софт, співпрацю, реагування на зміни. На практиці «agile‑трансформація» занадто часто перетворювалася на новий шар процесів, ролей і звітності, але без вкладення в ремесло: тестування, рефакторинг, архітектуру, дебаг‑інструменти.
По‑третє, агресивний маркетинг. Обіцянки «удвічі більше роботи за половину часу» красиво звучать із трибуни, але в досвіді Бека це ознака саме тієї «snake oil»‑культури, якій він протистоїть. І коли проєкти під цим соусом провалювалися, негатив осідав не лише на конкретних консультантах, а й на самому слові «agile».
Результат — термін, який, за оцінкою одного з його співзасновників, перестав означати щось конкретне й набув негативного відтінку.
Після Agile: що лишається від маніфесту
Попри всю критику назви й індустрії навколо, Бек не відкидає змісту Agile Manifesto. Навпаки, значну частину кар’єри він будував на практиках, які безпосередньо реалізують його принципи: короткі ітерації, тісна взаємодія з бізнесом, прозорість прогресу, відповідальність за якість.
Розрив, який він бачить сьогодні, не між «agile» і «waterfall», а між словами й діями. У його особистому визначенні agile — це «здатність встигати відповісти вчасно». А отже, справжня гнучкість — не сертифікат і не церемонії, а комбінація:
– технічних практик, які дають можливість змінювати систему швидко й без страху;
– організаційних рішень, що не блокують ці зміни;
– чесності щодо своїх обмежень, замість обіцянок «магії».
Сам Agile Manifesto, в цій оптиці, лишається історичним артефактом і корисним нагадуванням про цінності. Проблема не в тексті й навіть не в тому, що він став популярним, а в тому, як легко прижився ярлик без змісту.
Бек при цьому звертає увагу ще на один урок. Маніфест не з’явився на порожньому місці — він став результатом приблизно 15 років інтенсивної роботи з об’єктно‑орієнтованим програмуванням. Лише після довгого періоду експериментів, успіхів і помилок практики змогли звести спостереження до лаконічного набору принципів.
Тому, коли сьогодні його питають: «А де новий маніфест для епохи AI?» — він відповідає, що ще занадто рано. Спочатку — роки реальної роботи з новими інструментами й підходами. Потім, можливо, з’явиться текст, який конденсує цей досвід. Але не навпаки.
Висновок: чесність замість магії
Історія Agile Manifesto в інтерпретації Кента Бека — це не ностальгія за героїчними часами й не спроба відхреститися від успішного бренду. Це радше спроба відділити те, що працює, від того, як це упакували.
Він не відмовляється від ідей, що стояли за XP та Agile: короткі цикли, прозорість, співпраця, відповідальність за якість і готовність змінювати курс. Але він насторожено ставиться до будь‑якої обіцянки «вдвічі більше за пів часу», яка не спирається на серйозний технічний і командний фундамент.
У цій оптиці життя «після Agile» — не про пошук нової гучної назви, а про повернення до ремесла. Про готовність чесно сказати, скільки з обіцяної гнучкості справді підкріплено кодом, тестами, інфраструктурою й навичками людей, а скільки — лише яскравими слайдами.
Джерело
Подкаст The Pragmatic Engineer, випуск «How Kent Beck shapes the software engineering industry»
YouTube: https://www.youtube.com/watch?v=ddHQQtjIOpw