Оценка за мобилни проекти — какво е това, методи за оценка на задачи

Какво е оценка?

Оценка (от англ. estimate — оценка) — прогнозиране на количеството време или усилия, необходими за изпълнение на задача. В мобилната разработка оценките се изразяват в часове, дни, story point-ове или паричен еквивалент. Целта на оценката не е точно предвиждане, а намаляване на несигурността за вземане на решения.

Как оценката се различава от ангажимента

Оценка — прогноза с марж на грешка. Ангажимент (commitment) — обещание да се изпълни задача до определена дата. Разликата е критична: оценката казва „вероятно 5 дни„, ангажиментът — „ще го направим за 5 дни„. Мениджърите често бъркат тези понятия, превръщайки оценката в краен срок без право на грешка.

Оценката като комуникационен инструмент

Процесът на оценяване е също толкова важен, колкото и резултатът от него. Когато екипът обсъжда оценката на задача, се разкриват скрити изисквания, зависимости и рискове. Дори ако крайната цифра е неточна, дискусията дава на всички участници разбиране за задачата. Затова колективните методи за оценка (Planning Poker) са по-ефективни от индивидуалните.

Методи за оценка в разработката

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

Planning Poker

Planning Poker — най-популярният метод за оценка в Agile. Всеки разработчик получава тесте карти с числа на Фибоначи (1, 2, 3, 5, 8, 13, 21). След обсъждане на задачата всички едновременно показват картата си. Ако оценките се разминават — разработчиците с минимална и максимална оценка обясняват своята логика, след което следва повторно гласуване. Методът елиминира влиянието на авторитетите и дава по-точна оценка.

T-Shirt sizing

T-Shirt sizing — груба оценка по размер на тениска: XS, S, M, L, XL, XXL. Методът се използва за бърза оценка на големи задачи (епици) в ранни етапи, когато детайлите не са известни. По-късно всяка такава задача се декомпозира и оценява в Planning Poker. T-Shirt sizing отнема 5-10 минути на задача, но дава само порядък на големината.

Three-point estimation (PERT)

PERT използва три оценки: оптимистична (O), песимистична (P) и най-вероятна (M). Крайната оценка се изчислява по формулата: (O + 4M + P) / 6. Методът отчита несигурността и дава по-реалистичен резултат от единична оценка. PERT е особено полезен за задачи с високи рискове или нови технологии.

Точност на оценката: очаквания vs реалност

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

Конус на несигурността

Конус на несигурността (Cone of Uncertainty) — модел, който описва как маржът на грешка на оценката намалява с напредването на проекта. На етапа на концепция маржът на грешка е 400% (задачата може да отнеме от 1 до 4 месеца). В момента на спринта — 20% (1-1.2 месеца). Осъзнаването на този модел помага да не се изискват точни оценки в ранните етапи.

Фактори, влияещи върху точността

• Сложност на задачата — нова технология или позната? Неизвестното увеличава грешката 2-3 пъти.
• Размер на задачата — малките задачи (до 2 дни) се оценяват по-точно от големите. Декомпозицията подобрява точността.
• Опит на екипа — екип, работил заедно 6+ месеца, оценява 30-50% по-точно от нов екип.
• Исторически данни — наличието на метрики velocity и циклометрия повишава точността на прогнозите.

Относителна vs абсолютна оценка

Относителната оценка (в story point-ове) е по-точна от абсолютната (в часове), защото хората сравняват задачи по-добре, отколкото оценяват време. „Тази задача е два пъти по-сложна от онази„ — по-надеждна преценка от „тази задача ще отнеме 8 часа„. Относителните оценки не зависят от конкретния разработчик и запазват точността си при смяна на изпълнителя.

Как да подобрим точността на оценката: най-добри практики

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

Декомпозиция до 1-2 дни

Всяка задача, оценена на повече от 2 дни, трябва да бъде декомпозирана на подзадачи. Принцип: ако задачата не може да бъде оценена с 50% точност, значи е твърде голяма. Разделете я на стъпки, които са разбираеми и оценими. След декомпозиция общата оценка често е 1.5-2 пъти по-голяма от първоначалната.

Исторически данни и метрики

Водете история на оценките и сравнявайте с действителните разходи. Например: „задачите, оценени на 3 story point-а, средно отнемат 4 дни, а не 2„. Използвайте velocity на екипа за прогнозиране: ако екипът затваря 20 story point-а на спринт, не планирайте 30. Анализът на точността на предишни оценки е най-доброто обучение за умението за оценяване.

Закотвяне и калибриране

Закотвяне — психологически ефект, при който първата изказана оценка влияе на всички участници. За да избегнете закотвяне, в Planning Poker всички показват картите едновременно, а не последователно. Калибриране — редовна сверка на оценките с реалността: след 10-20 спринта екипът се научава да оценява по-точно благодарение на обратната връзка.

Отчитане на рисковете в оценката

Всяка задача съдържа скрити рискове: заболяване на разработчик, проблем с API, промяна на изискванията. Добавете коригиран спрямо риска фактор към оценката: за задачи с висок риск — множител 1.5-2, с нисък — 1.1-1.2. Прозрачно покажете на клиента какви рискове са отчетени и как те влияят на сроковете.

Типични грешки при оценяване

Грешките при оценяване се повтарят в повечето екипи, независимо от тяхната зрялост. Познаването на тези грешки е първата стъпка за тяхното коригиране.

Оптимистична оценка

Най-честата грешка — оценка по най-добрия сценарий: „ако всичко върви идеално, ще го направим за 3 дни„. В действителност нищо не върви идеално: грешки, въпроси относно изискванията, зависими задачи. Решение: оценявайте по най-вероятния сценарий, а не по оптимистичния. Използвайте PERT за отчитане на вариативността.

Оценка под натиск

Когато мениджърът каже „трябва до петък„, разработчикът подсъзнателно коригира оценката спрямо този срок. Оценката под натиск винаги е занижена и води до забавяне. Решение: оценката трябва да предхожда крайния срок, а не обратното. Първо екипът оценява, след това страните се договарят за сроковете.

Объркване между сложност и време

Сложност на задачата (колко да мислим) и време (колко да правим) — различни метрики. Една задача може да бъде проста, но времеемка (кодиране на 10 екрана). Или сложна, но бърза (намиране на грешка в legacy). В story point-овете обикновено се оценява сложността, а времето се извлича от velocity-то на екипа.

Игнориране на контекстни превключвания

Разработчикът не работи 8 часа непрекъснато по една задача: срещи, code review, помощ на колеги, административни задачи отнемат 30-50% от работното време. Контекстните превключвания трябва да бъдат отчетени в оценката: реално разработчикът пише код 3-4 часа на ден.