Методики оцінювання

Чотири одиниці на одному екрані

Спершу все порівняння, бо саме по нього ви прийшли. Про ці чотири одиниці зазвичай сперечаються так, ніби одна з них правильна, а решта — помилки. Вони не суперники. Вони вимірюють різне, пасують до роботи різного розміру й передають перетворення зусиль на дату різним людям. Читайте таблицю по рядку, щоб зрозуміти одну одиницю, і по стовпцю — щоб побачити, чим вони насправді відрізняються.

Найважливіший стовпець — п’ятий. Кожну оцінку врешті перетворюють на дату, бо клієнтові, спонсорові чи плану релізів вона потрібна. У story points коефіцієнт, що перетворює розмір на час, вимірюють постфактум: це velocity, якої команда справді досягла за останні кілька спринтів. У людино-днях і годинах коефіцієнт припускають до початку роботи — хтось вирішує, що в дні шість продуктивних годин або що четверо людей закінчать учетверо швидше. Ця одна відмінність пояснює більшість суперечок про те, яка одиниця краща.

Яка одиниця для якого рішення

Оцінка — це діапазон, а не дата

Найкорисніша ідея про оцінювання водночас і найменш практикована: оцінка — це розподіл імовірностей, а число, яке кажуть уголос, зазвичай є його найоптимістичнішою правдоподібною точкою. Усе інше на цій сторінці — яка одиниця, яка шкала, який ритуал — важить менше за це.

Три слова плутають між собою, і саме ця плутанина спричиняє більшість суперечок про оцінки. Стів Макконнелл розводить їх у книжці Software Estimation (2006). Оцінка — це прогноз того, скільки щось займе. Ціль — це твердження про те, чого хоче бізнес: «нам це треба до конференції в березні». Зобов’язання — це обіцянка віддати до певної дати, і його мають давати на основі оцінки, а не замість неї. Коли менеджер питає «встигнете до березня?», він питає, чи підтримує оцінка ціль, і чесна відповідь — імовірність, а не «так».

Тривалості робіт скошені праворуч. Задача не може завершитися швидше, ніж за нуль часу, але цілком може забрати втричі більше запланованого, і способів, як щось піде не так, більше, ніж способів, як воно піде ідеально. На скошеному розподілі найімовірніше значення, медіана й середнє — три різні числа, саме в такому порядку. Коли людина уявляє, що робота йде нормально, і називає число, вона називає найімовірніше значення — а його, за такого розкиду, як на діаграмі, дотримуються лише приблизно тричі з десяти.

Наскільки точною вона може бути

Точність залежить від того, що відомо, а на старті відомо дуже мало. Баррі Бем виміряв це в 1981 році, а Стів Макконнелл пізніше популяризував як конус невизначеності: на етапі першої ідеї справжні зусилля можуть опинитися будь-де — від чверті до вчетверо більшого за оцінку, і діапазон звужується в міру ухвалення рішень. PMBOKPMBOKA Guide to the Project Management Body of Knowledge — довідник PMI з управління проєктамиДовідник Project Management Institute з управління проєктами й основа сертифікації PMP. Видання має значення: 6-те (2017) приписувало 49 процесів, 7-ме (2021) замінило їх дванадцятьма принципами, а 8-ме (2025) має шість принципів, сім доменів і сорок процесів.Докладніше в статті →Усі терміни для вартості використовує схожу драбину: груба оцінка порядку величини на старті має влучити в межі від −25% до +75%, остаточна — від −5% до +10%.

До конуса додаються два застереження. Це найкращий випадок, а не типовий: дані Тодда Літтла з Landmark Graphics (IEEE Software, 2006) показали, що співвідношення фактичної й оціненої тривалості наприкінці проєктів лишається майже таким самим широким, як на початку. Конус звужується лише тоді, коли команда ухвалює рішення, що прибирають мінливість, — урізає обсяг, фіксує архітектуру, завершує ризикову інтеграцію, — а не просто тому, що минає час. А діапазон, вужчий, ніж дозволяє етап, — це не точність, а здогад у костюмі.

Story points: відносний розмір

Story point — це одиниця відносного розміру. Команда обирає еталонний елемент, який уже віддала, — невелику, добре зрозумілу історію, — називає її 2 чи 3 і оцінює все інше порівнянням: це приблизно вдвічі більше за те, а це трохи менше. Число навмисно поєднує три речі: обсяг роботи, її складність і невизначеність щодо неї. Нудна, але велика міграція даних і маленька зміна в коді, якого ніхто не розуміє, обидві можуть бути на 8.

