Съдържание:
- Въведение
- Моделът на гадателката
- Анализ на функционални точки (FPA)
- Става пъргав
- Заключение
- Бърза анкета
оценка на софтуерен проект
Pixabay
Въведение
Оценката е просто трудна. За съжаление също е много необходимо. Компаниите използват прогнози, за да изготвят графици за пускане, да поемат ангажименти към своите клиенти, да решат дали дадена функция си струва да бъде приложена, да проследяват скоростта на екипите и да приоритизират ефективно работата. Ръководителите често искат да знаят кога дадена функция или продукт ще бъде готов за производство. В крайна сметка разработването на софтуер не е маловажна инвестиция. Без оценки как ръководителят на проекта ще направи оценка? Ако хората можеха да предскажат точно бъдещето, хората нямаше да печелят на конни надбягвания 2% от времето. Оценката е голямата загадка. От съществено значение и необходимо е компаниите да помолят хората си да направят невъзможното: да предскажат бъдещето.
Първо, нека прегледаме някои популярни методи за оценка (в случай, че сте пропуснали част от вълнението). Тогава можем да разгледаме какво означава това за нас и нашите проекти.
Моделът на гадателката
Този модел не изисква почти никакви усилия за изготвяне на оценка. Оценителите помислят за малко какво трябва да се направи, за да се приложи и тества дадена функция, след което изхвърлят число. Звучи много като „… (дълга пауза)… Ъмммм… 6 седмици.“ Тогава всички кимват и ние продължаваме напред. Те биха могли да прекарат доста време на предния край, като говорят какво знаят за изискванията (което вероятно не е пълната картина). Този внимателен анализ прави оценката им по-надеждна. В края на проекта винаги има приета обосновка защо оценката е била толкова далеч от реалността. Винаги има непредвидени обстоятелства, които могат да служат като изкупителна жертва. Често на никого не му хрумва, че моделът е сериозно опорочен.
И така, как можем да подобрим този процес? Знам! Можем да използваме Техниката на разлагане (т.е. разделяй и владей). Този подход предполага, че знаете пълния обхват на функцията или проекта на предния край. Всяка функция е разделена на парчета с размер хапка. Всеки парче се оценява (стил на гадател), след което ги събираме, за да получим цялостна оценка на характеристиките / проекта. Това със сигурност е по-сложен подход, но изглежда по-добър поради две причини:
- По-малките парчета работа са по-лесни за надеждно оценяване.
- Въпреки че все още има възможност за грешка (+/- някаква сума), има предположение, че грешките ще се отменят взаимно, когато съберете всичко и ще получите по-надеждна обща оценка.
Основният недостатък на този подход е, че отделните донори (хората, които действително вършат работата) универсално подценяват. Те все още са значително по-добри от тези над тях и около тях, но това не е висока летва. Това не изглежда така, защото всички сме виждали случаи, в които разработчиците са се изненадвали, като са постигнали нещо преди графика. Но това е единична точка от данни, а не тенденция. Хората всъщност печелят от време на време в казиното; харчете пари в казино всеки ден в продължение на една година и ще имате по-малко пари, отколкото сте започнали. Ако проследявате оценките спрямо действителните за година или две, ще откриете, че оценките наистина не отговарят на реалността. Докато много бизнесмени са абсолютно сигурни, че разработчиците мързеливо подплащат своите оценки и използват допълнителното време, за да "златната чиния" или да проверят запасите си,данните показват друго. Стратегията за „отмяна“ не работи.
И сега какво? Нека се откажем от модела на гадател и да преминем към подход, основан на размера. Оказва се, че докато хората са доста ужасни в оценката на времето за завършване, ние всъщност сме доста добри в това да кажем колко голямо е нещо. Особено добре се справяме със сравнителното оразмеряване („то е по-голямо от това, но по-малко от това там“). Ако мислим по-скоро за размер или сложност, отколкото за време, мозъкът ни го обработва по-надеждно. След това можем да вземем стойностите на размера и да изчислим действителния брой часове за проекта въз основа на изящна магическа формула! И точно тогава на сцената излиза популярният модел функционални точки (етап вляво).
Анализ на функционални точки (FPA)
За анализ на функционални точки трябва да идентифицираме пет вида неща в нашето приложение: външни входове, външни изходи, външни заявки, файлове с външен интерфейс и вътрешни логически файлове (не се притеснявайте много за дефинициите; можете да ги изследвате по-късно). Всеки пример за тези (функция) има сложност, свързана с нея (ниска, средна или висока). Използваме таблицата по-долу, за да разберем колко точки получава всяка функция.
Сега, ако съберем точките за всички наши функции, може да получим число като 457 функционални точки за нашия проект. Тогава просто се нуждаем от формула, за да разберем броя на часовете… Въз основа на последния ни проект, нашата „норма на доставка“ беше 15 функционални точки на човек на месец. Това е работа на стойност около 30 месеца, което за моя екип от 12 души трябва да отнеме малко повече от два месеца и половина!
Това със сигурност е по-сложно от предишния ни модел. Всъщност има четири ключови области на сложността, които трябва да се разпознаят.
- Петте типа компоненти не са непременно интуитивни и е лесно да забравите да сложите нещо в списъка или да го присвоите на грешната група.
- Таблицата, използвана за действително генериране на функционалните точки, съдържа магически числа, които ще изискват много усилия за валидиране. Правилно ли са калибрирани тези числа, за да се генерират надеждни оценки за моите екипи?
- Доставката (критична част от пъзела) се изчислява въз основа на производителността на вашия екип. Колко често трябва да изчисляваме ново число? Всъщност има много малко насоки за това.
- Какво представлява ниска, средна или висока сложност? Как да дефинираме това, така че всички да го разберат? Получаването на това право не е ли критично за точността на нашите изчисления?
В този много прост пример има няколко движещи се части и дори не сме обсъждали по-сложни модели на сложност и другите данни, които могат да влязат в сила (напр. Процент на разходите, процент на поддръжка, плътност на дефектите и т.н.). Повече движещи се части означава повече възможности за възникване на грешки. Прекалено сложни ли правим оценката сега? Ние не плащаме на разработчиците, за да отделят много време за оценка. Не мога да продам прогноза на клиентите си. Имам нужда от работещ софтуер. Има ли нещо друго там?
Става пъргав
Сега нека разгледаме накратко пъргавия скрам (достатъчно, за да направим сравнение). Както беше посочено по-рано, хората са ужасни в изчисляването на времето и са доста добри в сравнителното оразмеряване. Ето няколко термина, които трябва да разберете:
- Спринт - период от време (обикновено две седмици).
- Потребителска история - отделна работа, за предпочитане достатъчно малка, за да бъде извършена от един човек в спринт. Това е нещото, което оценяваме.
Най-популярната стратегия е използването на фибоначи последователност (0, 1, 2, 3, 5, 8, 13) за оценки. Не е линейно - докато се качвате по скалата, размерът на пролуките се увеличава. Ключът е, че пропуските трябва да бъдат достатъчно широки, за да няма причина да се спори за незначителни разлики. След като стигнете над 3, разликата между 4 и 5 или 7 и 8 е толкова незначителна, че е безсмислено да отделяте време за хеширане кой е. Последователност на база 2 също би работила (0, 1, 2, 4, 8, 16 и т.н.).
„Но чакай, това е само цифра. Какво означава? Колко часа е точка? “ Точките не са предназначени да корелират директно с часове, защото ако го направят, екипите биха се изкушили да се върнат към оценяване в часове и след това да го преобразуват по някакъв начин. Както беше обсъдено по-рано, точността на нашите оценки идва от сравнителното оразмеряване и не изчисляването на броя часове, които нещо ще отнеме. Ако дадете на екипа способността да мисли с часове, вие компрометирате способността си да правите точна оценка.
Да приемем, че сте започнали с упражнение за калибриране. Издърпайте екипа си в стая и ги преведете през списък с 10-12 потребителски истории. Изберете една малка, но не най-малката и направете тази първа. Прегледайте го и обявете, че тази история е „3“. Не питаш. Разказваш. След това преминете към следващата история. „Ако това беше 3, какво е това?“ Сега екипът оразмерява истории в сравнение с други истории. В крайна сметка те ще имат доста добра представа какво представлява „1“, „2“ и т.н. Те не правят оценка. Времето няма значение. Те оразмеряват истории, в сравнение с други истории, които вече имат номер. След това можете да поставите примерни истории за всяко число в последователността в документ, наречен линийка. Те могат да го използват като справка, ако не са сигурни какво е „5“.
Ето тук е ключът. Вълшебният сос, който прави тази работа, е „скорост“ (броят точки, които екипът може да набере в спринт, усреднен за 3-4 спринта). Да приемем, че спринтът ви е две седмици, а екипът ви от 8 души има средна скорост от 35 точки. Получавате 35 точки за 640 часа работа (8 x 80 часа). Ако разберем, че дадена функция ще отнеме около 100 точки на работа, за да завърши, знам, че това е около 6 седмици работа и ~ 1900 часа. Екипът се справя много добре с последователното оразмеряване на истории и вие го използвате, за да планирате проекта си. Това изчисление работи, защото продължителността е последователна от спринт до спринт.
За да направите дългосрочно планиране на високо ниво, можете да поискате от вашите клиенти да разбият функциите на високо ниво в междинни истории с една линия и да поставят стойности на точки върху тях. Ще бъде загубена степен на точност, но вие се възползвате от модела, който вече разбират. По-точен път би бил относителното оразмеряване на ниво функция. „Тази функция е по-голяма от тази 40-точкова функция, по-малка от тази 120-точкова функция там и малко по-голяма от 65-точковата, която току-що направихме.“ Историите са групирани в „епоси“. Ако всяка функция е епична, в края ще разберете колко точки са необходими, за да завършите тази функция. Запазете история на това и можете да го използвате за вашето планиране на изданието.
Заключение
Днес има много използвани методологии. Всеки има плюсове и минуси. По някакъв начин трябва да разберем как да увеличим максимално точността на нашите оценки, за да можем да вземем добри решения. Това не означава, че нашите оценки трябва да бъдат точни. Те просто трябва да бъдат достатъчно точни, за да са полезни. Ако не разбирате прогнозата, може да предположите, че оценките не са били точни, тъй като екипът не е свършил добра работа. Те не са оценили правилно или не са изпълнили проекта правилно. Побоите ще продължат, докато оценките се подобрят. Но изчисленията никога не трябва да се използват като ангажимент. Това е най-доброто предположение въз основа на ограничената информация, която имаме днес. Когато се появи нова информация, трябва да позволим преразглеждането на прогнозите. Всичко друго очаква невъзможното, което е проблем с лидерството (не с екипа).
Подходът на Scrum е много по-прост от това, което виждаме при анализа на функционалните точки. И бих казал, че е много по-надежден от магическите таблици с магически числа. Получава най-много пари (минимални усилия с разумно висока степен на точност). От гледна точка на усилията, това не създава тежък процес за разбиране и използване на екипите. Оценката на пъргавината всъщност може да се случи много бързо, след като всички разберат подробностите за оценяваната работа. Със сигурност е по-добре от изваждането на цифри от въздуха. Използването на скоростта прави нещо много важно: то включва исторически данни в изчислението. Всеки спринт преизчислявате скоростта си. Това е критично, тъй като с течение на времето производителността се променя. Екипите, които използват FPA, могат да извлекат процента на доставка от предишния си проект,което в някои случаи беше преди няколко месеца. Много неща вероятно са се променили оттогава. Моето предложение е да проучите Agile и наистина да положите усилия за разбиране на сюжетни точки и скорост. Не се връщайте да правите оценки за часове, само защото това е, което разбирате. Вярвам, че ще се благодарите по-късно.