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)
- Нехтувати якістю заради завершення завдань

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

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

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

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

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

Kanban for Agile Teams - це авторський клас для охочих детально розібратися в практичній сутності Kanban-методу та навчитися застосовувати його у своїх аджайл командах.

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

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

тренінг
Євгеній Лабунський  

Дводенний поглиблений клас присвячений фасилітації у масштабі. Курс сертифікаційний, після закінчення учасники отримують іменні сертифікати ICAgile Agile Team Facilitation (ICP-ATF Certified professional). Від практики до просунутого рівня та масштабних зустрічей.

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

Certified Scrum Product Owner (CSPO) with Alexey Krivitsky (UA)

Ви не знаєте того, чого не знаєте. У цій програмі я зібрав увесь свій досвід (понад 20 років) роботи в продуктових, сервісних та аутсорсингових організаціях.
Це НЕ курс про основи ролі власника продукту в Scrum. Це інтенсивна насичена програма з гнучкого управління продуктами — від принципів до …

Certified Scrum Product Owner (CSPO) with Alexey Krivitsky (RU)

Вы не знаете того, чего вы не знаете. В этой программе я собрал весь свой опыт (более 20 лет) работы в продуктовых, сервисных и аутсорсинговых организациях.

Это НЕ курс про основы роли владельца продукта в Scrum. Мы не продаём пустышки. Это насыщенная интенсивная программа по гибкому …

Скільки це коштує?

Контракти, бюджети та розцінки. Ці три поняття можуть змусити найзатятіших практиків #NoEstimates (без оцінки) бігти в укриття. Але цього не варто робити.

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

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

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

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

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