Одиниця абстрактна навмисно. Люди погано передбачають абсолютні тривалості й добре порівнюють дві речі поруч, і відносна шкала використовує ту навичку, яка в них є. До того ж її не можна прочитати як обіцянку: три пункти — це не три дні ні для кого, тож ніхто поза командою не може тримати команду за слово так, ніби це були дні.

Чому в шкалі є прогалини

Більшість команд користуються модифікованою послідовністю Фібоначчі — 1, 2, 3, 5, 8, 13, 20, 40, 100, — часто ще з картками ½, 0 і «?». Прогалини ростуть, бо з розміром має падати точність. Різницю між 2 і 3 видно; різниці між 13 і 14 — ні, і шкала, що пропонує 14, розпочала б суперечку, яку ніхто не виграє. Майк Кон, чия книжка Agile Estimating and Planning (2005) поширила цю послідовність, пояснює її законом Вебера з психології: ми сприймаємо різницю у відсотках, а не в абсолютних величинах, тож і кроки мають бути приблизно пропорційними.

Усе, що від 20 і вище, — це не оцінка, а сигнал. Елемент завеликий або надто неясний, щоб його оцінити, і правильна реакція — розділити його або провести spike, коротке дослідження з обмеженим часом, а тоді оцінити знову.

Planning poker крок за кроком

Planning poker описав Джеймс Греннінг у 2002 році, а популяризувала книжка Майка Кона 2005 року. Його цінність — не в числі, яке він дає. Вона в тому, що розбіжність стає видимою до початку роботи, поки вона ще дешева.

1. 1.Один раунд planning poker

   1. 1.1Product OwnerProduct Ownerвідповідає за те, що будуютьОдна людина, відповідальна за те, що команда будує і в якому порядку. Повноваження тут справжні: Product Owner, який мусить погоджувати кожне рішення деінде, є посильним, і роль перестає працювати.Докладніше в статті →Усі терміни читає елемент і відповідає на питання. Ще ніхто не оцінює.
   2. 1.2Кожен обирає картку сам, мовчки.
   3. 1.3Усі картки відкривають одночасно, щоб ніхто не заякорився на першому голосі.
   4. 1.4Найвищий і найнижчий пояснюють свою логіку: зазвичай вони знають щось, чого не знають інші.
   5. 1.5Голосують знову. Зупиняються, коли картки близькі; якщо лишилися два сусідні значення, беруть більше й рухаються далі.
   6. 1.6Обмежте час: елемент, що не сходиться за два-три раунди, треба розділити або дослідити спайком, а не голосувати вчетверте.

Є дані, чому це працює. У 2008 році Kjetil Moløkken-Østvold, Nils Christian Haugen і Hans Christian Benestad дослідили норвезьку софтверну компанію й з’ясували: оцінки, до яких доходили в planning poker, були менш оптимістичними й точнішими за середнє з індивідуальних оцінок тих самих людей для тих самих задач. Обговорення знаходить роботу, про яку хтось забув. Сторінка про Scrum описує той самий ефект з іншого боку: 2 і 13 на одному елементі — це не арифметична суперечка, а два різні розуміння задачі.

Від пунктів до дати

Пункти стають датою через velocity — кількість пунктів, які команда справді завершує за спринт, виміряну за останні три-шість спринтів. Прогнозуйте діапазоном, а не середнім. Якщо останні шість спринтів дали від 24 до 35 пунктів, а лишилося 180, чесна відповідь — «від шести до восьми спринтів». Сказати «сім» означає викинути найкориснішу частину того, що ви знаєте.

Звідки взялися пункти — і роздуми згодом

