Трябва ли да оценяваме бюджета на Agile проектите?

Много хора смятат, че да се оценяват разходите и да се съставя бюджет за Agile проектите е безмислено и даже контрапродуктивно. Има дори цяло движение #NoEstimates. В края на краищата, не е ли оценяването на разходите против принципите на Agile, тъй като те не могат да бъдат определени предварително? Проектът ще бъде завършен, когато бъде завършен и когато клиентът хареса резултата. И тогава може би ще разберем колко ни е струвал.​

Традиционно, в Agile проектите, които използват Scrum (и в Agile има традиционни неща :), обемът на работата се измерва в Story Points. Това са относителни, а не абсолютни измерители на обема на работата по проекта.

More...

Броят на точките не зависи от скоростта на работата (производителността) на отделните членове на екипа. Ако те се съгласят, че една задача е с обем 10 Story Points, някои от тях могат да я свършат за два дни, други за четири дни. Но ако се съгласят, че друга задача е с обем 20 Story Points, това означава, че същите хора смятат, че могат да я свършат съответно за четири и за осем дни. По този начин, екипът калибрира своята скала за относителна оценка и може да оцени обема на работата на един проект, пропорционално на обема на друг проект.

Но това не означава, че точките са равнозначни на обема на работата в човекочасове и на разходите, определени на база човекочасовете и часовата ставка. Всъщност, Story Points не са замислени като средство за оценка на разходите на проекта.

Сега да се върнем на въпроса. Всъщност има два въпроса:

           1. Трябва ли за оценяваме разходите на Agile проектите?

           2. Можем ли да оценим разходите на Agile проектите?

Да започнем с първия въпрос. Има два случая, в които трябва да оценим разходите на проекта и Agile проектите не правят изключение.

Първо, трябва да го правим, когато работим за външен клиент. Нали не искаме да работим на загуба? Следователно, трябва да знаем какви ще бъдат нашите разходи. Разбира се, може да се договорим клиентът да плаща на база на реално отработени човекочасове (или на друг подобен принцип) и тогава сме застраховани от загуба. Но не всеки клиент би се съгласил на този подход и със сигурност никой клиент няма да се съгласи да поеме безлимитен ангажимент по отношение на разходите.

Второ, трябва да оценяваме разходите, когато тази оценка е необходима за вземане на управленско решение. Най-общо, когато искаме да знаем дали проектът е изгоден и за целта сравняваме прогнозните ползи с прогнозните разходи на проекта. Тук важи общото правило (което не е отменено дори за Agile проектите :), че ползите трябва да бъдат по-големи от разходите. Ако очакваните ползи са по-малки от очакваните разходи, какъв е смисълът от проекта?

Ползи от Agile проекта > Разходи за Agile проекта

В повечето случаи, измерваме ползите в пари и за да има сравнимост, трябва да измерим и разходите в пари (а не в Story Points). Има случаи, в които ползите могат да бъдат измерени и по друг начин – в здраве, човешко щастие, по-добра околна среда и т.н. Тогава не е задължително да измерваме разходите в пари, за да преценим дали проектът е изгоден. Ако 1 Story Point води до повишаване на Индекса на човешкото щастие с поне 1 процентен пункт (и в случая човекът е Спонсорът на проекта), то това е страхотен проект!

Но нека не прекаляваме. По-сигурни транзакции, по-доволни клиенти, по-надеждна информация, по-бърза работа и други подобни, са хубави неща, но не дотолкова, че да не се стремим да ги оценим в пари. Ако искаме да имаме реална оценка за ползата от проекта, ще трябва да оценим и разходите.

Нека сега да разгледаме втория въпрос - можем ли да оценим разходите на Agile проектите?

А защо да не можем?

    • Защото тези проекти са гъвкави (и следователно могат да поемат в една или друга посока)
    • Защото включват изисквания, които се променят и еволюират

Съгласен съм, че е много трудно и често безсмислено, да се опитваме да направим оценка на разходите „отдолу нагоре“, т.е. да оценим разходите за извършване на отделните задачи и да ги агрегираме в общ бюджет на проекта.

Но можем да прилагаме оценка „отгоре надолу“, като подходът тук не е по-различен от този при всички иновативни проекти:

    • Можем да сравним нашия проект с други предишни подобни проекти, за чиито разходи имаме информация (да направим бенчмаркинг)
    • Ако имаме информация за действителните разходи на предишни наши Agile проекти, можем да получим прогнозни разходи за нашия нов проект, като приложим съотношението на Story Points за двата проекта (ако оценките са дадени от един и същ екип или по-точно казано, от екипи, калибрирани с еднакъв мащаб на оценката)
    • Можем да използваме параметричен модел за оценка на разходите на проекта
    • И ако нищо друго не можем да направим, поне можем да направим експертна оценка на разходите :), на базата на нашия опит и умения

Основната разлика в резултатите от оценката на разходите „отдолу нагоре“ и „отгоре надолу“ е в точността. Следователно, оценката на разходите на Agile проектите е напълно възможна, но трябва да се задоволим с по-малка степен на точност. Можем да приемем, че точността, която можем да постигнем, е не по-малка от точността при концептуална оценка на разходите на проекта: от -25% до +75%.

Ако най-вероятната оценка на разходите на Agile проекта е 300 000 лв. и нашата оценка за точността е -25%/+75%, то реалните разходи биха могли да варират в диапазона 225 000 лв. – 525 000 лв. Точността на оценката на разходите се отразява на резерва към бюджета на проекта. В този случай към бюджета на проекта от 300 000 лв. добавяме резерв от 225 000 лв., за да получим общ бюджет от 525 000 лв.

Ако очакваните ползи от проекта са в размер на 550 000 лв., то в най-добрият случай нетните ползи биха били 325 000 лв. (550 000 – 225 000), в най-вероятният случай биха били 225 000 лв. (550 000 – 300 000), а в най-лошия минус 25 000 лв. (550 000 - 525 000).

Но ако очакваните ползи са 320 000 лв., проектът може да донесе загуба до 205 000 лв. (525 000 – 320 000). Бихте ли започнали този проект?

В най-вероятната стойност на разходите на Agile проекта трябва да бюджетираме всички най-вероятни итерации (последователни подобрени версии) на продукта на проекта, с най-вероятните усилия за тези итерации. Резервът ще отиде за евентуални по-големи усилия за планираните итерации и за евентуални допълнителни итерации.

ЗАКЛЮЧЕНИЕ

Прогнозните разходи в Agile проектите могат да бъдат оценени, макар и с по-малка степен на точност. Такава оценка е необходима, за да определим нетните ползи на проекта и да преценим дали проектът има смисъл.

А какво мислите вие?​

​Автор: Александър Апостолов


Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *