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