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 сп.

Прогнозирање путем velocity-ја

Знајући velocity и укупан обим беклога у story поинтима, може се прогнозирати број спринтова до издања. На пример, ако је у беклогу 210 story поинта, а velocity = 21, потребно је 10 спринтова. Ово је груба прогноза која се прецизира током рада. Важно: velocity је просек, а не обавеза. Планирајте по доњој граници (18 сп), а не по просеку.

Како повећати velocity

Velocity се не може повећати наредбом — то је симптом здравља процеса. Одрживи раст velocity-ја се постиже кроз: смањење техничког дуга, побољшање процеса code review-а, смањење контекстних прекида, аутоматизацију тестирања и CI/CD. Важно: velocity различитих тимова се не може поредити — сваки тим дефинише story поинте на свој начин.

Story поинти vs сати: шта и када користити

Story поинти и сати имају различите циљеве, а избор између њих зависи од контекста. Искусни тимови користе оба приступа за различите задатке.

Када story поинти раде боље

Story поинти су незаменљиви за планирање спринтова: не зависе од тога ко ће радити задатак. Junior може да уради 2 сп дневно, senior — 4 сп, али процена задатка остаје 2 сп за обојицу. Story поинти омогућавају праћење тимске продуктивности без поређења програмера. Ово смањује политички притисак и побољшава атмосферу у тиму.

Када су сати неопходни

Сати су потребни за спољне обавезе: уговори, предрачуни, извештаји за клијента. Клијент жели да зна не „8 story поинта”, већ „3 недеље”. За конверзију story поинта у сате користи се historical conversion rate: тим зна да је 1 сп = приближно 4 сата рада. Конверзија мора бити транспарентна и заснована на подацима, а не на претпоставкама.

Комбиновани приступ

Многи тимови користе комбиновани приступ: задаци се процењују у story поинтима за планирање спринта, а затим менаџер их конвертује у сате/дане за спољно извештавање. Важно је не мешати два система у једном процесу: или процењујете у story поинтима и изводите време из velocity-ја, или процењујете директно у сатима.

Типичне грешке при раду са story поинтима

Увођење story поинта често прати грешке које поништавају предности релативне процене. Ево најчешћих од њих.

Везивање story поинта за време

Најчешћа грешка — тим договара: „1 сп = 4 сата”. У овом случају story поинти губе смисао и претварају се у сате под другим именом. Story поинти морају бити релативни, невезани за време. Ако је задатак А двоструко сложенији од задатка Б, добија 2 сп, без обзира на то колико сати ће трајати.

Процена post-factum

Када се задатак процењује након његовог извршења — то није процена, већ констатација. Story поинти морају бити додељени пре почетка рада, у тренутку максималне несигурности. Процена post-factum изобличује velocity и не доноси корист за планирање. Штавише, ствара лажни осећај прецизности.

Поређење velocity-ја различитих тимова

Поређење velocity-ја тима А и тима Б — бесмислена вежба. Сваки тим дефинише референцу и размеру на свој начин. За један тим 1 сп је једноставан задатак за сат времена, за други — за дан. Може се поредити само velocity истог тима у динамици: расте или опада.

Неконзистентна скала

Када различити задаци са истом сложеношћу добијају различите story поинте, а сложенији — мање, скала се руши. Тим мора редовно калибрисати скалу: сваких 3-6 спринтова ретроспективно проверавати колико су процене одговарале стварној сложености. Ово побољшава конзистентност процена.