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

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

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

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

Рекомендованные мероприятия

тренинг
Дмитрий Незабытовский, Александр Червинский  

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

тренинг
Craig Larman  

Learn with Craig Larman—the co-creator of LeSS—in this 3-day highly-participative course. Participants (senior managers, product developers, ...) explore a deep understanding of LeSS, Large-Scale Scrum, for lean & agile development with many teams working together on one product.

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

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

Рекомендованные статьи

Фасилітація чи модерація робочих зустрічей? У чому відмінність та внаслідок чого виграють Agile команди

Ретроспективи, наради, дейліки, зустрічі проєктних груп та інші форми обговорень займають багато часу, а керівники цього потребують понад 70 % робочого часу. Найчастіше учасники групових обговорень постають перед такими труднощами в організаціях:

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

По вопросам коучинга и корпоративных программ:

+380 93 4974661
hello@scrum.ua

По вопросам публичных классов, регистраций, счетов:

+380 95 7402380
hello@scrum.ua

По всем номерам телефонов - голос и telegram.

©2017 - 2022 Scrum Ukraine. Все права защищены.

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