Оцінка — одна з найбільш спірних тем в Agile-спільнотах. Суперечки зазвичай ідуть так: story points проти годин, відносне оцінювання проти абсолютного, #NoEstimates проти певної кількості оцінок, planning poker проти того, що прийшло йому на зміну.
Це реальні дискусії. І вони, як правило, упускають глибшу проблему — те, що аргументи про те, як оцінювати, підмінюють розмову про те, чи є проблемою сама модель оцінки.
Що Agile насправді говорив про оцінку
Agile виник не для того, щоб допомогти командам краще оцінювати. Він виник, тому що хтось помітив: у комплексній роботі (у кеневіновському сенсі: емерджентній, де причинно-наслідкові зв’язки видно лише ретроспективно) — роботі, де повні вимоги неможливо знати заздалегідь, де правильний підхід розкривається в самій роботі, — точність, яку обіцяє оцінка, виявляється хибною.
Що насправді означає «комплексна робота»
Цю фразу — комплексна робота, робота, де повні вимоги неможливо знати заздалегідь — легко проминути. Та не варто. Це головне, несуче твердження цього посту: не засвоївши його, усе подальше можна сприйняти як аргумент про техніки оцінки, а не про те, чи придатна сама оцінка для цієї мети.
Комплексна робота — це не про проекти, де команда була недостатньо розумна чи недостатньо дисциплінована або де ще не застосували правильну методологію. Це позначення окремої категорії: роботи, де зв’язок між причиною і наслідком можна зрозуміти лише заднім числом. Де правильний підхід розкривається на практиці, а не в аналізі. Де вимоги змінюються не тому, що зацікавлені сторони погано подумали заздалегідь, а тому, що сама робота змінює те, що потрібно.
Методології — навіть чудові — створені для простої і складної роботи. Вони діють, застосовуючи відомі патерни до відомих типів задач. У цьому і є їхня цінність у тих контекстах, для яких їх розробляли. У комплексної роботи відомих патернів немає. У неї є емерджентні. Застосування методології до комплексної роботи не вирішує проблему — воно створює ілюзію структури, тоді як реальна невизначеність лишається незачепленою. Міні-Waterfall — короткоциклове послідовне планування, яким непомітно стали багато впроваджень Agile, — потрапляє в ту саму категорію. Тривалість ітерації змінюється; базове припущення, що попереднє планування здатне надійно спрямовувати роботу, — ні.
«Безжальне спрощення» — суміжний рецепт, який варто розглянути. Якщо роботу справді можна звести до відомого типу задачі — спростіть її, це хороша практика. Але це гігієна, а не управління комплексною роботою. Те, що лишається після всіх можливих спрощень, — це та частина, яка спрощенню опирається, тобто сама комплексна робота; їй потрібне те, чого стратегії спрощення дати не можуть. У 2025 році, якщо конкурентна відповідь на комплексність звучить як «треба спрощувати ще більше», то розмова про реальне управління комплексною роботою ще навіть не почалася.
Публічний розворот Джеффріса — це не просто зміна думки про одиницю виміру. Це визнання чогось глибшого: передумова була хибною. Оцінка передбачає категорію роботи, де попередній аналіз дає надійні прогнози. Для простої і складної роботи це припущення тримається достатньо добре. Для комплексної роботи — ні, і жодне вдосконалення техніки цього не змінить. Одного разу засвоєне, це розуміння змінює сенс усього подальшого.
Двотижневий спринт, що постачає робоче ПЗ, — це не кращий метод оцінки. Це заміна оцінки емпіричним вимірюванням. Замість того щоб передбачати, скільки часу займе робота, ви вимірюєте, скільки насправді зроблено — у реальних умовах, реальними інкрементами. Передбачення поступається місцем ритму і циклу зворотного зв’язку.
Це не тонке розрізнення. Воно означає, що команди, які працюють за Agile-процесами, але досі вважають метою точну оцінку в story points, докорінно не зрозуміли, навіщо цей процес потрібен.
Чому суперечки не вщухають
Суперечки про оцінку не вщухають почасти тому, що організації, які прийняли Agile, не відмовилися від своєї базової потреби — систем управління, побудованих на прогнозах, бюджетах, термінах, контрактах. Agile-церемонії просто наклали поверх цієї потреби. Story points стали заміною годинам. Velocity стала вхідними даними для планування. Agile-словник перейняли, а очікування прогнозів — ні.
Ситуація, що склалася, справді неоднозначна. Одні команди працюють там, де «ніяких оцінок» справді можливо, — де зацікавлені сторони навчилися довіряти емпіричному постачанню і не потребують прогнозів. Інші — там, де контракти, регуляторні вимоги або організаційна культура роблять ту чи іншу форму прогнозування неминучою.
Позиція Agile полягає не в тому, що оцінка завжди хибна. Вона в тому, що оцінка в комплексній роботі структурно ненадійна — що впевненість, яку приписують оцінкам, регулярно перевищує реальні підстави для неї, — і що дисципліна коротких циклів постачання з живим зворотним зв’язком покращує передбачуваність сильніше, ніж досконаліші методи оцінки.
Проблема одиниць виміру — і закономірність, яку варто помітити
Зараз в Agile-колах набирає популярності відхід від story points до Ідеальних Людино-Днів (IPDs) — повернення до оцінки на основі часу, яке його прихильники вважають інтуїтивнішим і простішим для захисту перед зацікавленими сторонами.
Варто знати, звідки взялися story points. Рон Джеффріс — один із трьох засновників Extreme Programming і один із тих, хто підписав Agile-маніфест, — винайшов story points. Вони виросли безпосередньо з ideal days — одиниці на основі часу, яку XP-команди використовували від початку. Біда з ideal days була в тому, що зацікавлені сторони чули «три ideal days» і розуміли це як зобов’язання вкластися в три дні, попри застереження «ideal». Тому позначку про час прибрали, і одиницею стало голе число. Story points за своїм походженням — це ideal days, у яких прибрали прив’язку до часу саме для того, щоб їх не сприймали як зобов’язання щодо термінів.
Відтоді Джеффріс написав про це прямо. «Мені подобається говорити, що story points, можливо, винайшов я, — написав він у 2019 році, — і якщо так, то тепер мені шкода». Сьогодні він один із найпомітніших прихильників #NoEstimates — позиції, згідно з якою проблема не в тому, яку одиницю оцінки ви використовуєте, а в тому, що оцінка в комплексній роботі принципово ненадійна незалежно від одиниці.
Варто запитати, чому перехід до IPDs відбувається саме зараз. Річ не в тому, що команди знайшли кращий метод оцінки. Річ у тім, що IPDs лягають на фінансову інфраструктуру Waterfall — бюджетні цикли, системи проектного обліку, моделі виставлення рахунків за контрактами та інструменти планування штату, які організації вибудували навколо планування на основі часу і так і не змінили, коли переходили на Agile. Story points у ці системи не вписуються. IPDs — вписуються.
Це не еволюція Agile. Це Waterfall, який знову заявляє про себе в шатах Agile, — використовуючи фінансові структури, які так і не демонтували, щоб тягнути практику назад до тієї моделі, заради якої ці структури й створювалися. Одиниця оцінки змінилася; організаційна система, що вимагає зобов’язань щодо термінів, — ні. Результат — той самий театр прогнозів, лише під новою назвою.
Це не компанії нарешті беруть штурвал і виправляють те, що Agile проґавив. Це компанії заново утверджують інфраструктуру, яка так і не змінилася. IPDs не вимагають жодного зсуву в мисленні, розумінні чи світогляді — ви просто переклеюєте ярлик на те, що й так знаєте. Саме тому вони набирають обертів.
Тут Agile-спільнота проґавила шанс на лідерство. Коли попит на оцінки термінів повернувся під виглядом IPDs, правильною відповіддю було назвати те, що відбувається, своїм іменем: це фінансова логіка Waterfall знову утверджується над практикою Agile. Натомість багато практиків пішли назустріч, сприйнявши цей попит як обмеження, яким треба керувати, а не як помилку категорії, яку треба виправити. У підсумку команди, які найвільніше володіють Agile-словником, часто реалізують найвитонченішу версію тієї самої моделі, яку Agile мав замінити.
Людство вчиться повільно
Тут є закономірність глибша, ніж методологія оцінки. Це звичка приймати зміну ярлика за зміну практики — плутати перехід на новий словник зі зсувом мислення, який цей словник і мав виразити.
Визначення божевілля, яке приписують Ейнштейну, цитують часто і зазвичай помилково, але воно незмінно влучає в ціль: робити те саме знову і знову, очікуючи іншого результату. Авторство, найпевніше, апокрифічне. Закономірність — ні. Організації, що перейняли Agile-церемонії без Agile-мислення, тепер переймають церемонії-наступники, не перевіряючи, чи змінилося мислення під ними. Слова інші. Модель та сама.
Розмова, яку цей пост намагається почати, — не про одиниці оцінки. Вона про те, чи справді ваша організація розібралася, що таке комплексна робота і чого вона вимагає. Якщо ваша інфраструктура планування не змінилася — якщо вам досі потрібні прогнози, зобов’язання та облік на основі часу, що виходить із того, що попередній аналіз дає надійні передбачення, — тоді суперечки про оцінку лише симптом. А вказують вони на те, що зсув, який пропонував Agile, ще не стався.
Коментарі 0