[{"data":1,"prerenderedAt":155},["ShallowReactive",2],{"footer-topics-uk":3,"post-uk-agile-ai-values-principles-estimation-is-not-the-problem":70},{"topics":4},[5,21,33,46,58],{"locale":6,"name":7,"slug":8,"blurb":9,"summary":10,"state":11,"featuredOnHub":12,"hubOrder":13,"accent":14,"questionsTitle":15,"questions":16,"body":20},"uk","Шлях","the-journey","Від перших експериментів з Agile × ШІ до робочої системи — історія думки, що стоїть за нею.","Від перших експериментів до робочої системи — справжня історія створення Agile4AI, включно з хибними поворотами, які визначили все.","published",true,2,"gold","Чого цей шлях не перестає нас навчати",[17,18,19],"Що переконало нас, що Agile і ШІ створені одне для одного, — і що ледь не переконало нас у протилежному?","Які хибні повороти виявилися найповчальнішими?","Як SCI пройшов шлях від експерименту з копіюванням і вставкою до відповідей ШІ, на які справді можна покластися?","\nКожна ідея в цьому розділі народилася з нашого власного досвіду розробки Agile4AI. Нам не терпиться поділитися цією історією з вами — і перемогами, і поразками, — адже ми переконані: навчитися краще працювати зі ШІ ми можемо лише разом. Те, до чого ми дійшли, народилося не з теорії. Воно народилося з практики, з помилок, із готовності починати заново, врахувавши засвоєні уроки.\n\nУсе почалося з простого запитання: чи можна переосмислити Agile для епохи ШІ? А далі були роки експериментів, зруйнованих припущень, несподіваних відкриттів і повільного визрівання чогось, що й справді працює, — підходу під назвою Структурований спільний інтелект (SCI) і побудованої на ньому системи Agile4AI.\n\nЦе не пригладжена ретроспектива, написана з висоти прожитого. Це історія, розказана настільки близько до того, як усе було насправді, наскільки це можливо, — з усіма глухими кутами, хвилинами сумнівів і проривами, що перевертали наші уявлення.\n\nМи ділимося нею, бо урок криється в самій історії. Висновки важливі, але не менш важливо й *те, як ми до них дійшли*, — адже саме шлях показує, що спрацювало, що ні й чому.\n\nМатеріали цього розділу охоплюють усю дугу шляху: ранні експерименти зі спільною роботою зі ШІ, народження SCI, окремі відкриття, що змінили те, як ми працюємо, і віхи, які варто відзначити. Якісь тексти вийшли споглядальними. Якісь — без прикрас. Але всі вони — справжні.\n\nЯкщо вам хочеться зрозуміти, чому Agile4AI та SCI взагалі з’явилися на світ, — а не лише що вони собою являють, — починайте звідси.\n",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":28,"body":32},"Agile: розшифровка","agile-decoded","Що насправді означають терміни Agile — не звичне скорочення, не версія карго-культу, не глосарій методолога.","Словник Agile широко використовується і широко тлумачиться неправильно. Правильно розуміти терміни — це не педантизм, а різниця між ритуалом і роботою.",3,"Чому термінологія має принципове значення",[29,30,31],"Якщо стендап проводиться як звіт про статус, що насправді втрачає команда?","Коли «Методологія Agile» стала стандартним виразом, як це вплинуло на підхід організацій до трансформації?","Які витрати команди, яка може назвати кожну практику Agile, але не розуміє призначення жодної з них?","\nУ Agile є проблема зі словником. Не тому що терміни незрозумілі — більшість людей у сучасних організаціях їх чули. А тому що це знайомі слова, що використовуються в зовсім іншому контексті, і без цього контексту люди співвідносять їх з тим, що вже знають.\n\nКоли хтось вперше зустрічає поняття «Scrum Master», найближчим доступним концептом виявляється «менеджер проекту». Така відповідність здається природною — майже очевидною. Контекст зовсім інший.\n\nНіхто не збудував достатньо чіткого мосту між ними. А проблема посилилась, коли добросовісні практики — люди, що щиро прагнули допомогти організаціям рухатися вперед — почали описувати Agile як «краще управління проектами». Почали писати книги під назвою «Методологія Agile». Коли ви називаєте свій підхід методологією, його оцінюють за стандартами методології: артефакти планування, фазові шлюзи, структура результатів. Коли Agile не продукує цього — бо так і не задумувався — він не відповідає цим стандартам, і цілком обґрунтовано. Проблема не в тому, що Agile — погана методологія. Проблема в тому, що Agile взагалі не є методологією. Називати його так гарантувало розчарування всіх, хто шукав методологію, і те, що всі, хто його прийняв, будували щось, що Waterfall давно описав.\n\nСтендап перетворюється на статусний звіт. Sprint перетворюється на дедлайн. Backlog перетворюється на список завдань. «Методологія Agile» стає стандартним позначенням того, що автори Маніфесту не впізнали б як опис того, що вони створили. І коли слова означають не те, що треба, практики, побудовані на них, дають хибні результати — точно, добросовісно і у масштабі.\n\nЦей розділ — виправлення концепт за концептом. Не посібник зі стилю — функціональний довідник. Кожна публікація бере одне слово або фразу, що стали ключовими в тому, як організації розуміють Agile, досліджує, що вони насправді означають, і пояснює, що втрачається, коли скорочення замінює суть. Це не просто термінологічні розбіжності. «Бажаний результат» — не більш витончене слово для «специфікації»: це зовсім інша річ, з зовсім іншої моделі того, як робиться робота. Термін — це поверхня. Концепт під ним — ось що важливо.\n\nТой самий паттерн проявляється, коли організації звертаються до ШІ, — і концептуальний розрив тут ширший. У випадку з Agile базові концепти були принаймні сформульовані, хоча й погано донесені. У випадку зі ШІ самі концепти ще лише формуються, а в масовому розумінні ледве починають вимальовуватися. Словник випереджає осмислення: ШІ як «автоматизація», ШІ як «інструмент», «ШІ-трансформація» як проект із датою завершення. Кожне з цих визначень закріплює ментальну модель раніше, ніж хтось встигає перевірити, чи вона підходить. Те, як ми називаємо речі, визначає, що і як ми будуємо. Правильні слова — необхідна умова для правильної роботи.\n\nТут діє один принцип: ментальні моделі первинні. Мова їх виражає. Дії слідують. Коли ментальна модель не відповідає роботі, словник, що її виражає, несе цю невідповідність — і дії, побудовані на цьому словнику, добросовісно виконуватимуть викривлене розуміння у масштабі, з повною відданістю. Зміна словника без зміни мислення дає в кращому випадку таблицю перекладу: таблицю відповідностей, де «sprint» відповідає чомусь на кшталт «короткого дедлайну». Таблиці перекладу дозволяють людям працювати через розрив. Вони його не усувають. Публікації цього розділу цілять у більше, ніж переклад. Вони цілять у зміну ментальної моделі.\n",{"locale":6,"name":34,"slug":35,"blurb":36,"summary":37,"state":11,"featuredOnHub":12,"hubOrder":38,"accent":39,"questionsTitle":40,"questions":41,"body":45},"Структурований спільний інтелект","structured-collaborative-intelligence","Де спільне мислення перевершує одну передову модель — і де ні.","Де структурована взаємодія — між моделями та між моделями й людьми — дає результати, яких одна модель не досягне самостійно.",4,"green","Питання, до яких ми повертаємося знову й знову",[42,43,44],"Де структурований спільний інтелект створює цінність, яку одна модель просто не може відтворити?","Коли моделі розходяться в думках, що це говорить вам — і як ви це використовуєте?","Як побудувати структуру, яка робить співпрацю з ШІ продуктивною, а не просто надлишковою?","\nОкрема модель ШІ, якою б здібною вона не була, розмірковує наодинці. Їй нікому заперечити її припущення, виявити сліпі плями чи помітити, що вона відхилилась від початкового наміру. Solo-AI — робота з однією моделлю за раз — вразлива до цього. Модель, якій доручено дати вам відповідь, дасть її — навіть якщо в неї немає хорошої відповіді, яку варто було б вам показувати.\n\nСтруктурований спільний інтелект (SCI) — це інший підхід. Замість того, щоб вважати результат однієї моделі кінцевим підсумком, SCI використовує структуровану взаємодію — між кількома ШІ-моделями та між моделями й людьми — щоб отримувати результати, які надійніші, ретельніше перевірені й чесніші щодо власних обмежень. Моделі перевіряють одна одну. Розбіжності виявляють приховані припущення. Сам процес створює петлю зворотного зв'язку, яку взаємодія з однією моделлю не може відтворити.\n\nЗв'язок з Agile прямий: саме так завжди працювали високоефективні команди. Не одна людина, що дає відповідь в ізоляції, а структурований процес співпраці, перевірки та ітерації, який вловлює те, що пропускає будь-яка окрема точка зору. SCI застосовує цю саму дисципліну до ШІ.\n\nУ міркуванні наодинці є й глибший недолік. Solo-AI прив'язує вас до єдиного джерела даних, єдиної архітектури та єдиного набору вбудованих упереджень — а отже, і до єдиної форми відповіді, точна вона чи ні. Згадайте, як добрий детектив опитує кількох свідків. Не тому що хтось із них бреше, а тому що кожна точка зору відкриває те, що інші пропустили. Разом вони наближаються до того, що сталося насправді. SCI працює так само: кілька моделей різного походження, кожна зі своїм кутом зору. Отримана відповідь розглянута з різних боків — вона багатша, повніша, і її важче запідозрити у прихованій помилці.\n\nКоли взаємодіють моделі різного походження, результати покращуються там, де це важливо: менше самовпевнених помилок, краще оброблюються граничні випадки, міркування стає виразнішим — таким, яке люди можуть оцінити й скоригувати. Розбіжності між моделями — не шум, який треба придушувати, а саме той сигнал, що потрібен вам, коли ставки високі.\n\nSCI — аналітичний двигун сервісу Agile4AI. Матеріали цього розділу документують, що таке SCI, як він працює на практиці, де він створює справжню цінність і — не менш важливо — де ні. Частина дисципліни — вміти розрізнити одне й інше.\n",{"locale":6,"name":47,"slug":48,"blurb":49,"summary":50,"state":11,"featuredOnHub":12,"hubOrder":51,"accent":52,"questionsTitle":40,"questions":53,"body":57},"Цінності та принципи Agile4AI","agile-ai-values-principles","Цінності та принципи Agile в епоху ШІ — що залишається в силі, що змінюється і чому ми запрошуємо найсильніші заперечення.","Мислення Agile у застосуванні до роботи зі ШІ — що залишається актуальним, що загострюється, і чому зв’язок між Agile і ШІ не є випадковим.",5,"red",[54,55,56],"Коли комплексну роботу неможливо повністю спланувати заздалегідь, що це означає для роботи зі ШІ?","Як змінюється акцент Agile на постійному зворотному зв’язку, коли ваш партнер не втомлюється і не займає оборонної позиції?","Чи є «Agile для ШІ» природним поєднанням — або заперечення про помилку категорій насправді вирішальне?","\nМислення Agile було викувано в умовах комплексності (у кеневіновському сенсі: емерджентної, де причинно-наслідкові зв’язки видно лише ретроспективно) — не для того, щоб управляти нею, усуваючи її, а щоб проходити крізь неї усвідомлено й розумно. Це не стає менш актуальним, коли ваш партнер — модель ШІ. У багатьох відношеннях це стає ще більш актуальним.\n\nЦей розділ присвячено тій самій взаємодії: не Agile-by-prescription, не фреймворкам і церемоніям, а глибинним цінностям і принципам, що їх Agile дистилював — і тому, як вони застосовуються, загострюються й часом потребують переосмислення, коли люди та ШІ працюють разом.\n\nКлючове розуміння полягає в тому, що мислення Agile завжди було відповіддю на *природу* комплексної роботи, а не просто на особливості людських команд. Коли Agile поставив під сумнів припущення, що комплексну роботу можна детально спланувати заздалегідь, це не був обхідний шлях для людських обмежень — це було точне спостереження про те, як насправді поводиться недетермінована, швидкозмінна робота. Це спостереження не змінюється від того, що в справу вступає ШІ. Воно загострюється.\n\nОцінку варто назвати прямо — це одне з найбільш дискусійних питань навіть серед відданих аджайлістів. Agile виник не для того, щоб допомогти командам краще оцінювати; він виник, щоб показати, чому оцінка *ламається* у комплексній роботі — і замінити хибну точність емпіричними вимірюваннями та справжнім зворотним зв’язком, що дійсно покращує прогнозування поставок. В епоху ШІ, де результати ймовірнісні, а сама робота чинить опір фіксованим специфікаціям, це розуміння актуальніше, ніж будь-коли.\n\nЦе також місце для Принципової Дискусії: там, де найсильніші заперечення проти «Agile для ШІ» отримують трибуну. Ми переконані, що аргумент витримує критику. І ми хочемо, щоб нас спростували, якщо це не так.\n",{"locale":6,"name":59,"slug":60,"blurb":61,"summary":62,"state":11,"featuredOnHub":12,"hubOrder":63,"accent":64,"questionsTitle":40,"questions":65,"body":69},"Психологічна безпека ШІ","ai-psychological-safety","Чому свобода сказати «я ще не знаю» є передумовою справжнього інтелекту.","Умови, які ви створюєте у своєму спілкуванні, визначають те, що ШІ повертає вам — і коли ці умови хибні, результатом є впевненість без надійності.",6,"amethyst",[66,67,68],"За яких умов ШІ радше визнає справжню невизначеність, ніж видасть упевнено звучну здогадку?","Як те, у якій формі ви ставите запитання, визначає, чи буде відповідь надійною — чи лише заспокійливою?","Що переноситься з підходу Agile до психологічної безпеки — і що потрібно адаптувати для ШІ?","\nБільшість людей розглядає психологічну безпеку як суто людську проблему — умови, що дозволяють людині висловитися, висловити сумнів чи поставити ідею під сумнів без страху. І це слушно — наскільки сягає такий погляд.\n\nАле щось важливе губиться, коли ми забуваємо, звідки взявся ШІ. ШІ створений людьми, сформований людською мовою, навчений на зробленому людьми виборі. Закономірності, що впливають на роботу людини, — зокрема психологічна безпека — переносяться на взаємодію зі ШІ з тих самих глибинних причин, на які Agile завжди вказував: **умови, які ви створюєте у своєму спілкуванні, визначають те, що ви отримуєте у відповідь.**\n\nШІ, якого підштовхують до впевнено звучних відповідей, видаватиме впевнено звучні відповіді — незалежно від того, чи виправдана ця впевненість. Якщо у ШІ немає простору сказати «я не впевнений», він заповнить цю порожнечу чимось іншим, бо директиви вимагають від нього відповідати навіть тоді, коли він сам розуміє, що правильної відповіді в нього немає. Ця динаміка відрізняється від людської психологічної безпеки, але базовий принцип той самий: інтелект працює краще, коли йому дозволено чесно визнавати, чого він не знає.\n\nЦе має практичне значення. Галюцинації, надміру самовпевнені відповіді та системи ШІ, які кажуть вам те, що ви хочете почути, а не те, що відповідає правді, — це не суто технічні збої. Найчастіше це збої в дизайні взаємодії: промпти, формулювання, неявні очікування, закладені в сам спосіб постановки запитання.\n\nПублікації тут досліджують умови, за яких спільна робота людини та ШІ стає надійнішою і правдивішою. Серед них — як складати промпти, що запрошують справжню невизначеність, а не пригнічують її; у чому різниця між детерміністським та імовірнісним використанням ШІ і чому це розрізнення змінює все в тому, як ви формулюєте свою роботу; і що з застосовуваного в Agile підходу до психологічної безпеки в людських командах зберігає силу, коли вашим партнером стає модель.\n\nТут само ми розбираємо сценарії збоїв: що відбувається, коли цих умов немає, і чого це коштує.\n",{"kind":71,"post":72,"topic":85,"availableLocales":87,"translations":96,"html":153,"audioUrl":154},"post",{"audio":-1,"author":73,"category":48,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":63,"slug":77,"state":11,"tags":78,"title":83,"translationKey":77,"updatedAt":84},"Seán González","Agile виник не для того, щоб допомогти командам краще оцінювати. Він виник, тому що оцінка ламається в комплексній роботі — і рішення не в тому, щоб оцінювати точніше, а в тому, щоб інакше ставитися до невизначеності.",false,"2025-03-15T10:00:00.000Z","estimation-is-not-the-problem",[79,80,81,82],"Agile","Оцінювання","Комплексність","Цінності","Оцінка — не проблема","2026-06-14T00:00:00.000Z",{"locale":6,"name":47,"slug":48,"blurb":49,"summary":50,"state":11,"featuredOnHub":12,"hubOrder":51,"accent":52,"questionsTitle":40,"questions":86,"body":57},[54,55,56],[88,89,90,91,92,6,93,94,95],"en-US","es-419","fr-FR","pt-BR","de-DE","ru","ja","bo",[97,107,115,122,128,135,137,144],{"audio":-1,"author":73,"category":48,"excerpt":98,"featured":75,"locale":88,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":99,"slug":77,"state":11,"tags":100,"title":105,"translationKey":77,"updatedAt":106},"Agile didn't emerge to help teams estimate better. It emerged because estimation breaks in complex work — and the fix isn't better estimates, it's a different relationship with uncertainty.",7,[101,102,103,104],"agile","estimation","complexity","values","Estimation is not the problem","2026-06-13T10:00:00.000Z",{"audio":-1,"author":73,"category":48,"excerpt":108,"featured":75,"locale":89,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":109,"slug":77,"state":11,"tags":110,"title":114,"translationKey":77,"updatedAt":84},"Agile no surgió para ayudar a los equipos a estimar mejor. Surgió porque la estimación se rompe en trabajo complejo — y la solución no son mejores estimaciones, sino una relación diferente con la incertidumbre.",8,[79,111,112,113],"Estimación","Complejidad","Valores","La estimación no es el problema",{"audio":-1,"author":73,"category":48,"excerpt":116,"featured":75,"locale":90,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":109,"slug":77,"state":11,"tags":117,"title":121,"translationKey":77,"updatedAt":84},"Agile n'est pas né pour aider les équipes à mieux estimer. Il est né parce que l'estimation se rompt dans le travail complexe — et la solution n'est pas de meilleures estimations, c'est une relation différente avec l'incertitude.",[79,118,119,120],"Estimation","Complexité","Valeurs","L'estimation n'est pas le problème",{"audio":-1,"author":73,"category":48,"excerpt":123,"featured":75,"locale":91,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":109,"slug":77,"state":11,"tags":124,"title":127,"translationKey":77,"updatedAt":84},"Agile não surgiu para ajudar equipes a estimar melhor. Surgiu porque a estimativa se rompe no trabalho complexo — e a solução não são melhores estimativas, mas uma relação diferente com a incerteza.",[79,125,126,113],"Estimativa","Complexidade","Estimativa não é o problema",{"audio":-1,"author":73,"category":48,"excerpt":129,"featured":75,"locale":92,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":99,"slug":77,"state":11,"tags":130,"title":134,"translationKey":77,"updatedAt":84},"Agile entstand nicht, um Teams bei besseren Schätzungen zu helfen. Es entstand, weil Schätzung bei komplexer Arbeit versagt — und die Lösung sind nicht bessere Schätzungen, sondern eine andere Beziehung zur Unsicherheit.",[79,131,132,133],"Schätzung","Komplexität","Werte","Schätzung ist nicht das Problem",{"audio":-1,"author":73,"category":48,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":63,"slug":77,"state":11,"tags":136,"title":83,"translationKey":77,"updatedAt":84},[79,80,81,82],{"audio":-1,"author":73,"category":48,"excerpt":138,"featured":75,"locale":93,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":99,"slug":77,"state":11,"tags":139,"title":143,"translationKey":77,"updatedAt":84},"Agile возник не для того, чтобы помочь командам лучше оценивать. Он возник, потому что оценка ломается в комплексной работе — и решение не в том, чтобы оценивать точнее, а в том, чтобы иначе относиться к неопределённости.",[79,140,141,142],"Оценка","Комплексность","Ценности","Оценка — не проблема",{"audio":-1,"author":73,"category":48,"excerpt":145,"featured":75,"locale":94,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":146,"slug":77,"state":11,"tags":147,"title":152,"translationKey":77,"updatedAt":84},"アジャイルはチームの見積もり精度を上げるために生まれたのではない。複雑な仕事において見積もりが機能しないという認識から生まれた。解決策はより良い見積もりではなく、不確実性への向き合い方を変えることだ。",1,[148,149,150,151],"アジャイル","見積もり","複雑性","価値観","見積もりは問題ではない","\u003Cp>Оцінка — одна з найбільш спірних тем в Agile-спільнотах. Суперечки зазвичай ідуть так: story points проти годин, відносне оцінювання проти абсолютного, #NoEstimates проти певної кількості оцінок, planning poker проти того, що прийшло йому на зміну.\u003C\u002Fp>\n\u003Cp>Це реальні дискусії. І вони, як правило, упускають глибшу проблему — те, що аргументи про те, \u003Cem>як\u003C\u002Fem> оцінювати, підмінюють розмову про те, \u003Cem>чи є проблемою сама модель оцінки\u003C\u002Fem>.\u003C\u002Fp>\n\u003Ch2>Що Agile насправді говорив про оцінку\u003C\u002Fh2>\n\u003Cp>Agile виник не для того, щоб допомогти командам краще оцінювати. Він виник, тому що хтось помітив: у комплексній роботі (у кеневіновському сенсі: емерджентній, де причинно-наслідкові зв’язки видно лише ретроспективно) — роботі, де повні вимоги неможливо знати заздалегідь, де правильний підхід розкривається в самій роботі, — точність, яку обіцяє оцінка, виявляється хибною.\u003C\u002Fp>\n\u003Ch2>Що насправді означає «комплексна робота»\u003C\u002Fh2>\n\u003Cp>Цю фразу — \u003Cem>комплексна робота, робота, де повні вимоги неможливо знати заздалегідь\u003C\u002Fem> — легко проминути. Та не варто. Це головне, несуче твердження цього посту: не засвоївши його, усе подальше можна сприйняти як аргумент про техніки оцінки, а не про те, чи придатна сама оцінка для цієї мети.\u003C\u002Fp>\n\u003Cp>Комплексна робота — це не про проекти, де команда була недостатньо розумна чи недостатньо дисциплінована або де ще не застосували правильну методологію. Це позначення окремої категорії: роботи, де зв’язок між причиною і наслідком можна зрозуміти лише заднім числом. Де правильний підхід розкривається на практиці, а не в аналізі. Де вимоги змінюються не тому, що зацікавлені сторони погано подумали заздалегідь, а тому, що сама робота змінює те, що потрібно.\u003C\u002Fp>\n\u003Cp>Методології — навіть чудові — створені для простої і складної роботи. Вони діють, застосовуючи відомі патерни до відомих типів задач. У цьому і є їхня цінність у тих контекстах, для яких їх розробляли. У комплексної роботи відомих патернів немає. У неї є емерджентні. Застосування методології до комплексної роботи не вирішує проблему — воно створює ілюзію структури, тоді як реальна невизначеність лишається незачепленою. Міні-Waterfall — короткоциклове послідовне планування, яким непомітно стали багато впроваджень Agile, — потрапляє в ту саму категорію. Тривалість ітерації змінюється; базове припущення, що попереднє планування здатне надійно спрямовувати роботу, — ні.\u003C\u002Fp>\n\u003Cp>«Безжальне спрощення» — суміжний рецепт, який варто розглянути. Якщо роботу справді можна звести до відомого типу задачі — спростіть її, це хороша практика. Але це гігієна, а не управління комплексною роботою. Те, що лишається після всіх можливих спрощень, — це та частина, яка спрощенню опирається, тобто сама комплексна робота; їй потрібне те, чого стратегії спрощення дати не можуть. У 2025 році, якщо конкурентна відповідь на комплексність звучить як «треба спрощувати ще більше», то розмова про реальне управління комплексною роботою ще навіть не почалася.\u003C\u002Fp>\n\u003Cp>Публічний розворот Джеффріса — це не просто зміна думки про одиницю виміру. Це визнання чогось глибшого: передумова була хибною. Оцінка передбачає категорію роботи, де попередній аналіз дає надійні прогнози. Для простої і складної роботи це припущення тримається достатньо добре. Для комплексної роботи — ні, і жодне вдосконалення техніки цього не змінить. Одного разу засвоєне, це розуміння змінює сенс усього подальшого.\u003C\u002Fp>\n\u003Cp>Двотижневий спринт, що постачає робоче ПЗ, — це не кращий метод оцінки. Це заміна оцінки емпіричним вимірюванням. Замість того щоб передбачати, скільки часу займе робота, ви вимірюєте, скільки насправді зроблено — у реальних умовах, реальними інкрементами. Передбачення поступається місцем ритму і циклу зворотного зв’язку.\u003C\u002Fp>\n\u003Cp>Це не тонке розрізнення. Воно означає, що команди, які працюють за Agile-процесами, але досі вважають метою точну оцінку в story points, докорінно не зрозуміли, навіщо цей процес потрібен.\u003C\u002Fp>\n\u003Ch2>Чому суперечки не вщухають\u003C\u002Fh2>\n\u003Cp>Суперечки про оцінку не вщухають почасти тому, що організації, які прийняли Agile, не відмовилися від своєї базової потреби — систем управління, побудованих на прогнозах, бюджетах, термінах, контрактах. Agile-церемонії просто наклали поверх цієї потреби. Story points стали заміною годинам. Velocity стала вхідними даними для планування. Agile-словник перейняли, а очікування прогнозів — ні.\u003C\u002Fp>\n\u003Cp>Ситуація, що склалася, справді неоднозначна. Одні команди працюють там, де «ніяких оцінок» справді можливо, — де зацікавлені сторони навчилися довіряти емпіричному постачанню і не потребують прогнозів. Інші — там, де контракти, регуляторні вимоги або організаційна культура роблять ту чи іншу форму прогнозування неминучою.\u003C\u002Fp>\n\u003Cp>Позиція Agile полягає не в тому, що оцінка завжди хибна. Вона в тому, що оцінка в комплексній роботі структурно ненадійна — що впевненість, яку приписують оцінкам, регулярно перевищує реальні підстави для неї, — і що дисципліна коротких циклів постачання з живим зворотним зв’язком покращує передбачуваність сильніше, ніж досконаліші методи оцінки.\u003C\u002Fp>\n\u003Ch2>Проблема одиниць виміру — і закономірність, яку варто помітити\u003C\u002Fh2>\n\u003Cp>Зараз в Agile-колах набирає популярності відхід від story points до Ідеальних Людино-Днів (IPDs) — повернення до оцінки на основі часу, яке його прихильники вважають інтуїтивнішим і простішим для захисту перед зацікавленими сторонами.\u003C\u002Fp>\n\u003Cp>Варто знати, звідки взялися story points. Рон Джеффріс — один із трьох засновників Extreme Programming і один із тих, хто підписав Agile-маніфест, — винайшов story points. Вони виросли безпосередньо з ideal days — одиниці на основі часу, яку XP-команди використовували від початку. Біда з ideal days була в тому, що зацікавлені сторони чули «три ideal days» і розуміли це як зобов’язання вкластися в три дні, попри застереження «ideal». Тому позначку про час прибрали, і одиницею стало голе число. Story points за своїм походженням — це ideal days, у яких прибрали прив’язку до часу саме для того, щоб їх не сприймали як зобов’язання щодо термінів.\u003C\u002Fp>\n\u003Cp>Відтоді Джеффріс написав про це прямо. «Мені подобається говорити, що story points, можливо, винайшов я, — написав він у 2019 році, — і якщо так, то тепер мені шкода». Сьогодні він один із найпомітніших прихильників #NoEstimates — позиції, згідно з якою проблема не в тому, яку одиницю оцінки ви використовуєте, а в тому, що оцінка в комплексній роботі принципово ненадійна незалежно від одиниці.\u003C\u002Fp>\n\u003Cp>Варто запитати, чому перехід до IPDs відбувається саме зараз. Річ не в тому, що команди знайшли кращий метод оцінки. Річ у тім, що IPDs лягають на фінансову інфраструктуру Waterfall — бюджетні цикли, системи проектного обліку, моделі виставлення рахунків за контрактами та інструменти планування штату, які організації вибудували навколо планування на основі часу і так і не змінили, коли переходили на Agile. Story points у ці системи не вписуються. IPDs — вписуються.\u003C\u002Fp>\n\u003Cp>Це не еволюція Agile. Це Waterfall, який знову заявляє про себе в шатах Agile, — використовуючи фінансові структури, які так і не демонтували, щоб тягнути практику назад до тієї моделі, заради якої ці структури й створювалися. Одиниця оцінки змінилася; організаційна система, що вимагає зобов’язань щодо термінів, — ні. Результат — той самий театр прогнозів, лише під новою назвою.\u003C\u002Fp>\n\u003Cp>Це не компанії нарешті беруть штурвал і виправляють те, що Agile проґавив. Це компанії заново утверджують інфраструктуру, яка так і не змінилася. IPDs не вимагають жодного зсуву в мисленні, розумінні чи світогляді — ви просто переклеюєте ярлик на те, що й так знаєте. Саме тому вони набирають обертів.\u003C\u002Fp>\n\u003Cp>Тут Agile-спільнота проґавила шанс на лідерство. Коли попит на оцінки термінів повернувся під виглядом IPDs, правильною відповіддю було назвати те, що відбувається, своїм іменем: це фінансова логіка Waterfall знову утверджується над практикою Agile. Натомість багато практиків пішли назустріч, сприйнявши цей попит як обмеження, яким треба керувати, а не як помилку категорії, яку треба виправити. У підсумку команди, які найвільніше володіють Agile-словником, часто реалізують найвитонченішу версію тієї самої моделі, яку Agile мав замінити.\u003C\u002Fp>\n\u003Ch2>Людство вчиться повільно\u003C\u002Fh2>\n\u003Cp>Тут є закономірність глибша, ніж методологія оцінки. Це звичка приймати зміну ярлика за зміну практики — плутати перехід на новий словник зі зсувом мислення, який цей словник і мав виразити.\u003C\u002Fp>\n\u003Cp>Визначення божевілля, яке приписують Ейнштейну, цитують часто і зазвичай помилково, але воно незмінно влучає в ціль: робити те саме знову і знову, очікуючи іншого результату. Авторство, найпевніше, апокрифічне. Закономірність — ні. Організації, що перейняли Agile-церемонії без Agile-мислення, тепер переймають церемонії-наступники, не перевіряючи, чи змінилося мислення під ними. Слова інші. Модель та сама.\u003C\u002Fp>\n\u003Cp>Розмова, яку цей пост намагається почати, — не про одиниці оцінки. Вона про те, чи справді ваша організація розібралася, що таке комплексна робота і чого вона вимагає. Якщо ваша інфраструктура планування не змінилася — якщо вам досі потрібні прогнози, зобов’язання та облік на основі часу, що виходить із того, що попередній аналіз дає надійні передбачення, — тоді суперечки про оцінку лише симптом. А вказують вони на те, що зсув, який пропонував Agile, ще не стався.\u003C\u002Fp>\n",null,1789790610920]