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

Agile-метрики команд. Частина 2. Хороші метрики

22 серп. 2022

Це український переклад статті Євгенія Лабунського, яка була написана ще в 2019 році. Її можна прочитати тут.

Burn-up Chart

Що це: показує, як ви з’їдаєте скоуп (обсяг) до дати або, навпаки, до якої дати буде зроблено цей обсяг скоупа.

Burn-up Chart

Зображення з https://spin.atomicobject.com/2016/03/31/burn-up-charts/

Що ми тут маємо:
- Вісь Х — спринти, вісь Y —обсяг. Обсяг міряємо в Story Points або штуках (кількості) завдань.
- Зелений тренд — фактично поспринтова Velocity команди.
- Синій тренд  —  поточний обсяг завдань та його зміна від спринту до спринту (тобто обсяг беклогу).
= Зелений тренд — як команда спринт за спринтом «споживає» беклог.

Що нам це дає? Ми можемо прогнозувати. Наприклад, коли буде зроблено весь цей обсяг завдань?

Alt Text

Чи що буде зроблено до Різдва?

Alt Text

У Agile світі ми віддаємо перевагу прогнозу «до дати», тому що обсяг завдань, як правило, зростає. Тому при плануванні «від обсягу» ви можете потрапити в ситуацію, коли «давайте ще доробимо це завдання, тому що без нього ніяк».

End-to-end time to market (Lead time)

Що це: ця метрика показує, скільки часу проходить із моменту появи ідеї до моменту її фактичної реалізації та появи на стороні користувача.

Часто в розробці команди вимірюють те, наскільки швидко вони роблять саму Feature, тобто скільки часу проходить із моменту початку роботи до продакшина.

Lead time

Проте набагато цікавіше те, скільки часу минуло загалом від ідеї до реалізації. Й ось чому:

Ви дізнаєтесь, скільки реально часу бізнес у середньому чекає одну фічу

А ще ви дізнаєтеся, скільки часу бовтаються завдання в беклозі абсолютно без діла. Але це вже інша метрика

Ефективність потоку (Flow Efficiency)

Будь-яка робота — це сукупність активних стадій, коли робота виконується, та стадій очікування, коли завдання очікує на виконання або наступній стадії.

Flow Efficiency 1

Flow Efficiency 2

Зображення з https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Наприклад, візьмемо спрощений процес розробки з погляду завдання:

Опрацювання деталей — Розробка — Тестування — Випуск

У такому ланцюгу «завдання» перебуватиме в активному стані тоді, коли над ним проводитиметься робота. Наприклад, коли програміст пише код. Щойно він закінчив, то з погляду завдання активна фаза закінчилася, тобто перейшла в стадію «очікування тестування». Тестувальник розпочне роботу тоді, коли звільниться з інших завдань.

Якщо ви вважаєте час, який витрачається на «роботу» над завданням, то є активний час, а так само час, який завдання проводить в очікуванні. І ви можете порахувати Ефективність потоку — співвідношення очікування та активної роботи.

Alt Text

Якщо працювали над завданням 1 день (затрекали час), а фактично між активною роботою вона провела 2 дні (час очікування), ефективність такого потоку = 1/(1+2) * 100 = 30 %

Це означає, що 70 % часу робота не ведеться, тобто завдання «простоює».

Кількість елементів у беклозі

Що міряє: міряє кількість елементів у беклозі :)

Навіщо міряти? Щоби розуміти, скільки сміття на вашому «складі». З погляду Lean беклог — це склад. Зайві складські запаси — один із видів втрат.

Alt Text

Як за будь-яким складом за беклогом потрібно доглядати, переглядати, оцінювати, чистити та інвентаризувати.

Чим більше ваш беклог — тим менше ви розумієте, що в ньому зберігається й тим менша його фактична актуальність

На додаток, чим більше всіх елементів, тим більше часу витрачається на догляд за ним, а також менша прозорість роботи в ньому.

Немає цифри, яка б ідентифікувала межу:) Це все дуже специфічно для команди/продукту/компанії. Просто пам’ятайте, що навряд чи варто зберігати завдання, яким кілька років, щоби «не забути» :)

Термін життя елемента беклогу

Попередня метрика тісно пов’язана з цією метрикою: чим старіше завдання в беклозі, тим менше сенсу вони мають.

Старість беклогу зазвичай говорить про такі проблеми:

  1. Накопичення: завдання створюються, щоби «не забути».
  2. Відсутність «власника» беклога. Тобто ставлення команди до нього, як до орендованої машини: ви не миєте її. Усім байдуже, що там у них робиться. Тобто з беклогом не працюють, не «грумлять».
  3. Власник продукту не вміє говорити НІ, тому додає все, що його просять.

Чим менший термін життя — тим зрозумілішим є контент беклогу, простіше з ним працювати й підвищується його актуальність.

Еволюція Definition of Done

Як виміряти роботу Scrum Master? Дуже просто. Потрібно зрозуміти те, наскільки росте Definition of Done його команди. Цим самим можна виміряти «дорослішання команди».

Definition of Done

Саме збільшення критеріїв готовності чудово відображає, наскільки зростає технічна усвідомленість команди, наскільки швидко ви можете робити зміни, наскільки швидкий зворотний зв’язок і наскільки ви близькі до клієнта.

Саме збільшення критеріїв готовності чудово відображає, наскільки зростає технічна усвідомленість команди, наскільки швидко ви можете робити зміни, наскільки швидкий зворотний зв’язок і наскільки близькі до клієнта.

Якщо команда рік сидить із критеріями «код написаний та протестований», то за минулі 12 місяців ви не почали більше Agile у вашій компанії. Ви лишилися на минулому рівні. Не розвинулися технічно, управлінсько та продуктово.

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

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

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. Всі права захищені.

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