Сторі пойнти: як це працює
Скільки зусиль потрібно на задачу? В умовах невизначеності й труднощів вимірювати відповідь на це питання годинами було б неправильно. Значно краще використовувати відносні одиниці, найвідоміші з яких – сторі пойнти. Ми переклали для вас статтю Майка Кона про те, які фактори потрібно враховувати при оцінці роботи в сторі пойнтах і як узгоджувати ці фактори між собою. Бонусом даємо перелік типових помилок у застосуванні сторі пойнтів.
Сторі пойнти: як це працює
Сторі пойнтами вимірюємо зусилля, потрібні для виконання елементу беклога продукту чи будь-якого іншого відрізка роботи.
Користуючися сторі пойнтами, ми привласнюємо кожному елементу роботи кількісне значення. Ці оцінки неважливі самі по собі. Має значення лише те, як оцінки різних елементів співвідносяться одна з одною. Історія зі значенням 2 має бути вдвічі більшою за історію зі значенням 1 і мати приблизно дві третини складності історії зі значенням 3.
Замість одиниці, двійки і трійки, команда могла б використовувати числа 100, 200 й 300. Або ж 1 мільйон, 2 мільйони, 3 мільйони. Важливе співвідношення чисел, а не самі числа поза ним.
Що включає сторі пойнт?
Оскільки сторі пойнти позначають зусилля, необхідні для реалізації історії, команда має оцінити все, що вплине на ці зусилля. Це може бути:
- обсяг роботи;
- складність роботи;
- ризики або невизначеність.
Вимірюючи роботу в сторі пойнтах, обов’язково оцініть кожен із цих факторів.
Об’єм роботи
Чим більше роботи потрібно виконати, тим, очевидно, більшим має бути умовний показник зусиль. Візьмемо для прикладу розробку двох веб-сторінок. На одній має бути одне поле і прохання ввести ім’я. На іншій має бути сто полів для введення тексту.
Друга сторінка не складніша за першу. Вона не передбачає взаємодії між полями, їх потрібно заповнювати тільки текстом. Її розробка не пов’язана з ризиками. Єдина відмінність цих сторінок — у тому, що на другій треба буде додати більше полів.
Другій сторінці доведеться дати більше сторі пойнтів. Але не в сто разів більше (хоч на ній і міститиметься у сто разів більше полів). Не треба забувати про ефект масштабування: в реальності ми можемо витратити на другу сторінку вдвічі, втричі або ж у десять разів більше зусиль, ніж на першу.
Ризики й невизначеність
Їх також потрібно включати в оцінку. Наприклад, команді потрібно оцінити елемент беклогу, про який зацікавлена особа (стейкхолдер) не може сказати нічого конкретного. Або ж інша ситуація, коли потрібно визначити націнку там, де додавання нової фічі потребує переписування старого, ненадійного коду без автотестів.
Невизначеність як така показана вже в самій послідовності чисел для сторі пойнтів, що нагадує ряд Фібоначі: 1, 2, 3, 5, 8, 13, 20, 40, 100. Яке б число ряду ви не обрали, в ньому вже закладено опосередковану невизначеність.
Складність
Згадайте про нашу сторінку зі ста полями, між якими немає взаємодій.
А тепер уявімо іншу сторінку зі ста полями. Частина з них – поля з датами й, відповідно, календарними віджетами. В іншій частині можна вводити лише обмежену кількість символів: наприклад, номери телефонів. Є поля, де перевіряється контрольна сума (наприклад, поля з номерами банківських карток). Є взаємодії між полями. Для карти Visa сторінка має видавати поле з тризначним CVV-кодом, а для карти American Express – з чотиризначним.
І хоч на екрані досі сто полів, та розробка буде складнішою, тобто займе більше часу. Зростає ймовірність того, що розробник помилиться, якісь з оновлень доведеться скасувати й переробити заново.
Враховуйте усі ці фактори
Часом здається, що показати всі три фактори одним числом нереально, але це не так. Їх об’єднує фактор зусиль, які потрібно витратити на роботу.
Оцінюючи, ми спершу рахуємо, скільки зусиль займе кожен елемент Беклогу. Потім додаємо до цих зусиль вплив ризику. Для цього озвучуємо ризики і їх вплив. Наприклад, елементу з вищим ступенем ризику, особливо якщо він потребує виконання більшого обсягу роботи, треба привласнити більше сторі пойнтів, ніж елементу, з яким проблеми можуть і не виникнути.
І нарешті, додаємо складність. Вона може потребувати більше зусиль для осмислення, спроб і помилок, комунікації з замовником, перевірки й часу на виправлення помилок.
Зверніть увагу на Definition of Done (визначення готового)
Оцінка в сторі пойнтах має враховувати все необхідне для приведення елементу беклогу в стан готовності. Якщо визначення готового в команді містить результати автотестів для перевірки історії (а це цілком непогано), то оцінка має включати і зусилля, витрачені на написання тестів.
Типові помилки
- Сторі пойнти не потрібно зводити тільки до складності, невизначеності чи об’єму роботи.
- Сторі пойнти не треба переводити в години – це стане причиною додаткових незгод при оцінюванні.
- Потрібно уникати усереднених значень (наприклад, коли одна половина команди оцінює елемент на 3 сторі пойнти, а друга – на 5). Якщо виникає дискусія, краще стати на бік більшого показника.
- Ніколи не міняйте оцінку під час спринту, навіть якщо вона некоректна. Вона знадобиться потім для об’єктивних спостережень за швидкістю роботи.
- Не забувайте оцінювати баги – звісно, якщо в команди немає фіксованого відсотка часу на прибирання багів.
- Не привласнюйте сторі пойнти надто мілким завданням (наприклад, чотиригодинному аналізу) – для них буде достатньо таймбоксів.
- Не міняйте оцінку ключових елементів беклогу в кожному окремому спринті. Це завадить вам порівнювати результати спринтів, тоді як основна мета існування сторі пойнтів – якраз таке порівняння.
- Якщо в новий спринт перейшла робота з минулого, не потрібно повторно її оцінювати: по-перше, ви вже знаєте її тривалість в годинах, а по-друге, вона потім вплине на швидкість (velocity) команди.
- Не підлаштовуйте оцінку в сторі пойнтах під окремого розробника.
- Якщо склад команди змінився, оцінки потрібно переналаштувати.
- Не підлаштовуйтесь під оцінку найдосвідченішого фахівця, присутнього на нараді.
Не забувайте обговорювати неадекватні оцінки на ретроспективі.
Перекладено й адаптовано командою BrainRain за матеріалами:
