Гъвкавите показатели са измервания, използвани за проследяване на напредъка и успеха на гъвкав проектен екип.
Показателите, когато са дефинирани по правилния начин, предоставят представа за представянето на екипа, качеството, ефективността на тестването или цялостната ефективност и как се развива с течение на времето.
Крайната цел на гъвкавите показатели е да помогне на екипите да идентифицират области за подобрение и да вземат решения, базирани на данни, които ще доведат до по-добри продукти, докато екипът напредва.
През повечето време компаниите дефинират показатели, които са или метрични показатели, или необработени числа, добре нарастващи отляво надясно. Може да изглеждат добре на някои табла, но обикновено са безполезни за самия екип.
Целта им не е да помогнат на екипа по никакъв начин, а по-скоро да попълнят някои отчети за ръководството и след това да завършат с някои стратегически решения. За съжаление тогава екипът не разбира защо съществува това конкретно решение.
В оградата за изпълнение на такива грешни показатели екипите след това фалшифицират собствените си процеси, за да направят показателите да изглеждат добре. Но резултатите на отбора изобщо не се подобряват.
Съдържание
Основни показатели
Има много начини за разделяне на показателите. Може би най-основният е отгоре надолу и отдолу нагоре.
➡️ Отгоре надолу означава: Ние, ръководството, ще създадем за вас показатели, на които искаме всички да отговаряте, и крайната ви цел е да се вместите в зелените зони на тези. Ние нямаме нищо против дали вие – отбор ги харесвате или не; това е, което искаме да проследим.
➡️ Отдолу нагоре означава: Ние – екипът трябва да се подобрим в тези области и за това трябва да се съсредоточим върху тези неща. Ето защо ние дефинираме показатели, които ще ни позволят да проследим напредъка на екипа към нашите цели и можем да ви демонстрираме – лидерството как точно подобри работата ни с течение на времето.
Определение за добър показател
И така, какво трябва да съдържа всеки добър показател или как да го опишем?
Най-важното свойство е промяната на поведението. Това означава, че всеки път, когато погледнете резултата от показателя, е ясно какво трябва да се промени в екипа, за да получите подобрения.
Тогава трябва да е просто. Ако не можете да го обясните с няколко прости изречения, така че всички съответни слушатели да могат да разберат, тогава нещо наистина не е добре.
Добрият показател е сравним във времето. Направете моментна снимка на резултатите след време, след което го направете отново по-късно. Поставете ги един до друг. Ако не можете да сравните двата резултата помежду си, тогава трябва да помислите втори път за този показател.
И накрая, по-добре от чистите числа, когато е възможно, направете го съотношение или процент. „10 нови открити дефекта по време на спринта“ няма да кажат много. Зависи дали обикновено имате един или 100.
Ето няколко примера за показатели, които смятам, че отговарят на всички тези критерии за дефиниция. Те имат предвид специално Agile екипи. Има три основни категории: производителност, качество и морал.
Категории показатели
Показатели за ефективност
Целта е да се разбере колко добър е екипът в наваксването на истории, извършени в рамките на спринт. За да прецените дали свръхангажираността не е обичайна работа или дали историите за пренасяне са стандарт от спринт до спринт.
От гледна точка на гъвкавото представяне екипът трябва да се стреми да предостави планирано съдържание за спринта, с което екипът се е ангажирал в началото на спринта.
Това не означава, че няма да сме гъвкави в размяната на истории по време на спринта. Но винаги трябва да има преговори, водещи до размяна, а не до добавяне. Капацитетът на екипа няма да нарасне само защото някой е добавил нови истории в спринта.
Ние въвеждаме този показател, за да внимаваме за такива случаи и да напътстваме всеки в екипа да защити капацитета, който имат за спринта.
Това изгражда надеждността и предвидимостта на екипа.
#1. Капацитет на спринта спрямо доставени исторически точки
Гледайте хронологията на капацитета на спринта спрямо съдържанието на доставените исторически точки (SP) през спринтовете.
- Малки отклонения от спринт до спринт са добре. Огромни скокове във всяка посока сигнализират, че нещо не е наред.
- Общ капацитет за спринт – свободният ден на един член на екипа добавя един към общия капацитет. Например, ако екипът има 10 души и всички те ще бъдат на разположение в пълен спринт, тогава общият капацитет за спринта е 100.
Проверете капацитета на спринта спрямо завършен SP от спринт до спринт. Ако екипът (по време на планирането) се ангажира със значително по-голямо количество SP, отколкото обикновено може да изпълни, увеличете този риск за екипа.
Целта трябва да бъде общ планиран SP равен или по-малък от общия завършен SP за спринт.
Все още можете да имате повече завършени SP от планираното, ако отборът завърши (към края на спринта) всички планирани истории и отборът все още има капацитета да вземе допълнителната история.
- Ако отборът многократно предоставя по-малко SP от планираното, отборът трябва да промени планирането си и да вземе по-малко SP в следващия спринт.
Инструменти като monday.com, Atlassian Jira или Asana предоставят лесен начин за запазване и извличане на точки за история за всяка история в спринтовете. Те дори могат да генерират това за вас автоматично след всяко планиране на спринта.
#2. Графика на изгаряне
Това е един от показателите, който вероятно повечето от скръм екипите имат някъде скрити на таблото. Съгласен съм, че това може дори да изглежда като безполезно нещо. Екипът рядко го взема под внимание. По-скоро мениджърът иска да посочи как историите наистина изглеждат от високо ниво и как не напредват добре (тъй като всички са отворени през целия спринт).
Това, което бих искал да подчертая, е, че въпреки това вие като екип трябва да отидете и да проверите диаграмата за изгаряне за ваше добро. Ако всички истории са отворени през целия спринт и са затворени само в последния ден от спринта, това създава несигурност в екипа и по отношение на изпълнението на целите на спринта.
- Прегледайте своята дъска за спринт за завършени истории.
- Проверете с екипа, за да определите защо малките истории все още са отворени, дори ако са започнали в началото на спринта.
- Работете с екипа, за да изградите това мислене, а не да държите историите отворени по-дълго от необходимото.
- Идеалната диаграма на изгаряне обикновено е теоретично състояние. Въпреки това, колкото повече се доближаваме до него, толкова по-ефективно боравене с историята имаме.
Инструментите за гъвкаво управление като Asana могат автоматично да генерират диаграма за изгаряне за всеки спринт.
Източник: asana.com
#3. Изпълнение на целта на спринта
Това проследява процента от целите на спринта, които сте постигнали по време на всеки спринт.
Вие документирате целите на спринта отделно, напр. на страницата Confluence / Jira, за всеки спринт. Състоянието ще бъде присвоено независимо дали са били изпълнени или не в рамките на спринта.
Дори ако екипът не е завършил всички истории в рамките на спринта, той пак може да постигне целта на спринта (напр. липсват само странични истории).
Ще се стремим към 100% постигане на целите за спринт всеки спринт. Ако това не е така, разберете какво предотвратява екипът.
- Ако във всеки спринт има твърде много паралелни теми, намалете броя им.
- Ако по време на спринта се добавят твърде много ad hoc истории, намалете това, така че да не повлияе на първоначалните цели на спринта.
- Ако целите на спринта са твърде големи или твърде предизвикателни, опростете ги. Така или иначе няма смисъл да имате големи спринтови цели, докато не ги изпълнявате до края на спринта.
Показатели за качество на кода
Това ще проследи колко добър е кодът във времето. Помага за поддържането на здравословни процеси на развитие и намалява времето, прекарано за разрешаване на проблеми. Или времето на неактивност на програмиста, причинено от изчакване на изпълнението на кода по време на дейности за разработка и тестване.
Източник: azuredevopslabs.com
#1. Автоматизирани тестове
Създавайте автоматизирани единични тестове от разработчиците за всяка промяна, която правят.
- Измерете покритието на кода чрез автоматизирани тестове – използвайте Azure Pipelines или SonarCloud, за да изпълните тестовете. Стремете се към 85% покритие. Над 90% не е наистина ефективно.
- Уверете се, че автоматизираното създаване на Unit test е част от определението за готово за новите истории.
- Наваксайте с покритието на тестовете за стари кодове като част от историите за технически дългове в изоставането.
#2. Сложност на кода
Оценявайте ненужните усложнения, които кодът получава с течение на времето, и активно го коригирайте чрез истории за технически дългове. Или да ги предотвратите, ако е възможно.
Дефинирайте кодови стандарти и насоки, за да обучите разработчиците да ги следват. Уверете се, че се придържат към правилата за кодиране, за да сведете до минимум необоснованото увеличаване на сложността на кода. Редовно актуализира насоките въз основа на опита на екипа.
Идентифициране на миризми на код – индикатори за потенциални проблеми в кода, като дублиран код, дълги методи и неизползвани променливи.
Партньорските проверки гарантират, че стандартите за код се прилагат към новосъздадения код.
Използвайте инструменти като табла за управление и отчети на Azure Ado или SonarCloud, за да откриете проблеми с кода.
#3. Ръчни стъпки при внедряване
Проследете колко ръчни стъпки трябва да направи екипът, за да пусне кода в тестови или производствени среди.
- Нашата цел ще бъде да постигнем 0 тук с течение на времето.
- Създайте истории за технически дългове, ако е необходимо, за да изведете тръбопровода за внедряване/пускане до пътната карта за автоматизация. Постепенно намалявайте оставащите ръчни стъпки в процесите от спринт до спринт.
Морални показатели
Това е метрика за проследяване как екипът се чувства относно работата си и процесите, с които се занимава ежедневно.
#1. Спринт Ретроспективно изпълнение
Можете да проследите колко елемента за действие са били действително изпълнени в следващия спринт.
- Scrum Master ще събере резултатите от ретроспективната среща в страниците на екипа, за да проследи договорените елементи за действие.
- След това екипът ще следи напредъка.
- След това ръководството на проекта може да прегледа дали елементите за действие напредват или какво пречи на екипа да ги завърши. След това променете средата, за да позволите на екипа да напредне в договорените елементи за действие.
Най-малко 33% или 1 (в зависимост от това кое е по-високо) елементи за действие от предишния спринт ще бъдат приети в следващите спринтове.
Ако е по-малко от това, необходими са промени, за да се позволи на екипа да приложи подобренията, за които са се съгласили.
Инструментите за управление на проекти съдържат готови за използване шаблони за спринтови ретроспективни дейности. Ето пример от monday.com:
Източник: monday.com
#2. Екипно сътрудничество
Програмиране на двойки песни.
- Сформирайте естествена двойка за всяка история, за да работите заедно, споделяйки наблюдения, знания и успех. Създавайте подзадачи под истории, притежавани от различни членове на екипа.
Прегледи на Track Code от инициативи на колеги.
- Връстниците са помолени или проактивно предприемат действия, за да прегледат продукцията на нечия друга история.
Показателят може да бъде извлечен от дъската monday.com/Asana/Jira от подзадачите.
Най-малко 50% от историите в спринта трябва да бъдат споделени от членовете на екипа. Ако е по-малко, проучете причините и предприемете действия, където има смисъл.
За доброволни партньорски проверки, проследявайте историите със специални подзадачи. В началото 20% от кодовите истории, прегледани по този начин, е добро начало. Постепенно по време на спринтовете ще насърчите и мотивирате екипа да работи повече съвместно и ще го увеличите до 50% от кодовите истории на спринт като цел.
#3. Технически дългове срещу нови истории за функционалност
Източник: atlassian.com
Даването на възможност на екипа да разреши собствените си дългове ще увеличи удовлетворението на екипа от тяхната работа.
- Напротив, натрупването на проблеми с технологичния дълг без план за постепенното им решаване ще демотивира екипа с течение на времето. И решението ще стане по-нестабилно, сложно и трудно за решаване без съществена преработка.
Екипът знае най-добре какво не работи добре с решението, дори ако заинтересованите страни или крайните потребители не го виждат. Подобни истории оказват най-голямо влияние върху самия екип на разработчиците. За заинтересованите страни те може да са невидими. Ето защо е важно да се даде шанс на екипа да работи върху истории, които ще му помогнат да разчисти дейностите по разработка.
Целта е да се проследи колко истории за повдигнат технически дълг са решени с течение на времето и дали изоставането от такива истории само нараства или не.
Екипът може да обозначи историите като TechDebt в неизпълнените задачи и да им даде приоритет от екипа, така че да могат да отидат на върха и да бъдат избрани в спринтове.
В зависимост от това в какво състояние е проектът и колко технологични дългове са идентифицирани в изоставането, може да искате да се уверите, че изоставането на TechDebt не нараства с повече от 10% от спринт до спринт.
Дайте приоритет на историите за технологичен дълг и ги включете в спринтовете, за да поддържате растежа на изоставането на технологичния дълг под контрол, така че на екипа да бъде позволено да работи върху историите за технологичен дълг през 10-20% от времето на всеки спринт.
Заключителни думи
Всеки проект в крайна сметка ще се нуждае от някои показатели, независимо дали защото ръководството иска да ги има или защото екипът решава да измери собствения си успех.
Най-доброто, което можете да направите, е да започнете да изграждате своята библиотека от показатели, готови за избиране и използване; Колкото по-скоро, толкова по-добре. И докато правите това, уверете се, че винаги избирате преди всичко показатели, променящи поведението.
След това проверете нездравословните процеси, които могат да съсипят вашия спринт.