Гнучкі метрики – це інструменти вимірювання, призначені для моніторингу прогресу та успішності гнучкої команди проекту.
Правильно визначені метрики дозволяють оцінити продуктивність команди, якість роботи, ефективність тестування, а також загальну результативність та її динаміку в часі.
Головною метою гнучких метрик є надання командам можливості ідентифікувати сфери, що потребують покращення, та приймати рішення на основі об’єктивних даних, що сприятимуть створенню кращих продуктів в процесі розвитку команди.
У багатьох випадках компанії встановлюють метрики, які є або демонстративними, або просто необробленими числами, що демонструють постійне зростання. Хоча такі показники можуть добре виглядати на інформаційних панелях, вони часто є малокорисними для самої команди.
Їхня мета полягає не в тому, щоб надати реальну допомогу команді, а радше заповнити звіти для керівництва, що часто призводить до стратегічних рішень, які команда не розуміє.
Щоб відповідати таким неефективним показникам, команди можуть спотворювати власні процеси, щоб метрики виглядали позитивно. Однак, це не веде до реального покращення продуктивності команди.
Ключові підходи до метрик
Існує кілька способів класифікації метрик, але одним з основних є поділ на “зверху вниз” та “знизу вгору”.
➡️ Підхід “зверху вниз” означає, що керівництво визначає метрики, яких усі повинні дотримуватися, і основна мета команди полягає у досягненні потрібних показників. В такому підході не враховується думка команди, і головне – це виконання встановлених вимог.
➡️ Підхід “знизу вгору” передбачає, що команда сама визначає сфери, які потребують вдосконалення, і встановлює відповідні метрики для відстеження прогресу. Це дозволяє команді демонструвати керівництву, як саме покращується її робота з часом.
Критерії ефективної метрики
Які характеристики має мати ефективна метрика?
Найважливішою характеристикою є здатність метрики впливати на поведінку команди. Це означає, що аналіз результатів метрики повинен чітко показувати, які зміни потрібно внести в роботу команди для досягнення покращення.
Метрика також має бути зрозумілою. Якщо її неможливо пояснити кількома простими реченнями, так щоб усі зацікавлені сторони її зрозуміли, це означає, що метрика є неефективною.
Ефективну метрику можна порівнювати з часом. Зробіть знімок показників в один момент часу, а потім повторіть це через деякий час. Порівняння цих результатів дозволить побачити прогрес. Якщо порівняння результатів є неможливим, це свідчить про непридатність метрики.
Нарешті, ефективною є метрика, що подається у вигляді співвідношення або відсотка, а не як абсолютне число. Наприклад, «10 нових виявлених дефектів за спринт» не дає повної картини, оскільки кількість дефектів може варіюватися від 1 до 100.
Ось декілька прикладів метрик, які, на мою думку, відповідають зазначеним критеріям і є корисними для гнучких команд. Їх можна розділити на три основні категорії: продуктивність, якість та моральний стан.
Категорії метрик
Метрики продуктивності
Ці метрики допомагають оцінити, наскільки добре команда виконує заплановані на спринт завдання, а також виявити можливі проблеми, такі як надмірні зобов’язання чи перенесення завдань між спринтами.
З точки зору гнучкої продуктивності, команда повинна прагнути до виконання запланованого обсягу робіт, який вона взяла на себе на початку спринту.
Це не означає, що команда не має бути гнучкою під час спринту, однак, будь-які зміни повинні бути результатом переговорів, а не простого додавання нових завдань. Збільшення продуктивності команди не відбувається шляхом додавання нових історій протягом спринту.
Ці метрики використовуються для моніторингу ситуації та заохочення команди до захисту своїх можливостей виконання завдань протягом спринту.
Це сприяє надійності та прогнозованості роботи команди.
#1. Потужність спринту vs. виконані бали історії
Порівняйте потужність спринту з фактично доставленою кількістю балів історії (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. Співпраця в команді
Заохочуйте парне програмування.
- Створюйте пари для спільної роботи над завданнями, обмінюючись спостереженнями, знаннями та досягненнями. Розподіляйте підзавдання між різними членами команди.
Відстежуйте відгуки про код від колег.
- Колеги можуть запропонувати або ініціювати перевірку коду інших.
Метрику можна отримати з дошки monday.com/Asana/Jira з підзавдань.
Щонайменше 50% історій у спринті повинні бути поділені між членами команди. Якщо це значення менше, з’ясуйте причини та вживіть необхідних заходів.
Для добровільного рецензування відстежуйте історії за допомогою спеціальних підзавдань. На початку 20% історій коду, що рецензуються, є хорошим стартом. Поступово протягом спринтів ви повинні заохочувати команду до більшої співпраці та збільшити цю цифру до 50% історій коду за спринт.
#3. Технічний борг vs. нові функціональні історії
Джерело: atlassian.com
Можливість для команди вирішувати власні технічні борги підвищить задоволення команди від своєї роботи.
- Навпаки, накопичення проблем із технічним боргом без плану поступового їх вирішення демотивує команду. І рішення стане більш нестабільним, складним та важким для вирішення без суттєвої переробки.
Команда найкраще розуміє, що саме не так з рішенням, навіть якщо зацікавлені сторони або кінцеві користувачі цього не помічають. Такі історії найбільше впливають на саму команду розробників, а для зацікавлених сторін можуть бути невидимими. Ось чому важливо надати команді можливість працювати над історіями, які допомагають покращити процес розробки.
Мета полягає в тому, щоб відстежувати, скільки історій технічного боргу було вирішено з часом, і чи постійно збільшується беклог таких історій.
Команда може позначити історії як “TechDebt” у беклозі та пріоритизувати їх, щоб вони могли бути обрані першими в спринтах.
Залежно від поточного стану проекту та кількості виявлених технічних боргів, ви можете встановити ліміт на зростання беклогу TechDebt (не більше 10% від спринту до спринту).
Розставте пріоритети для технічних боргів та включайте їх у спринти, щоб контролювати їх зростання та забезпечити, щоб команда працювала над ними 10-20% часу кожного спринту.
Заключні слова
Кожному проекту зрештою потрібні певні метрики, або тому, що цього хоче керівництво, або тому, що команда вирішила вимірювати свій власний успіх.
Найкраще, що ви можете зробити – це почати створювати власну бібліотеку метрик, готових до вибору та використання. Чим раніше, тим краще. При цьому переконайтеся, що ви завжди надаєте перевагу метрикам, які змінюють поведінку.
Також перевірте нездорові процеси, які можуть погіршити ваш спринт.