Story точки в разработката — какво е, скали за оценка и приложение

Какво са story точките?

Story точките — са метрика за сложност на задачата, използвана в Scrum и други Agile методологии. Екипът оценява всяка задача не в часове, а в относителни единици: „тази задача е два пъти по-сложна от еталонната”. Този подход неутрализира разликата в скоростта на различните разработчици и се фокусира върху сложността.

Произход на термина

Понятието story точка възниква в началото на 2000-те години заедно с популяризирането на Scrum. Един от първите, описали метода, е Рон Джефрис в рамките на Extreme Programming (XP). Идеята е да се отдалечим от оценката в „човеко-часове”, която винаги е неточна, към относителна сложност, която екипът определя колективно. Днес story точките са индустриален стандарт за Agile екипи.

Фактори, взети предвид в story точките

При оценка в story точки, екипът взема предвид три фактора: обем на работа (количество код, екрани, логика), сложност (технически предизвикателства, нови технологии) и несигурност (неясни изисквания, рискове). Една story точка може да означава „проста задача без рискове”, а 8 — „сложна задача с висока несигурност”.

Скали за story точки: как да избираме

Изборът на скала за story точки влияе върху точността на оценката и удобството на планирането. Най-популярната скала е редицата на Фибоначи, но има и алтернативи.

Защо Фибоначи? Психология на скалата

Редицата на Фибоначи не е избрана случайно. Разликата между 1 и 2 е минимална (50%), а между 13 и 21 — значителна (62%). Това отразява реалността: малките задачи се оценяват по-точно, големите — с по-голямо разсейване. Когато задача бъде оценена на 21 story точки, екипът разбира: „не знаем колко време ще отнеме, но със сигурност повече от 13”. Скалата на Фибоначи предотвратява фалшива точност.

Еталонна задача — основа на скалата

За да работи скалата, екипът договаря еталон: „задача X — 1 story точка”. Обикновено за еталон се избира проста, добре позната задача: „добавяне на текстово поле на екрана” или „поправка на бъг от тип печатна грешка”. Всички останали задачи се оценяват спрямо еталона. Без еталон story точките губят смисъл — всеки разбира единицата по свой начин.

Velocity на екипа и прогнозиране

Velocity (скорост на екипа) — средният брой story точки, които екипът затваря за един спринт. Това е ключова метрика за прогнозиране на сроковете на проекта.

Как се изчислява velocity

Velocity се изчислява на база завършени задачи: сумират се story точките на всички задачи, които екипът е успял да довърши (definition of done е изпълнен). Незавършените задачи не се вземат предвид. За точност се взема средната стойност от последните 3-5 спринта. Например, ако екипът е затворил 20, 22, 18 и 24 story точки за последните 4 спринта, velocity = 21 sp.

Прогнозиране чрез velocity

Познавайки velocity и общия обем на backlog в story точки, може да се прогнозира броят спринтове до пускане. Например, ако в backlog има 210 story точки и velocity = 21, необходими са 10 спринта. Това е груба прогноза, която се прецизира в хода на работата. Важно: velocity е средна стойност, а не задължение. Планирайте по долната граница (18 sp), а не по средната.

Как да повишим velocity

Velocity не може да бъде повишено със заповед — това е симптом на здравето на процесите. Устойчивото повишаване на velocity се постига чрез: намаляване на техническия дълг, подобряване на процесите за code review, намаляване на контекстните превключвания, автоматизиране на тестването и CI/CD. Важно: velocity на различни екипи не може да се сравнява — всеки екип дефинира story точките по свой начин.

Story точки vs часове: какво и кога да използваме

Story точките и часовете имат различни цели и изборът между тях зависи от контекста. Опитните екипи използват и двата подхода за различни задачи.

Кога story точките работят по-добре

Story точките са незаменими за планиране на спринтове: те не зависят от това кой ще изпълнява задачата. Junior може да прави 2 sp на ден, senior — 4 sp, но оценката на задачата остава 2 sp и за двамата. Story точките позволяват проследяване на екипната производителност без сравняване на разработчици. Това намалява политическия натиск и подобрява атмосферата в екипа.

Кога часовете са необходими

Часовете са необходими за външни задължения: договори, бюджети, отчети за клиента. Клиентът иска да знае не „8 story точки”, а „3 седмици”. За конвертиране на story точки в часове се използва historical conversion rate: екипът знае, че 1 sp = приблизително 4 часа работа. Конвертирането трябва да бъде прозрачно и базирано на данни, а не на предположения.

Комбиниран подход

Много екипи използват комбиниран подход: задачите се оценяват в story точки за планиране на спринта, след което мениджърът ги конвертира в часове/дни за външно отчитане. Важно е да не смесвате две системи в един процес: или оценявате в story точки и извличате времето от velocity, или оценявате директно в часове.

Типични грешки при работа със story точки

Внедряването на story точки често е придружено от грешки, които анулират предимствата на относителната оценка. Ето най-честите от тях.

Обвързване на story точките с времето

Най-честата грешка — екипът договаря: „1 sp = 4 часа”. В този случай story точките губят смисъл и се превръщат в часове под друго име. Story точките трябва да бъдат относителни, непривързани към време. Ако задача А е два пъти по-сложна от задача Б, тя получава 2 sp, независимо от колко часа ще отнеме.

Оценка post-factum

Когато задачата се оценява след нейното изпълнение — това не е оценка, а констатация. Story точките трябва да бъдат определени преди започване на работа, в момента на максимална несигурност. Оценката post-factum изкривява velocity и не носи полза за планирането. Освен това създава фалшиво усещане за точност.

Сравняване на velocity на различни екипи

Сравняването на velocity на екип А и екип Б — безсмислено упражнение. Всеки екип дефинира еталона и скалата по свой начин. За един екип 1 sp е проста задача за час, за друг — задача за ден. Може да се сравнява само velocity на един и същ екип в динамика: расте или пада.

Непостоянна скала

Когато различни задачи с еднаква сложност получават различни story точки, а по-сложните — по-малко, скалата се разрушава. Екипът трябва редовно да калибрира скалата: на всеки 3-6 спринта ретроспективно да проверява доколко оценките съответстват на реалната сложност. Това подобрява последователността на оценките.