Story points вийшли з Extreme ProgrammingExtreme Programmingagile-метод, що починається з інженеріїAgile-методологія кінця 1990-х, збудована навколо інженерних практик: розробка від тестів, парне програмування, безперервна інтеграція, рефакторинг і невеликі часті релізи. Від неї походить більшість того, що тепер називають технічною гнучкістю, і команда, яка переймає події Scrum без цих практик, зазвичай бачить, як її спринти сповільнюються.Усі терміни, з проєкту розрахунку зарплат Chrysler C3 наприкінці 1990-х. Рон Джеффріс розповідав, як це було. Спершу команда оцінювала в «ідеальних днях» — скільки займе робота в парі, якщо ніхто не заважатиме, — і множила на коефіцієнт навантаження близько трьох, щоб отримати реальний час, тож історія на три ідеальні дні забирала близько дев’яти. Пояснення, чому ідеальний день триває три справжні, збивало з пантелику всіх, тож ідеальні дні почали називати просто пунктами. У 2019 році Джеффріс написав: «Можливо, це я вигадав story points, і якщо так, то тепер шкодую». Його заперечення — не проти відносного розміру. Воно проти того, що з ним зробили організації: графіки velocity, які порівнюють між командами, і пункти, яких вимагають як результату.

П’ятий варіант: перестати оцінювати й рахувати

Тепер Джеффріс радить те, на чому весь час наполягав рух #NoEstimates, започаткований Вуді Зуіллом близько 2012 року: різати кожен елемент настільки дрібно, щоб його можна було завершити за день-два, а тоді прогнозувати, рахуючи елементи, замість додавати пункти. Коли елементи стабільно малі, їхня кількість прогнозує майже так само добре, як сума, а година суперечок «3 чи 5» повертається в розрізання. Це не відмова від прогнозу. Це прогноз за throughput — метод, який сторінка про Kanban описує з перцентилями й Monte CarloMonte Carloсимуляція багатьма випадковими прогонамиМетод, що відповідає на питання, проганяючи його тисячі разів із випадково взятими входами й читаючи розподіл результатів. На розкладі він замінює одну дату діапазоном і ймовірністю — чесною формою оцінки, складеної з двадцяти невизначених задач.Усі терміни, — а перехід Siemens Health Services 2012 року разом із числами описано на сторінці про Scrumban.

Людино-дні: зусилля в часі людей

Людино-день (MD, man-day або person-day) — це один день роботи однієї людини, зазвичай вісім годин. Це абсолютна одиниця зусиль, і в сервісних компаніях саме в ній рахують гроші: кошторис, пропозиція за fixed pricefixed priceузгоджений обсяг за узгоджену сумуКонтракт, у якому узгоджений обсяг віддають за узгоджену суму, тож вартість усього, що займе довше за план, несе виконавець. Саме тому fixed price приходить із найсуворішим контролем змін: будь-яка зміна обсягу є комерційною подією, а не лише плановою.Усі терміни, прайс ставок і рахунок за time and materialstime and materialsоплата за витрачені годиниКонтракт, у якому клієнт платить за фактично відпрацьований час, а не за фіксований обсяг, тож зміна напряму коштує грошей, а не перемовин. Ризик переходить до клієнта — тому ця модель приходить із більшою звітністю й важчою розмовою про те, що саме купили ці години.Усі терміни — усе в людино-днях або їхніх старших родичах. Людино-місяць — за домовленістю приблизно 20–21 робочий день, або близько 160–168 годин, залежно від країни й контракту.

Перша пастка в тому, що зусилля — це не тривалість. Двадцять людино-днів — це не чотири робочі тижні для однієї людини й не два тижні для двох. Це двадцять днів зосередженої роботи, які ще треба розкласти по календарю, повному зустрічей, рев’ю, відпусток і чергувань. Команди враховують це через фокус-фактор — частку робочого дня, що йде на заплановану роботу. Це число — локальний вимір, а не закон. Команда, яка закладає 0,8, а насправді працює на 0,6, запізнюється на третину ще до того, як хоч один рядок коду поведеться не так.

Чому люди не взаємозамінні

Друга пастка тонша, і в неї є назва. Фред Брукс керував розробкою IBM OS/360 і написав про здобутий досвід книжку «Міфічний людино-місяць» (1975). Людино-місяць, стверджував він, вважає людей і місяці взаємозамінними, а взаємозамінні вони лише для роботи, яку можна поділити так, щоб нікому ні з ким не треба було говорити. Софт — протилежність цьому. Кожну додану людину мусить увести в курс хтось, хто вже знає систему, а кожна пара людей — це ще одна лінія комунікації.

