Метрики: Velocity, Throughput и Cycle Time
Разберете защо Throughput и Cycle Time дават много по-ясна представа от Velocity, помагайки на вашия Scrum екип да открива тесните места и да прогнозира доставките с по-голяма точност.
Повечето инженерни организации измерват грешните неща, защото story points звучат научно. Когато мениджърите гледат числа, екипите започват да оптимизират самите числа, вместо да доставят работещ софтуер. Velocity, Throughput и Cycle Time са трите най-често използвани метрики за проследяване на работата, но те измерват принципно различни неща. Само две от тях реално ви помагат да доставяте стойност по-бързо.
Проблемът с Velocity
Story points са относителни оценки, създадени от един конкретен екип за целите на планирането на спринта. Scrum Guide никога не споменава story points или velocity. Той просто изисква от Developers да оразмерят елементите, за да могат да прогнозират какво може да бъде свършено в рамките на един Sprint. Когато ръководството третира Velocity като метрика за производителност, се стига до инфлация на оценките. Екип, който е доставил 20 точки в миналия Sprint, ще оцени задача от пет точки като задача от осем точки в настоящия Sprint. Нищо не се движи по-бързо, но графиката върви нагоре.
Velocity е инструмент за вътрешна калибрация на отделна група, а не външна мярка за резултатност. Тя не може да се сравнява между различни екипи, защото всеки екип измисля своя собствена скала. Още по-лошото е, че фокусът върху Velocity насърчава екипите да поемат големи обеми работа наведнъж, за да поддържат високи числа. Това увеличава риска и забавя обратната връзка.
Защо Throughput работи по-добре
Throughput измерва броя завършени работни елементи за единица време, например завършени задачи за седмица или за Sprint. Тази метрика не се интересува от story points. Поправката на бъг се брои за едно, а преработеният разплащателен модул също се брои за едно. Зачитат се единствено елементи, които покриват Definition of Done.
Броенето на отделни елементи може да звучи първично, докато не се вгледате в математиката. В разработката на софтуер разликите в размера на задачите имат много по-малко значение от разликите в дължината на опашките и забавянията. Когато екипите разделят потребителските истории на малки, логически обособени части от стойност, броят завършени елементи осигурява прогнози, които съвпадат с или превъзхождат оценките, базирани на story points. Това също така елиминира продължителните спорове дали дадена задача е три или пет точки.
Cycle Time показва къде блокира работата
Cycle Time проследява колко време отнема даден елемент от момента, в който работата по него започне, до момента, в който той покрие Definition of Done. Ако програмист започне да пише код в понеделник и функционалността стигне до продукция в четвъртък следващата седмица, Cycle Time е девет работни дни.
За разлика от Velocity, Cycle Time посочва директно триенето във вашия процес на доставка. Високите стойности на Cycle Time рядко идват от бавно писане на код. Те се дължат на работа, която чака по опашки: чакане за преглед на кода, чакане за тестване или чакане за внедряване в тестова среда. Ако искате да завършвате работата по-бързо, разгледайте разпределението на вашия Cycle Time, вместо да изисквате от хората да работят по-усилено.
Изграждане на по-добър навик за измерване
Не са ви необходими сложни табла с метрики, за да разберете напредъка си. Ако искате здрав процес на доставка, следете три практични показателя:
- Лимити за работа в процес, за да се предотвратят тесните места и Cycle Time да остане нисък.
- Cycle Time на 85-ия персентил, за да предоставяте реалистични прогнози за завършване пред заинтересованите страни.
- Throughput за Sprint, за да разбирате реалния капацитет без игри с точкуване на оценките.
Scrum Guide ни напомня, че целта на всеки Sprint е да създаде ценен, полезен Increment, който покрива Definition of Done. Velocity показва колко работа сте смятали, че вършите. Throughput и Cycle Time показват какво реално е свършено и колко време е отнело достигането до резултата.