Agile-метрики. Частина 1. Сумнівні метрики | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

Agile-метрики. Частина 1. Сумнівні метрики

18 серп. 2022

Це український переклад статті Євгенія Лабунського, яка була написана ще в 2018 році на прохання допомогти з метриками від його дружини, Дар'ї Алімової. Стаття є результатом їхнього багатогодинного брейншторму, який доповнений особистими роздумами Євгенія щодо тієї чи іншої метрики. Російську версію матеріалу можна прочитати тут.

Сумнівні метрики

Середня кількість дефектів на User Story. Тренд дефектів у динаміці (over time)

Що показує: фактично відображає тренд зменшення або збільшення якості на одну історію користувача. Цікаво розглядати в динаміці щонайменше за 2 місяці.

defects user story

Вимагає адекватного ведення Backlog'а задач, де нарізка для команди йде у вигляді end-to-end функціональності, а також фактично заведення кожного дефекту (з прив'язкою його до певної задачі).

Негативні наслідки: на перший погляд, це корисна метрика, проте фактично вона стимулюватиме такі негативні наслідки:
- Легко показати покращення просто не заводячи дефекти. У цього, однак, є й позитивний ефект - вам не доведеться витрачати час на заведення дефектів :) (позитив за умови, що команда виправляє проблеми без їхнього закріплення)
- Якщо ви змусите тестування закріплювати всі дефекти, то підштовхнете команду до розшарування та конфлікту між розробкою та тестуванням.
- Збільшується загальний час управління задачами шляхом збільшення часу на заведення, ре-тест, читання дефектів.

Різновид: кількість дефектів на Story Point, реліз, Epic тощо.
Загальний вердикт - краще не використовувати, або робити це так, щоб ніхто не знав.

Burn Down Chart

Що показує: тренд спалювання часу/обсягу задач у відношенні до ідеального тренду.

Як це має бути (очікування)

Burn Down Chart 1

Класичний Burn down показує, наскільки команда добре… трекає час. Ось приклад неефективної роботи у команді, де Burn down показуватиме ідеальний тренд:
Є спринт, у якому є 5 завдань. Команда починає виконувати 5 завдань одночасно, всі зайняті та відмінно списують час. І ось, кінець спринту і ... дуже багато дефектів щодо того, що щось не встигли або щось не склеїлося. Але 90% спринту ваш тренд за часом був ідеальним, ось як цей:

Burn Down Chart 2

Але щось пішло не так, і ви дізналися про це пізно. Все тому, що:

Burn Down Chart не показує те, ЯК ви робите роботу.

Читаючи цей рядок багато хто скаже, що тоді варто будувати чарт у Story Points. Ваша думка буде слушною лише за наступних умов:
1. Задачі оцінені дрібно
2. Ви виконуєте задачу за задачею, а не починаєте все одразу (це справедливо й у випадку з годинником)

Але все ж таки, доки історія не буде завершена, графік буде строго горизонтальний і, власне, нічого не показує. Як цей. Станом на 25-е число ви все ще не знаєте, чи зможете щось закрити і, чи вистачить вам часу.

Burn Down Chart 3

Різновиди: Epic Burn Down, Release Burn Down. Уникайте всього, що «бернить даун».

Висновок: якщо хочете дивитися, як люди трекають час  - burn down ваш вибір. Якщо хочете розуміти, як покращувати роботу команди, використовуйте фізичні дошки та інші візуалізації руху РОБОТИ.

Committed vs. Delivered

Мета: вимірювати обіцянки команди та факт. Дуже поширена серед менеджерів різних рівнів.

Committed Delivered

Що показує: показує, наскільки добре ваша команда вміє вас дурити. Жарт. Показує спринти, в яких вашу команду спитають "ДОКИ?". Це не жарт.
Дуже токсична метрика. Зазвичай призводить до того, що команда починає робити наступне (щось з цього або все одразу):
- Завищувати оцінки
- Занижувати оцінку продуктивності (velocity)
- Нехтувати якістю заради завершення завдань

Така проблема, що в ІТ все дуже відносно. Код і написання коду - дуже творчий процес, який складно оцінити за своєю суттю.

Використання цієї метрики веде до тотальної демотивації команди, появі фраз "ну ви ж обіцяли!" або "ви завжди щось обіцяєте, але не робите".

Ніколи не використовуйте цю метрику.

Рекомендовані заходи

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Дмитро Незабитовський  

Дводенний курс з основ Agile, Scrum фреймворку та Kanban-методу. Курс сертифікаційний, після закінчення учасники отримують іменні сертифікати ICAgile Certified Professional (ICP): Scrum & Kanban.

Рекомендовані статті

Скільки коштують ваші зустрічі? Та як не втрачати гроші.

Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …

Top 5 питань про Agile Retrospectives

Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

Чому коучинговий підхід актуальний у бізнесі?

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

©2017 - 2024 Scrum Ukraine. Всі права захищені.

Політика конфіденційності