Въпреки че практическите умения и познания за специфични програмни езици, инструменти и технологии са ключът към намирането на работа на пълен работен ден като софтуерен разработчик, има още един ценен показател, който в много отношения може да се разглежда като предпоставка за успех в тази професия: производителност. Измерването на производителността е нещо, което всички професионални разработчици на софтуер трябва да разберат и вземат под внимание, тъй като показателите за ефективност са присъщо важни за всеки екип за разработка на софтуер в днешната бизнес среда.
Защо производителността ви като разработчик има meaning?
В ерата на Agile разработката, DevOps и свиващите се цикли на издаване на софтуер, когато разработчиците трябва да доставят нови версии на продукти възможно най-бързо, компаниите използват множество различни показатели за производителност, за да оценят ефективността на отделните програмисти и екипа като цяло. Погледнато от гледна точка на разработчиците, измерването на производителността може да служи за редица ценни цели, като ви помага да проследявате напредъка на вашите програмни умения, което би ви позволило да постигнете последователно професионално израстване. Високопродуктивните програмисти са тези, които в крайна сметка получават страхотни предложения за заплати и се заемат с най-вълнуващите проекти. Но дори и да не сте точно постижения и просто искате Howвато и да е работа в разработката на софтуер и да имате сравнително успешен в нея, все още трябва да имате поне основно разбиране за показателите за ефективност и How те се използват за измерване на производителността на вашия принос в работата. За което и ще говорим днес.
Показатели за измерване на производителността на разработката на софтуер
Какво представляват показателите за продуктивност на разработката на софтуер?
Метриките за разработка на софтуер са областите на програмиране, където могат да се прилагат количествени измервания, за да се проследи производителността, качеството на работа и продуктивността на разработчика. Всеки показател за производителност се основава на вземане на данни от процеса на разработка и използването им за измерване на производителността. Тъй като почти нищо, свързано с разработването на софтуер, не е лесно и ясно, може да се каже, че измерването на производителността на програмирането също е доста непоследователно и фрагментирано в цялата индустрия. Или просто казано, различни екипи и компании могат да използват напълно различни показатели за ефективност и да подходят към този проблем от различни ъгли. Така че не е нужно да се занимавате с изучаването на всеки един показател, който може да се използва от екипите за разработка на софтуер.
Какви видове показатели за производителност при разработка на софтуер има?
Естествено, има множество различни показатели за производителност, които подхождат към измерването на производителността на различни нива и ъгли. Ето най-често срещаните видове такива показатели за производителност:
Официални показатели, фокусирани върху размера.
Тези показатели са фокусирани върху измерването на размера на работния резултат на програмиста, като редове code (LOC), дължина на codeовите инструкции, сложност на codeа и т.н. Тези показатели все повече се считат за остарели в днешната индустрия за разработка на софтуер.
Показатели за производителност, фокусирани върху времето и функциите.
Има селекция от традиционни показатели за производителност, използвани при разработката на каскаден софтуер, като активни дни, обхват на функционалност, доставена за определен период от време, проценти на изтичане на code, брой възложени задачи и т.н.
Показатели на процеса на гъвкава разработка.
Метриките на процеса на гъвкава разработка, като отчет за изгаряне на спринта, скорост, време за изпълнение, време на цикъл и други, вероятно са най-често използваните показатели сред екипите за разработка на софтуер днес. Ще говорим за Agile метриките по-подробно по-късно в статията.
Оперативни аналитични показатели.
Този набор от показатели е фокусиран върху измерване на производителността на софтуера в текущата производствена среда. Средното време между отказите (MTBF), средното време за възстановяване (MTTR) и честотата на сривове на приложението са най-използваните показатели тук.
Тестване на показатели.
Софтуерното тестване има свой собствен набор от показатели за измерване на качеството на системното тестване, като например процент на автоматизираните тестове, покритие на codeа и т.н.
Показатели за удовлетвореност на клиентите.
И накрая, крайният показател за всяка част от софтуера е изживяването на крайния клиент и има цял набор от показатели за това също, като оценка на усorята на клиентите (CES), оценка на удовлетвореността на клиентите (CSAT), оценка на нетен промоутър (NPS) и други.
Показатели за гъвкава разработка на софтуер
Както можете да видите, е доста лесно да се изгубите във всички тънкости на показателите за производителност на софтуера. Единствените, с които редовният разработчик на софтуер трябва да е добре запознат обаче, са Agile показателите, често използвани от екипите за разработка на софтуер днес като стандарти за измерване на производителността на екипа в различни части от жизнения цикъл на разработката на софтуер. Нека изброим основните и най-често използвани Agile показатели.
1. Спринт Burndown.
Докладите за изгаряне на Sprint са един от ключовите показатели за гъвкавите екипи за разработка на scrum. Тъй като в agile процесът на разработка е организиран чрез обвързани във времето спринтове, Sprint Burndown се използва като начин за проследяване на изпълнението на задачите по време на спринт. Като мерна единица се използват часове or исторически точки. Целта е да се постигне постоянен напредък и да се извърши работа в съответствие с първоначалните прогнози. Sprint Burndown помага на екипите да измерват темпото на работа и да го коригират, когато е необходимо.
2. Отборна скорост.
Скоростта е друг ключов индикатор, който също се основава на часове or исторически точки като мерна единица. Той измерва средното количество работа, която екипът изпълнява по време на спринт, и се използва за оценка и планиране по време на целия проект. Проследяването на скоростта е важно, за да се гарантира, че екипът осигурява постоянна производителност.
3. Сюжетни точки.
На ниво индивидуален член на екипа за разработка точките за история са ценен показател, тъй като размерът на историите, които програмистът доставя по време на всяко издание, е индикатор за производителността на този програмист.
4. Диаграма за контрол на цикъла.
Измерва общото време от момента, в който е започнала работата по задача or друг неизпълнен елемент до нейното завършване. Позволява проследяване и контрол на времената на цикъла, осигурявайки по-предвидими резултати.
5. Пропускателна способност и доставена стойност.
Мениджърите на проекти анализират задачите, възложени на разработчиците, и им определят стойност. След това този показател се използва за измерване на производителността на екипа or, с други думи, количеството извършена работа с добавена стойност.
6. Отлив на code.
Отливът на code е друг показател, който си струва да се спомене, тъй като се използва Howто за измерване на производителността на екипа като цяло, така и за проследяване на ефективността на отделните програмисти. Изтичането на code измерва колко често програмист премахва or прави промени в преди това добавени редове code и Howъв процент от предварително написан code в крайна сметка се променя or изхвърля.
Експертни мнения
И накрая, за да добавим малко перспектива, няколко цитата по въпроса от опитни професионалисти в индустрията за разработка на софтуер. „Надявам се, че не искате да „сравнявате“ своите показатели с няHowъв стандарт or дори с представянето на друг екип в друга компания. Навсякъде, където съм работил, имаше уникални вариации в техните дефиниции на исторически точки, скорост, почасови оценки, задачи и т.н., които наистина биха направor почти невъзможно сравняването на представянето на един екип от една компания директно с това на друг екип в друга компания“, отбеляза Клиф Гor, бивш технически продуктов мениджър и Agile Coach. „Малко съм подозрителен към показателите, когато става въпрос за насочване на представянето на екипа. След като обърнете внимание само на една or две променливи, става много лесно да изпаднете (умишлено or по друг начин) в заблуда на показателя и да се заблудите, че се подобрявате - когато всичко, което правите, е подобряване на показателя. Например, показателите, базирани на скоростта, могат да се „подобрят“ чрез преминаване на екипа към по-малки истории (по-малко работа на история – така че повече истории са завършени – така че скоростта се повишава). Това може да е нещо добро, ако историите са полезни потребителски истории, които осигуряват по-малки увеличения на бизнес стойността. Това може да е лошо, ако историите се превърнат в по-малки и по-„технически“ задачи, които сами по себе си не носят реална стойност“, каза Адриан Хауърд, друг професионалист в индустрията. „Когато работя в система, базирана на изтегляне, ценя производителността и времето за цикъл. Първият ми дава обща информация за капацитета на нашия екип и с течение на времето може да се превърне в много мощна предсказваща мярка. Второто е полезно като общ показател за ефективността на нашите тръбопроводи. Ако времето на цикъла е голямо, време е да започнем да разглеждаме тръбопровода, защото има ограничение, което вероятно можем да работим за облекчаване/използване. Но показателите са само инструменти. Не се изгубвайте в тях и със сигурност не започвайте да планирате към конкретен показател. Помислете Howво правите като екип и How естествено работите, след което изградете системата около хората. Показателите трябва да ви помогнат да видите How вашата система поддържа работата на всички. Или не“, заключи Дейв Сера, продуцент на разработка на видеоигри .
