Сумнівні метрики
Середня кількість дефектів на User Story. Тренд дефектів у динаміці (over time)
Що показує: фактично відображає тренд зменшення або збільшення якості на одну історію користувача. Цікаво розглядати в динаміці щонайменше за 2 місяці.
Вимагає адекватного ведення Backlog'а задач, де нарізка для команди йде у вигляді end-to-end функціональності, а також фактично заведення кожного дефекту (з прив'язкою його до певної задачі).
Негативні наслідки: на перший погляд, це корисна метрика, проте фактично вона стимулюватиме такі негативні наслідки:- Легко показати покращення просто не заводячи дефекти. У цього, однак, є й позитивний ефект - вам не доведеться витрачати час на заведення дефектів :) (позитив за умови, що команда виправляє проблеми без їхнього закріплення)- Якщо ви змусите тестування закріплювати всі дефекти, то підштовхнете команду до розшарування та конфлікту між розробкою та тестуванням.- Збільшується загальний час управління задачами шляхом збільшення часу на заведення, ре-тест, читання дефектів.
Різновид: кількість дефектів на Story Point, реліз, Epic тощо.Загальний вердикт - краще не використовувати, або робити це так, щоб ніхто не знав.
Burn Down Chart
Що показує: тренд спалювання часу/обсягу задач у відношенні до ідеального тренду.
Як це має бути (очікування)
Класичний Burn down показує, наскільки команда добре… трекає час. Ось приклад неефективної роботи у команді, де Burn down показуватиме ідеальний тренд:
Є спринт, у якому є 5 завдань. Команда починає виконувати 5 завдань одночасно, всі зайняті та відмінно списують час. І ось, кінець спринту і ... дуже багато дефектів щодо того, що щось не встигли або щось не склеїлося. Але 90% спринту ваш тренд за часом був ідеальним, ось як цей:
Але щось пішло не так, і ви дізналися про це пізно. Все тому, що:
Burn Down Chart не показує те, ЯК ви робите роботу.
Читаючи цей рядок багато хто скаже, що тоді варто будувати чарт у Story Points. Ваша думка буде слушною лише за наступних умов:
1. Задачі оцінені дрібно.
2. Ви виконуєте задачу за задачею, а не починаєте все одразу (це справедливо й у випадку з годинником).
Але все ж таки, доки історія не буде завершена, графік буде строго горизонтальний і, власне, нічого не показує. Як цей. Станом на 25-е число ви все ще не знаєте, чи зможете щось закрити і, чи вистачить вам часу.
Різновиди: Epic Burn Down, Release Burn Down. Уникайте всього, що «бернить даун».
Висновок: якщо хочете дивитися, як люди трекають час - burn down ваш вибір. Якщо хочете розуміти, як покращувати роботу команди, використовуйте фізичні дошки та інші візуалізації руху РОБОТИ.
Committed vs. Delivered
Мета: вимірювати обіцянки команди та факт. Дуже поширена серед менеджерів різних рівнів.
Що показує: показує, наскільки добре ваша команда вміє вас дурити. Жарт. Показує спринти, в яких вашу команду спитають "ДОКИ?". Це не жарт.
Дуже токсична метрика. Зазвичай призводить до того, що команда починає робити наступне (щось з цього або все одразу):
- Завищувати оцінки
- Занижувати оцінку продуктивності (velocity)
- Нехтувати якістю заради завершення завдань
Така проблема, що в ІТ все дуже відносно. Код і написання коду - дуже творчий процес, який складно оцінити за своєю суттю.
Використання цієї метрики веде до тотальної демотивації команди, появі фраз "ну ви ж обіцяли!" або "ви завжди щось обіцяєте, але не робите".
Ніколи не використовуйте цю метрику.
Comments