Кількість ліній росте як n(n−1)/2: у трьох людей їх три, у шести — п’ятнадцять, у дванадцяти — шістдесят шість. Звідси закон Брукса: додавання людей до проєкту, що запізнюється, змушує його запізнитися ще більше, бо новачки витрачають час тих, хто знає систему, ще до того, як дадуть хоч щось своє. У ювілейному виданні 1995 року Брукс визнав, що закон — обурливе спрощення, і все одно від нього не відмовився як від «найкращого наближення нульового порядку до істини». Для оцінки в людино-днях урок конкретний: сума MD не каже, яким буде календар, а більше людей скорочують його менше, ніж обіцяє арифметика.

Три числа замість одного

Стандартне виправлення одного оптимістичного числа — попросити три: оптимістичне (O), найімовірніше (M) і песимістичне (P). PERT, розроблений для програми Polaris ВМС США в 1958 році, зводить їх як (O + 4M + P) ÷ 6, із розкидом приблизно (P − O) ÷ 6. Формула важить менше, ніж питання, яке вона змушує поставити. «А як виглядав би поганий тиждень?» — це питання, якого оцінка одним числом не ставить ніколи.

Прочитайте таблицю двічі. Три найімовірніші значення в сумі дають 21 людино-день; очікуваний підсумок — 24,5, і ця різниця — та сама скошеність праворуч, що проступає назовні. А перші дві задачі мають однакове очікуване значення 6,0 за дуже різного ризику: звіти майже напевно займуть тиждень, інтеграція платежів може забрати майже три. Одне число зробило б їх однаковими.

Години: найдрібніше зерно

Години — це людино-дні в дрібнішому зерні, і вони правильна одиниця для одного типу роботи: малих, знайомих задач, що займають менше за пару днів. Розбити елемент спринту на задачі по дві-шість годин, виправити відомий тип бага, операційний тікет — у такому розмірі оцінка інженера в годинах зазвичай пристойна, бо він робив те саме нещодавно й може уявити кожен крок.

Понад цей розмір години стають хибною точністю. Оцінка в 340 годин для фічі претендує на точність близько одного відсотка щодо чогось, чий реальний діапазон на цьому етапі — двократний. Це число не точніше за «приблизно два місяці»; воно лише так виглядає, і кожен, хто додасть його до плану, успадкує точність, якої ніколи не було.

Чотири закони, що з’їдають оцінки в годинах

Разом вони пояснюють результат, що дивує нових менеджерів: запас безпеки на кожній задачі робить проєкти пізнішими, а не безпечнішими. Запас кожної задачі з’їдається локально — Паркінсоном і синдромом студента, — і жодна задача ніколи не повертає час: завершену раніше просто здають пізніше. Відповідь Голдратта в «Критичному ланцюзі» — прибрати запас з окремих задач і тримати його як один спільний буфер проєкту, що витрачається видимо й лише тоді, коли щось справді цього потребує.

Розміри T-shirt: порядок величини

Оцінка розмірами T-shirt розкладає елементи на кілька класів — XS, S, M, L, XL — замість давати їм числа. Це найгрубша з чотирьох одиниць, і в цьому її призначення: вона для етапу, на якому будь-що точніше було б вигадкою. Рядки роадмапу, епіки, портфель проєктів-кандидатів, перша розмова з клієнтом про те, скільки щось могло б коштувати.

Вона ще й швидка. В affinity estimation команда розкладає сорок-п’ятдесят елементів на стіні й мовчки сортує їх по стовпцях за розміром, а обговорює лише ті, які люди раз у раз пересувають. Беклог, на який пішов би день planning poker, оцінюється за годину — рівно з тією точністю, на яку заслуговує етап.

Кожен розмір має означати діапазон

Крок, який команди пропускають, — саме той, що робить розміри корисними: письмово домовитися, що кожен розмір означає в реальній одиниці. Без цього L однієї людини — це M іншої, і розміри не несуть жодної інформації нікому поза кімнатою. Діапазони нижче — приклад для однієї команди; ваші будуть іншими, і вони мають бути широкими.

Діапазони на кожному кроці приблизно подвоюються чи потроюються — з тієї ж причини, з якої в шкалі Фібоначчі є прогалини: чесний розмір стає менш точним, що він більший. А XL навмисно взагалі не розмір. Це позначка «ми поки знаємо замало», і корисна реакція на неї — робота, яка з’ясує, а не більше число.

Шість оцінок і те, що в них пропустили

Їх варто знати, бо кожну задокументовано публічно — самою організацією, у рецензованому дослідженні або в книжці, яку про це написав автор, — і бо кожна показує інший спосіб, у який оцінка йде не так. Жодна з них не про лінивих людей.

