Гнучкі показники – це вимірювання, які використовуються для відстеження прогресу та успіху гнучкої команди проекту.
Показники, якщо вони визначені правильно, дають зрозуміти продуктивність команди, якість, ефективність тестування або загальну ефективність і те, як це розвивається з часом.
Кінцева мета гнучких показників — допомогти командам визначити сфери, які потрібно вдосконалити, і прийняти рішення на основі даних, які призведуть до кращих продуктів у міру просування команди.
У більшості випадків компанії визначають метрики, які є або марнославними, або необробленими числами, які красиво зростають зліва направо. Вони можуть добре виглядати на деяких інформаційних панелях, але зазвичай марні для самої команди.
Їх мета полягає не в тому, щоб якось допомогти команді, а радше в тому, щоб заповнити деякі звіти для керівництва, а потім завершити деякими стратегічними рішеннями. На жаль, саме тоді команда не розуміє, чому існує саме це рішення.
Щоб виконати такі неправильні показники, команди потім підробляють власні процеси, щоб показники виглядали добре. Але результативність команди аж ніяк не покращується.
Основні показники
Існує багато способів розділення показників. Мабуть, найосновнішим є «зверху вниз» і «знизу вгору».
➡️ Низхідний означає: ми, керівництво, створимо для вас показники, яких ми хочемо, щоб усі ви відповідали, і ваша кінцева мета – вписатися в зелені зони цих показників. Ми не проти, подобаються вони вам – команді чи ні; це те, що ми хочемо відстежувати.
➡️ Знизу вгору означає: ми – команда маємо вдосконалюватися в цих сферах, а для цього нам потрібно зосередитися на цих речах. Тому ми визначаємо показники, які дозволять нам відстежувати прогрес команди у досягненні наших цілей, і ми можемо продемонструвати вам – керівництво, як саме воно покращило нашу роботу з часом.
Визначення хорошої метрики
Отже, що повинен містити будь-який хороший показник або як його описати?
Найважливішою властивістю є зміна поведінки. Це означає, що кожного разу, коли ви дивитесь на результат метрики, стає зрозуміло, що має змінитися всередині команди, щоб отримати покращення.
Тоді це має бути просто. Якщо ви не можете пояснити це кількома простими реченнями, щоб усі відповідні слухачі могли зрозуміти, тоді щось не дуже добре.
Хороший показник можна порівняти з часом. Зробіть знімок результатів через деякий час, а потім повторіть це пізніше. Розмістіть їх поруч. Якщо ви не можете порівняти два результати між собою, то вам слід ще раз подумати про цей показник.
Нарешті, краще, ніж чисті числа, де це можливо, робити це співвідношенням або відсотком. «10 нових відкритих дефектів під час спринту» не розкажуть багато. Це залежить від того, чи є у вас зазвичай один чи 100.
Ось кілька прикладів показників, які, на мою думку, відповідають усім критеріям визначення. Вони мають на увазі саме гнучкі команди. Є три основні категорії: продуктивність, якість і мораль.
Категорії метрики
Показники ефективності
Мета полягає в тому, щоб зрозуміти, наскільки команда вміє наздоганяти історії, скоєні під час спринту. Щоб оцінити, чи надмірні зобов’язання не є звичайною справою, чи перехідні історії є стандартом від спринту до спринту.
З точки зору гнучкості продуктивності, команда повинна прагнути забезпечити запланований вміст спринту, який команда взяла на себе зобов’язання на початку спринту.
Це не означає, що ми не будемо гнучкими в обміні історіями під час спринту. Але це завжди мають бути переговори, які ведуть до обміну, а не доповнення. Потенціал команди не зросте лише тому, що хтось додав нові історії всередині спринту.
Ми використовуємо цей показник, щоб стежити за такими випадками та направляти всіх у команді, щоб захистити свої можливості для спринту.
Це створює надійність і передбачуваність команди.
#1. Потужність спринту проти доставлених очок історії
Дивіться історію спринту щодо вмісту наданих сюжетних балів (SP) протягом спринтів.
- Невеликі відхилення від спринту до спринту в порядку. Величезні стрибки в будь-якому напрямку сигналізують про те, що щось не так.
- Загальна потужність спринту – доступний день для одного члена команди додає один до загальної потужності. Наприклад, якщо в команді 10 осіб і всі вони будуть доступні для повного спринту, тоді загальна кількість спринту становитиме 100.
Перевірте потужність спринту в порівнянні з виконаним SP від спринту до спринту. Якщо команда (під час планування) зобов’язується отримати значно більшу кількість SP, ніж зазвичай може виконати, підвищте цей ризик для команди.
Мета полягати в тому, щоб загальна запланована SP була рівною або меншою за загальну завершену SP за спринт.
Ви все ще можете мати більше завершених SP, ніж планувалося, якщо команда завершила (наприкінці спринту) усі заплановані історії, і команда все ще має можливість взяти додаткову історію.
- Якщо команда неодноразово надає менше SP, ніж планувалося, команді потрібно змінити свій план і взяти менше SP у наступному спринті.
Такі інструменти, як monday.com, Atlassian Jira або Asana, пропонують простий спосіб збереження та витягування очок історії для кожної історії в спринтах. Вони навіть можуть автоматично генерувати це для вас після кожного планування спринту.
#2. Діаграма вигорання
Це одна з метрик, яку, ймовірно, більшість команд зі скраму приховали десь на інформаційній панелі. Я погоджуюся, що це може навіть виглядати як марна річ. Команда рідко бере це до уваги. Швидше, менеджер любить вказувати, як історії дійсно виглядають на високому рівні та як вони не просуваються добре (оскільки всі вони відкриті протягом усього спринту).
Що я хотів би підкреслити, так це те, що незважаючи на це, ви як команда повинні піти і перевірити діаграму згоряння для вашого ж блага. Якщо всі історії відкриті протягом усього спринту і закриті лише в останній день спринту, це створює невпевненість усередині команди та щодо досягнення цілей спринту.
- Перегляньте свою спринтерську дошку, щоб знайти завершені історії.
- Зверніться до команди, щоб визначити, чому маленькі історії все ще залишаються відкритими, навіть якщо вони почалися на початку спринту.
- Працюйте з командою, щоб створити таке мислення, а не тримати історії відкритими довше, ніж потрібно.
- Ідеальна діаграма вигоряння зазвичай є теоретичним станом. Однак чим ближче ми до нього наближаємося, тим ефективніша робота з історією.
Інструменти гнучкого керування, такі як Asana, можуть автоматично генерувати для вас діаграму спалювання для кожного спринту.
Джерело: asana.com
#3. Спринт. Досягнення мети
Це відстежує відсоток цілей спринту, які ви досягли під час кожного спринту.
Ви документуєте цілі спринту окремо, наприклад, на сторінці Confluence / Jira для кожного спринту. Статус призначається незалежно від того, чи були вони виконані під час спринту.
Навіть якщо команда не завершила всі історії в спринті, вона все одно могла досягти цілі спринту (наприклад, бракує лише побічних історій).
Ми будемо прагнути до досягнення цілей спринту на 100% кожного спринту. Якщо це не так, дізнайтеся, чому заважає команда.
- Якщо в кожному спринті занадто багато паралельних тем, зменшіть їх кількість.
- Якщо під час спринту додається занадто багато спеціальних історій, зменшіть це значення, щоб це не вплинуло на вихідні цілі спринту.
- Якщо цілі спринту занадто великі або надто складні, спростіть їх. У будь-якому випадку немає сенсу мати великі спринтські цілі, не досягаючи їх до кінця спринту.
Показники якості коду
Це має відстежувати, наскільки хороший код з часом. Це допомагає підтримувати здорові процеси розвитку та зменшує час, витрачений на вирішення проблем. Або час простою розробника, викликаний очікуванням виконання коду під час розробки та тестування.
Джерело: azuredevopslabs.com
#1. Автоматизовані тести
Розробники створюють автоматизовані модульні тести для кожної внесеної ними зміни.
- Вимірюйте покриття коду за допомогою автоматизованих тестів – використовуйте Azure Pipelines або SonarCloud для запуску тестів. Прагніть до 85% покриття. Вище 90% не є ефективним.
- Переконайтеся, що створення автоматизованого модульного тесту є частиною визначення готового для нових історій.
- Наздогнати старе покриття тестування коду як частину технічних історій боргів у відставанні.
#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% часу кожного спринту.
Заключні слова
Кожному проекту врешті-решт знадобляться певні показники, чи тому, що керівництво хоче їх мати, чи тому, що команда вирішує виміряти свій власний успіх.
Найкраще, що ви можете зробити, це почати створювати свою бібліотеку показників, готових до вибору та використання; чим швидше тим краще. І при цьому переконайтеся, що ви завжди надаєте перевагу показникам, які змінюють поведінку.
Далі перевірте нездорові процеси, які можуть зіпсувати ваш спринт.