След поставянето на цели неизбежно следва проследяване на тяхното изпълнение. Това е една от основните отговорности на всеки проектен мениджър, а мениджърите по разработка на софтуер не правят изключение.
Проектните мениджъри използват специфични KPI, за да управляват ефективно проектите за разработка на софтуер. Скоростта на разработка, времето на цикъла и времето за изпълнение са примери за KPI, които могат да се използват за проследяване на софтуерни проекти.
Тези KPI за разработката на софтуер са вашият набор от обективни данни, с които да проследявате всяка стъпка от жизнения цикъл на разработката на софтуер, за да идентифицирате пречките и да работите за непрекъснатото му усъвършенстване.
Нека видим как екипите за разработка на софтуер могат да оптимизират процеса на разработка с помощта на 25-те най-важни KPI (ключови показатели за ефективност) за разработка на софтуер, които да подпомогнат вземането на решения.
25 показателя за ефективност за разработката на софтуер
Съществуват безброй KPI, съобразени с конкретни бизнес цели и текущи проекти. Ето 25-те най-важни показателя, които ще помогнат на вашия екип от разработчици да надхвърли целите си.
1. Скорост на разработване
Измерете производителността на екипа за разработка на софтуер с помощта на скоростта на разработка. Тя показва общата работа, която екипът ви може да свърши по време на спринт (фиксиран период, през който трябва да бъдат изпълнени задачите).
В рамките на един спринт използвайте точки за история, за да изчислите усилията, необходими за завършване на задачата, по скала от едно до десет, като едно е най-бързото, а десет е най-сложното. Чрез измерване на всеки спринт и точка за история можете да разберете средната скорост на вашия екип за разработка в рамките на три спринта.
Без тази метрика ще бъде трудно да планирате, да определите приоритети, да разпределите ресурси и да поставите реалистични очаквания за бъдещи проекти.
Скорост на разработване = Общо завършени точки в спринт
2. Време на цикъла
Цикълът е показател на DevOps Research and Assessment (DORA) за измерване на времето, необходимо за изпълнение на дадена задача. Той количествено измерва производителността на екипа и оценява времето, необходимо за завършване на бъдещи задачи.
Например, в разработката на софтуер цикълът може да се отнася до времето, необходимо за отстраняване на бъг, от момента, в който той е възложен на разработчик и преминава през тестове за стабилност и тестове на кода, до момента, в който е отстранен и одобрен от отдела за контрол на качеството.
Този показател помага да се оцени производителността на екипа от разработчици и да се идентифицират областите, които се нуждаят от подобрение. Можете да сравните времето на цикъла на всяка задача с желаната продължителност, за да анализирате къде екипът има недостатъци.
Време на цикъла = Крайно време – Начално време
3. Покритие на кода
Покритието на кода, наричано още покритие на тестовете, измерва процента на тествания код. Тази метрика на DevOps измерва качеството на софтуера за производствени и тестови цели.
Той дава приоритет на тестово ориентираното разработване (TDD) и идентифицира грешки в кода. Колкото по-високо е покритието на кода, толкова по-малки са шансовете за грешки.
Покритие на кода = (Брой редове код, изпълнени от тестове / Общ брой редове код) X100
4. Честота на внедряване
Внедряването на гъвкави методологии може да затрудни измерването на производителността на компанията, тъй като целият екип трябва да проследява гъвкави показатели през целия цикъл на разработване. Когато проследявате производителността на инструментите и процесите за разработка на софтуер в рамките на такъв процес, можете да разчитате на KPI за честотата на внедряване.
Той определя скоростта, с която екипът за внедряване внедрява код в различни отдели, като например стартиране, тестване и производство. Този KPI е сред четирите показателя на DORA и е свързан с други, като например процент на неуспешни промени, време за промени и средно време за възстановяване.
Този KPI за софтуер предоставя информация за ефективността и гъвкавостта на екипа за разработка, определя критерии за подобряване на практиките за внедряване и помага за непрекъснатото усъвършенстване.
Честота на внедряване = Общ брой внедрявания / Времеви период
5. Нетен индекс на лоялност
Net Promoter Score (NPS) измерва удовлетвореността на клиентите по скала от нула до десет, където нула означава най-лошото потребителско преживяване, а десет е най-доброто.
Хората, които оценяват софтуера между нула и шест, се наричат критици, тези, които го оценяват между седем и осем, са пасивни, а тези, които го оценяват между девет и десет, са поддръжници. Ако броят на поддръжниците надвишава този на критиците, софтуерът работи добре.
Net Promoter Score = (% промотори) – (% критици)
6. Средно време между откази (MTBF)
Когато се опитвате да оцените надеждността на софтуера, показателят MTBF измерва средното време между две софтуерни повреди.
В софтуерното разработване, където неуспехите са неизбежни, показателят MTBF е от решаващо значение за оценяването на софтуерните задачи и разработването на стратегии за поправка.
Средно време между откази (MTBF) = Общо време на работа/Общ брой откази
7. Процент на неуспешни промени
Измерването на качеството на софтуера е сложно поради неговата субективност. Показателят „Процент на неуспешни промени“ дава представа за качеството на софтуера, като изчислява процента на внедренията, които водят до неуспех в производството.
Ниската степен на неуспех при промените показва по-малко грешки и високо качество. Напротив, високата степен означава повече грешки и необходимост екипът да преработи кода.
CFR = (Брой неуспешни промени/Брой промени)/100
8. Размер на Pull Request (PR)
Размерът на pull request е показател за разработката на софтуер, който измерва броя на промените в кода в едно pull request, отразявайки размера или обхвата на промените, въведени от разработчика.
Малките pull заявки са по-лесни за преглед и обработка, което улеснява по-бързата интеграция, осигурява по-конкретна обратна връзка и намалява риска от бъгове. За разлика от тях, големите pull заявки отнемат повече време за разбиране, преглед и поправка.
9. Коефициент на откриване на дефекти (DDR)
Коефициентът DDR измерва броя на дефектите, открити преди пускането на продукта, в сравнение с тези, открити след пускането.
Използвайте показателя DDR, за да оцените броя на дефектите, пропуснати от екипа ви за тестване и открити от клиентите, които оказват негативно влияние върху тяхното преживяване.
Съотношение на откритите дефекти = (открити дефекти в дадена фаза + общо дефекти) X 100
10. Код Churn
Кодовете често се нуждаят от ревизия при софтуерни ъпгрейди и въвеждането на нови функции. Показателят за промяна на кода измерва броя пъти, през които софтуерният код се нуждае от итерация през определен период. По-високата промяна на кода показва по-висока поддръжка и риск.
Например, DevOp екипите обикновено работят със средна степен на промяна на кода от 25%, което показва, че кодовете са 75% ефективни.
Коефициент на промяна на кода = Общ брой редове код в началото – (Добавени редове + изтрити редове + променени редове)/ Общ брой редове код X 100
11. Простота на кода
Един прост код, изпълнен успешно, е по-добър от сложен код, който изисква постоянни итерации. Простотата на кода може да се измери с помощта на няколко показателя, като цикломатична сложност, дублиране на код, промяна на код и др.
Добрата простота на кода показва, че кодът ще отнеме по-малко време, ще изисква по-малко итерации и ще има по-малко грешки.
Няма пряка формула за измерване на простотата на кода като цикломатичната сложност, тъй като това е по-скоро качествена, отколкото количествена метрика.
12. Кумулативен поток
Мениджърите по разработка на софтуер често искат да знаят на какъв етап са проектите за разработка на софтуер. Кумулативният поток показва чрез визуални диаграми дали дадена задача е одобрена, в процес на изпълнение или в етап на забавяне.
Различните цветове обозначават различни статуси. Освен това ширината на лентата ви показва времето на цикъла. Този KPI за разработката на софтуер ви позволява да оцените статуса на разработката, да идентифицирате пречките и да изчислите усилията, необходими за завършване на забавените задачи.
Прочетете също: Как изглежда денят на софтуерен разработчик
13. Процент на грешки
Процентът на грешките определя броя на грешките, открити по време на тестването на софтуера. Повечето екипи за разработка на софтуер използват този показател, за да сравняват процента на грешките в различни проекти, екипи и времеви рамки, да установят еталони и да поставят реалистични цели за намаляване на грешките.
Можете да ги разгледате от две гледни точки: общият брой открити бъгове и сериозността на идентифицираните бъгове.
Процент на грешки = (Брой открити грешки/ Общ брой редове код) X 100
14. Sprint Burndown
Измерете общия брой задачи, изпълнени в рамките на спринт, с показателя „спринт бурндаун“. Той е сред ключовите KPI за софтуерно инженерство, които определят извършената работа по време на спринтовете. Преразгледайте представянето на екипа, ако резултатите не отговарят на очакванията.
Компаниите често използват спринт бурндаун диаграми и измерват времето и обема на работата, която трябва да бъде изпълнена в точки, за да проверят отклоненията от идеалния напредък.
15. Release Burndown
Показателят за изчерпване на версиите измерва напредъка на пускането на продукта и прогнозира колко спринта ще са необходими за завършване на дадена версия въз основа на предишни спринтове.
Използвайте диаграма за изчерпване на ресурсите, за да прецените дали операциите се изпълняват навреме или са в закъснение и да покажете напредъка на проекта на заинтересованите страни.
16. Ефективност на потока
Показателят за ефективност на потока проследява съотношението между общото и активното време, за да даде представа за периода на застой и да оптимизира работния процес.
Ефективност на потока = (Време за добавяне на стойност / Време за изпълнение) X 100
Време за добавяне на стойност = време, прекарано в дейности, които пряко допринасят за нуждите на клиента, като изходен код/тестване.
Общо време за изпълнение = Времето от момента, в който дадена задача влезе в системата Kanban, до момента, в който бъде доставена на клиента.
17. Средно време за ремонт (MTTR)
Средното време за ремонт се отнася до общото време, необходимо на системата за отстраняване на проблем или повреда. То включва времето за ремонт и тестване, за да се отчете цялото време, необходимо за възстановяване на пълната функционалност на софтуера.
Високият MTTR в проектите за разработка на софтуер може да доведе до непланирани прекъсвания.
MTTR оценява надеждността и достъпността на вашите системи и оборудване и идентифицира области за подобрение и тенденции в отказите, така че вашите софтуерни разработчици да могат да оптимизират стратегиите за поддръжка.
MTTR = Общо време за поддръжка / Брой ремонти
18. Време на изчакване
Времето на изчакване е времето за обработка от момента на издаване на билета до момента на разрешаването му. То се отнася за периода, през който билетът все още е в опашката и не е обработен или разрешен.
Дългите времена на изчакване могат да бъдат причинени от липса на специалисти по качество, лоша вътрешна комуникация или недостатъчни инструменти и поддръжка. Този KPI показва колко оптимизиран е процеса; следователно, колкото по-нисък е, толкова по-добре.
19. Степен на завършеност на обхвата
Колкото по-бърз е процесът на завършване на билетите, толкова по-положително се отразява това на ефективността на екипа за разработка на софтуер. Степента на завършване на обхвата е показател, който определя общия брой билети, завършени в рамките на един спринт.
Ниският процент на завършени задачи подсказва за неоптимизирани процеси, нереалистични цели или недостатъчен брой служители.
20. Добавен обхват
Добавеният обхват е критичен показател за всички мениджъри по разработка на софтуер, тъй като отразява общия брой точки, добавени след началото на спринта.
Висок процент на добавена обхватност показва липса на планиране за определяне на предстоящите предизвикателства. Това нарушава планирането на спринта, като намалява възможността за изпълнение на нова работа.
За да намалите добавения обхват, премахнете функциите, които изискват повече време, отколкото вашият екип може да отдели. Можете също да изготвите прогноза за поддръжката, в която да посочите времето и усилията, необходими за поддържане на функцията в дългосрочен план.
21. Време за изпълнение
Времето за изпълнение измерва общото време от заявката до завършването на задачата. За разлика от цикъла на софтуерните екипи, то взема предвид и времето за изчакване, одобренията и прегледите, необходими преди задачата да бъде завършена.
По-краткото време за изпълнение означава по-бързо пускане на пазара, по-голяма гъвкавост и ефективно използване на ресурсите. Заедно тези фактори допринасят за по-висока удовлетвореност на клиентите.
Време за изпълнение = време на внедряване – време на потвърждение
22. Изгубени усилия
Показателят за изразходваните усилия измерва времето и ресурсите, изразходвани за задачи, които не допринасят за крайния проект или бизнес целите.
Например, ако екипът е работил върху софтуерна функция, която след две седмици е била счетена за ненужна, загубените усилия биха били сумата, изплатена на всички разработчици за работата им през тези две седмици.
За да увеличите производителността и да съкратите времето за пускане на пазара, измерете KPI за разработката на софтуер, като например изразходваните усилия, и намерете начини да ги намалите, за да постигнете успех в проекта.
Изразходвани усилия = (Общо изразходвани усилия / Общо положени усилия) X 100
23. Прекъсвания
Показателите за прекъсвания измерват общия брой прекъснати задачи в даден период. Можете също да измерите общия брой прекъсвания в рамките на дадена задача, за да получите по-ясна представа.
Прекъсванията оказват пряко влияние върху производителността и трябва да се измерват, за да се спазват реалистични срокове. Примери за прекъсвания са технически проблеми, системни сривове, лични прекъсвания или прекъсвания, дължащи се на недостъпност на ресурси.
Коефициент на прекъсване = (Общ брой прекъсвания / Общо работно време) X 100
24. Наемане на персонал и време за въвеждане в работа
Нужни са ви адекватни ресурси, за да изпълните цикъла на разработката на софтуер. Наемането на екип от квалифицирани разработчици понякога отнема време, което подчертава необходимостта от поставяне на реалистични очаквания за изпълнение на задачите.
Времето за наемане определя периода от момента, в който кандидатът кандидатства за работа, до момента, в който я приема. При това се отчита времето за адаптация, което се отнася до периода между наемането на кандидата за дадена длъжност и момента, в който той започва да работи на пълна мощност.
Вземете предвид и двата показателя, когато оценявате жизнения цикъл на разработката на софтуер.
25. Предвидена дата на доставка
Заинтересованите страни често изискват приблизителна дата за завършване на софтуера, а този KPI помага на различните отдели да планират работата си.
Датата на доставка може да се промени в хода на операциите и може да бъде променена, когато настъпят промени.
Прочетете също: Каква е разликата между OKR и KPI?
Предизвикателства при внедряването на KPI за разработката на софтуер и съвети за преодоляването им
Избор на подходящи KPI
При определянето на KPI за разработката на софтуер може да бъде предизвикателство да разберете кои са най-подходящите за вашия проект. Как да изберете най-важните ключови показатели за ефективност от няколкото варианта?
Препоръчваме да започнете с организационните цели и KPI, които подкрепят стратегическите инициативи. Например, ключовите области, в които разработката на софтуер може да окаже значително влияние, включват подобряване на качеството на продуктите, повишаване на удовлетвореността на клиентите и съкращаване на времето за пускане на пазара.
Съответните KPI, които добавят бизнес стойност, включват покритие на кода, време на цикъла, качество на кода, MTTR за подобряване на качеството на продукта, NPS за удовлетвореност на клиентите и честота на внедряване за пускане на пазара.
Съберете мненията на инженери, тестери, разработчици, проектни мениджъри и продуктови разработчици, за да превърнете това в съвместно усилие и да увеличите вероятността за успешна реализация.
Редовно коригиране и проследяване на KPI
KPI не са статични; те трябва редовно да се адаптират към променящите се изисквания и бизнес цели. Можете да ги проследявате чрез електронни таблици, но това има ограничена мащабируемост поради контрола на версиите, липсата на автоматизирани промени в данните и достъпа на базата на роли.
Имате нужда от софтуер или шаблон, за да проследявате и коригирате вашите KPI за разработка на софтуер, за да завършите успешно проекта.
Липса на съгласуваност в екипите
Представете си сценарий, в който екипът за разработка измерва и дава приоритет на NPS резултата, но забравя да го съобщи на екипа за обслужване на клиенти. Без тази съгласуваност екипът за обслужване може да даде приоритет на скоростта пред клиентското преживяване, което подкопава бизнес целта.
Освен измерването на съответния KPI показател, трябва да го съобщите на съответните членове на екипа, за да разберат неговото значение и съответствие с целите на компанията.
Без да използвате общ табло или софтуер, как гарантирате, че всички са съгласувани по отношение на KPI и имат възможност да допринесат за постигането им?
Качество и точност на данните
Проследяването на данни чрез електронни таблици има няколко недостатъка, включително дублирани записи, грешки при ръчното въвеждане на данни и остаряла информация, което може да доведе до погрешни решения.
Силози от данни се създават в много компании, където всеки отдел работи изолирано със собствени данни и методологии.
Например, екипът за киберсигурност в организацията може да работи с различни източници на данни. В контраст с това, екипът за разработка може да има отделни методологии, докато тези екипи имат обща цел – да намалят уязвимостите на софтуера, които са податливи на кибератаки.
Резултатът е фрагментирана среда без единен източник на информация. Организациите не могат да подценяват важността на хигиената и навременността на данните за вземането на обосновани решения, особено когато мултифункционални екипи си сътрудничат за постигането на обща цел. От съществено значение е да има единен източник на информация, като всички екипи имат достъп до едни и същи централизирани данни.
Проследявайте и прилагайте KPI за разработката на софтуер с таблата на ClickUp
След като се запознаете с ключовите KPI за разработката на софтуер, следващият въпрос е как ще ги проследявате и прилагате.
Проследяването на KPI за софтуер отнема много време и е погрешно без ефективни инструменти, които предоставят ясни и полезни данни по ясен и практичен начин.
ClickUp е цялостна платформа за проследяване на всички ваши ключови показатели за ефективност, свързани с вашия софтуерен проект, и за гарантиране, че те са съобразени с вашите бизнес и стратегически цели.
Можете да персонализирате таблото за управление на ClickUp, за да проследявате най-релевантните KPI с данни в реално време и да вземате ефективни и навременни решения. Таблото за управление може да бъде персонализирано с карти за отчитане на спринтове, като карти за скорост, карти за изразходване, карти за изчерпване, кумулативен поток, време на цикъл и време за изпълнение.
Всички тези карти се актуализират редовно (с изключение на скоростта), за да се опрости проследяването на KPI и измерването на усилията за разработка. Тези карти имат различни опции за персонализиране, включително източник, времеви диапазон, период на извадка, обем на работа, филтри за задачи и др.
ClickUp Dashboards интегрира ценни данни от различни източници, за да предостави цялостна представа за показателите и ефективността на проекта за разработка на софтуер. Тези данни могат да се използват за вземане на решения, основани на данни, относно процеса на разработка на софтуер, оптимизиране на разпределението на ресурсите и цялостния процес на разработка.
Шаблони за KPI на ClickUp
Успехът е въпрос на изпреварване на KPI и като мениджър трябва да измервате какво работи и какво не работи за вашия екип за разработка на софтуер.
Шаблоните за разработка на софтуер на ClickUp са предназначени за висококачествена разработка на софтуер. Те се предлагат с готови за употреба, напълно персонализирани подкатегории и помагат за проследяване на KPI за управление на проекти с персонализирани изгледи, статуси и полета.
Шаблонът за KPI на ClickUp улеснява измерването на KPI, независимо дали сте стартиращ или утвърден бизнес. С този шаблон можете:
- Бъдете в течение с най-важните данни – всичко на едно място за всички ваши софтуерни разработчици.
- Получете представа за усилията на екипа си за разработка, като проследявате напредъка спрямо целите.
- Идентифицирайте тенденциите и проследявайте и измервайте напредъка на вашите ключови показатели за ефективност (KPI) с визуална диаграма.
Ето как ClickUp за софтуерни екипи опростява измерването на KPI:
- Създайте цели: Начертайте измерими и постижими цели, които са в съответствие с вашите дългосрочни и краткосрочни задачи.
- ClickUp Dashboard: Идентифицирайте показателите, които най-добре отговарят на вашите нужди, и използвайте таблото, за да ги проследявате.
- Създайте етапи: Проследявайте показателите сами или използвайте автоматизирани аналитични инструменти, за да следите представянето в реално време.
- Анализирайте резултатите: Използвайте изгледа на диаграмата на Гант или изгледа на таблото в ClickUp, за да анализирате резултатите и да промените целите според нуждите.
Свързано: KPI за управление на продукти 🎯
Влияние на осигуряването на качеството върху KPI за разработката на софтуер
Осигуряването на качеството трябва да бъде в центъра на измерването на показателите за разработката на софтуер, от идентифицирането на пропуски в сигурността до тестването на софтуера за откриване на бъгове.
Структуриран и надежден процес на тестване гарантира, че екипът по разработката ще отстрани всички бъгове и проблеми, преди клиентът да започне да използва вашия продукт/софтуер.
Освен това, оптималното качество на доставката намалява времето за преработка на кода и намалява честотата на грешките и съотношението на откриване на дефекти. Ето защо препоръчваме оптимизиране на осигуряването на качеството за бързи и гладки процеси на разработка на софтуер.
Измервайте KPI за разработката на софтуер, за да увеличите шансовете си за успешно изпълнение на проекта
Разработката на софтуер е повтарящ се процес, който изисква често наблюдение и корекции, за да се гарантира успехът на проекта. Задаването на KPI за разработката на софтуер гарантира, че всички носят отговорност и че усилията за разработката на софтуер са фокусирани върху бизнес целите.
Те служат като ориентир за екипите за разработка на софтуер, измерват ежедневния напредък и помагат на ръководството и мениджърите да разберат по-добре цялостната картина.
Интегрирайте софтуера за управление на проекти на ClickUp с процеса на доставка на софтуер, за да измервате напредъка, да проследявате KPI, да ги коригирате при необходимост и да оптимизирате процеса на разработка.
Регистрирайте се безплатно в ClickUp, за да зададете и проследявате вашите KPI за разработката на софтуер.