Де оцінювання перетворюється на театр

Оцінювання легко імітувати, не роблячи. Числа схожі на дані, церемонії — на старанність, і ніщо в ретельно заповненому полі оцінки не каже, чи змінило воно бодай одне рішення. Діаграма показує найпоширенішу форму цього театру.

Графік ілюстративний, а механізм — ні. VelocityVelocityскільки вміщується у спринтСкільки команда реально завершує за спринт, усереднено за кілька. Це допоміжна величина для планування однієї конкретної команди й нічого більше: порівнювати velocity двох команд чи ставити її за ціль означає надійно отримати роздуті оцінки, а не більше роботи.Докладніше в статті →Усі терміни — це власне число команди, яке дають власні оцінки команди. Зробіть його ціллю — і найдешевший спосіб його підняти буде оцінювати більше: нікому не треба брехати, трійки просто починають відчуватися як п’ятірки. Це закон Гудгарта в його звичному формулюванні: коли міра стає ціллю, вона перестає бути доброю мірою. Інші форми — варіації на ту саму тему.

• Пункти в трекері перетворюють на години, а тоді звітують угору так, ніби це години.
• Velocity порівнюють між командами або вписують у performance review.
• Оцінку торгують униз просто на зустрічі — «а може, це 3?», — щоб план уліз у дату.
• Оцінюють кожен елемент, включно з половиною беклогу, яку ніколи не будуватимуть.
• Завершені елементи переоцінюють угору, щоб спринт «влучив» у своє число.
• Клієнтові обіцяють одну дату з діапазону, який команда дала із застереженням, — а застереження ніхто не переслав.
• Оцінки в годинах порівнюють із залогованими годинами, людина за людиною.

І чесна межа. Жодна одиниця не виправляє того, через що оцінки софту хибні: роботу повністю знають лише тоді, коли її вже зроблено. Оцінювання зменшує похибку в тій частині, яку ви розумієте; воно нічого не робить із тією, якої ще ніхто не уявив, — а в даних Flyvbjerg саме там проєкти й помирають. Засоби проти цього — не техніки оцінювання. Це малі партії, щоб хибна оцінка коштувала тиждень, а не квартал; найризикованіша частина першою, щоб сюрприз прийшов, поки ще є час на нього відреагувати; і прогноз, який щоспринту складають наново з того, що справді сталося, замість обороняти те, що сказали на першому місяці.

Коли це застосовувати

Пов’язані сторінки

• МенеджментUser StoriesUser story — це короткий опис потреби з погляду користувача, написаний, щоб почати розмову, а не замінити її. Шаблон — найменш важлива частина; справжня навичка — нарізати роботу так, щоб кожна історія давала користувачеві щось справді придатне, і ще до початку роботи домовитися, як усі зрозуміють, що її зроблено. Сторінка починається з шістнадцяти історій у тому вигляді, як їх справді пишуть команди, — що не так із кожною і як її переписати; далі — картка, розмова й підтвердження, критерії приймання та example mapping, дев’ять способів розділити історію, story mapping, INVEST, спайки й поінти, п’ять епізодів з історії формату і де все це вироджується.
• МенеджментРизик-менеджментРизик-менеджмент — це рішення наперед про те, що може піти не так, на що з цього варто витратити гроші вже зараз і хто помітить, якщо воно почнеться. Ризик — це ще не проблема, і саме тому з ним дешево мати справу. Сторінка починається з повної карти — сім груп і двадцять вісім рядків, які можна звірити з власним проєктом, — а далі: як оцінити ризик без вдаваної точності, чотири відповіді, практики, які справді зрушують число, і шість публічних провалів із контролем, якого в кожному бракувало.
• МенеджментKanbanKanban — це спосіб керувати роботою, який починається з наявного процесу й покращує його, обмежуючи незавершену роботу й вимірюючи, як вона тече. Він не додає ні ролей, ні спринтів. Сторінка починається з усіх елементів Kanban-системи на одному екрані — що команда записує і як виглядає відсутність кожного; далі — чому дошка сама по собі ще не Kanban і хто визначає метод, шість принципів і шість практик, чотири метрики потоку й арифметика під ними, прогноз з історії замість оцінок, сім ритмів, пʼять задокументованих випадків і де все це вироджується.