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 у вашій компанії. Ви лишилися на минулому рівні. Не розвинулися технічно, управлінсько та продуктово.

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

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

Двухдневный углубленный класс посвященный фасилитации. Курс сертификационный, по его окончанию участники получают именные сертификаты 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. Все права защищены.

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