Полезни показатели за оценка на проекти
Защо да измервате нещо?
Има проект. Вашият любим, скъп, когото желаете да расте и просперира. Но как да оцените неговия просперитет, ако няма критерии за самия този просперитет? Как можете бързо да реагирате на проблеми, преди да станат невъзстановими, ако не използвате „Future F Sensor“? Как да разберете какво трябва да се подобри, ако не знаете източника на проблема?
Накратко, показателите са необходими за ефективно управление на проект: диагностицирайте проблемите, изолирайте ги, поправете ги и проверете дали избраните от вас начини за решаване на проблема наистина помагат.
Ще споделя различни видове показатели, всеки от които е тестван и е донесъл значителна полза. Всеки път, прилагайки ги, всеки екип е много мързелив и неудобен: трябва да запазите допълнителна информация, да измерите нещо там, да създадете бюрокрация. Но когато за първи път се възползваме от който и да е показател, мързелът се заменя с дисциплина и дълбоко разбиране на важността на този или онзи показател.
И ако те не дойдат, тогава показателят може безопасно да бъде изхвърлен;)
История 1: Кой го пусна тук??
В една страхотна компания ръководството се оплака от „продукт с лошо качество“ поради тестване. Моята задача беше да анализирам причините за това злощастно недоразумение и по някакъв начин да ги разреша, и разбира се вчера.
Задача #1 стана очевидна за мен:изчислете % на пропуснатите грешки: вярно ли е, че тестерите пропускат нещо? За да направим това, въведохме полето „докладвано от клиента“ в инструмента за проследяване на грешки, маркирахме стари грешки по този начин и ги преброихме. Процентът беше малко над 5%, като не всички бяха критични.
Много ли е или малко? Според моя опит това е доста добър процент. Откъде тогава мнението, четестерите пропускат много?
Въведохме още едно поле: „възпроизведено във версията за освобождаване“. Всеки път, когато от тестовия стенд беше подаден нов бъг, тестерите проверяваха дали е в най-новата потребителска версия: може би потребителите просто не съобщават за конкретни бъгове? Резултатът за първия месец е около 40% от грешките, регистрирани в инструмента за проследяване на грешки, се възпроизвеждат във версията на изданието.
Оказва се, че наистина пропускаме много, но потребителите не съобщават за конкретни грешки, а мнението „софтуерът ви е гаден!“ те са ясно оформени. Така сме формирали метрики-сензори: какво не е наред:
- % от грешките, пропуснати във версията за освобождаване
- % грешки, докладвани от потребителя
За да отговорим на този въпрос, трябва да копаем по-нататък и да търсим нови показатели, които ще отговорят на този въпрос.
В този случай сме добавили още едно поле за всички пропуснати грешки: „Причина за пропускане“. И посочваме избора защо не сме въвели този бъг по-рано:
- неизвестно изискване (не знаех или не разбрах, че е необходимо)
- не взе предвид теста (не се сети да го тества ТОВА е какво)
- не е тестван (имаше тест, беше проверен, но след това функционалността се повреди и тази област не беше повторно тествана)
Мозъчната атака „как да се реши тази загадка“ доведе до различни решения: седмично обсъждане на пропуснати дефекти в екипа за тестване, одобрение на теста с анализатори и разработчици, директна комуникация с потребителите за изследване на техните среди и условия и т.н. Чрез бавното прилагане на тези нови процедури намалихме процента на пропуснатите грешки до 20% само за 2 месеца. НЕ разширяване на екипа, НЕ увеличаване на сроковете.
История 2: Откъде идват дървата за огрев?
Тази история засяга един от моите собствени проекти. Разработваме някаква страшно необходима и полезна услуга, а графикът на разработката не ми стопли душата. Естествено, всичко по моя проект е много добро с тестване, но защо разработката едва се бави?
Естествено, започнах с опит да измервам субективните си усещания "бавно". Как да го разбираме? С какво да сравнявам? KLOC на месец? Функция в итерация? Средни закъснения по отношение на плана? Естествено, първите 2 показателя няма да донесат нищо полезно, така че започнах да гледам процента на пропуснатите срокове за функции (нашите итерации нямат фиксиран набор от функции, така че не могат да закъснеят сериозно - това, което успяхме да направим и тестваме за 2 седмици, след това го публикуваме). Но функции!
Започнах да анализирам: средно 1 малка функция представлява 15 до 40 грешки и отнема повече време, за да ги поправите, отколкото да разработите самата функция. Защо? Много ли е или малко? Разработчиците се оплакват, че има много искания за промяна на вече разработената функционалност - вярно ли е това или е субективна погрешна оценка?
Копаем по-нататък. Въвеждам в горкия нещастен инструмент за проследяване на грешки, набъбнал от допълнителни полета полето: "Причината за грешката." Не прескача като в История №1, а ВЪНШЕН вид. Това поле се попълва от разработчика по време на ангажимента, когато тойзнае точно какво и как е коригирал. А вариантите за отговор са:
- Код (те го взеха и го прецакаха)
- Неразбиране на изискванията („о, не разбрах, че точно това е необходимо!“)
- Промяна на изискването (собственикът на продукта погледна резултата и каза „ъ-ъ, не, всъщност трябва да е различно, а не начина, по който поисках първоначално“)
Намерихме много възможности за решаване на проблема, като се започне от наемането на технически писател, който ще поиска от собственика на продукта изисквания и ще документира подробно всичко, което описваме в няколко реда, и завършвайки със собственика на продукта, който беше прехвърлен на секретари, документира нови функции денонощно. Не ни хареса нито една от тези опции, те са твърде бюрократични за екип от 4 разработчици, които седят в един офис. Така че направихме следното:
- Собственикът на продукта накратко, както винаги, описва новата функция
- Разработчикът, когато става дума за това, внимателно обмисля метода на внедряване, как ще изглежда, какво трябва да прави с тази функция
- След това разработчикът и RO сядат заедно и разработчикът обяснява подробно своите мисли за светлото бъдеще на разработваната функция.
- Разработчикът при никакви обстоятелства не започва работа по нова функция, без да премине през горния алгоритъм от действия и без да съгласува визията си с RO
- Тестерът най-често участва в този процес, като предварително предполага трудните моменти, които ще тества
час "чат" на седмица, който излиза от 2-3 души. Броят на въведените грешки е намалял, от които са станали повече от 50% от грешките в кода - следователно следващата ни задача ще бъде внедряването на преглед на кода, т.к. сега имаме нов "главен проблем".
Но от метричния анализатор се върнахме към метричния сензор и разбрахме, че от пролетта не сме пропуснали крайните срокове за функция с повече от 50%, въпреки че преди това средната стойност на разбивката беше от 50% до 100%, а понякога и повече.
И това е само началото! ;-)
История #3: Кой забавя разработчиците?
Друга история се отнася до скорошния ми опит с компания на трета страна. Истински, истински Agile, седмични итерации... И пропуски на седмичния краен срок!
Причината, посочена от ръководството на компанията: „Разработчиците допускат твърде много грешки“.
Започнах да анализирам как става това. Просто участвах в процеса и го наблюдавах отстрани, както е много хубаво описано в книгата на Имаи "Гемба Кайзен". И ето какво видях: Излиза в четвъртък, петък е подготвителният ден за новата итерация. Във вторник-сряда се появява сборка за тестване. Дефектите започват от сряда до четвъртък. В петък, вместо да се подготвят за нова итерация, разработчиците спешно коригират грешки всяка седмица.
Помолих в инструмента за проследяване на задачи, където функциите от таблото се дублират, да запиша статусите за функцията: функцията е приета за разработка, функцията е дадена за тестване, функцията е тествана и изпратена за ревизия, функцията е тествана и приета за пускане.
И какво мислите, какво е средното време между "функцията е дадена за тестване" и "функцията е тествана и изпратена за ревизия"? 1,5 дни!
А понякога – и с ЕДИНСТВЕНИЯ блокиращ дефект.
Разработчиците в тази компания се оплакахаспирачни тестери, но тестерите и ръководството бяха против разработчиците: "вие сами трябва да тествате и да не давате суровия продукт." Но на Цезар е Цезарово!
И така, има метрика, 1,5 дни е неприемливо дълго време, искаме да го намалим поне три пъти - това трябва да ускори изданията с един ден. Как да го направим? Отново мозъчна атака, отново куп идеи, 90% от участниците в процеса настояват „разработчиците да се тестват“.
Намалихме периода от 1,5 на 0,5 дни много бързо, но на практика постигнахме друга, по-сериозна промяна: процентът на характеристиките, прехвърлени в статус „изпратени за ревизия“, намаля от почти 80 на почти 20! Това е 4 пъти! Тоест 80% от функциите вече бяха приети веднага след прехвърлянето им в статус „тестване“, тъй като малко преди да бъдат прехвърлени в този статус, тестването беше извършено „в движение“, което значително намали както времето за регистриране на грешки, така и разходите за коригирането им.
Между другото, история 3 е единствената, в която веднага постигнахме целта си. Сривовете на итерациите все още се случват, но сега това е изключение и почти всеки четвъртък екипът за разработка се прибира навреме, а в петък наистина започва подготовката за следващата итерация.
Наистина не исках да рисувам сухи формули, да философствам и теоретизирам. Разказах конкретни истории от пресен (2012!) опит. Истории, при които намалихме сроковете и подобрихме качеството, без да променяме бюджета.
Все още ли не сте готови да използвате добре показателите?