DORA Metrics English: How to Discuss Engineering Velocity (англійською)

Introduction

У сучасній інженерії програмного забезпечення, розмова про продуктивність команди змінилася від суб’єктивних вражень до вимірюваних результатів. Метрики DORA, розроблені командою DevOps Research and Assessment, надають інженерним лідерам словник, заснований на даних, для обговорення того, наскільки швидко і наскільки надійно доставляється програмне забезпечення. Незалежно від того, чи ви проводите ретроспективну, квартальну бізнес- оглядку, чи розмову з роботодавцем, знання цих термінів допоможе вам краще і чіткіше пояснити інженерну швидкість.

Докладніше: Метрична система метричної системи

** Частота розгортання ** — Як часто організація успішно випускає програмне забезпечення для виробництва. Команди з високою продуктивністю розгортають кілька разів на день; низькопродуктивні розгортають раз на місяць або рідше. Це один з двох основних показників пропускної здатності в структурі DORA.

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

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

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

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

“Наш рівень невдач змін підскочив до 40 відсотків після того, як ми зменшили охоплення автоматизованих тестів - це дані, які ми використовували, щоб виправдати реінвестування в трубопровід контролю якості.”

** MTTR ** — Середній час відновлення, середній час, який знадобиться для відновлення служби після аварії. Нижчий MTTR вказує на те, що команди можуть швидко виявити, діагностувати і виправити інциденти. Він часто використовується разом зі зміною ступеня невдачі для вимірювання надійності послуги.

• “Ми відстежуємо MTTR щотижня на інженерній панелі - наше поточне середнє 22 хвилини, а наша мета на наступний квартал менше 10 хвилин за допомогою кращої автоматизації runbook.” *

** Прохідність ** — загальний термін для опису обсягу роботи, яку команда виконає за певний проміжок часу. В інженерних контекстах це часто відноситься до кількості об’єднаних запитів на витяг, відправлених функцій або завершених історичних пунктів за спринт. Вона відрізняється від швидкості тим, що вона зосереджена на виході, а не на відносних зусиллях.

“Дані про пропускну здатність показують, що команда платформи обробляє приблизно на 30 відсотків більше запитів на скидання за тиждень, оскільки ми прийняли модель власника коду для маршрутизації перегляду.”

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

• “Коли ми намалювали час циклу на діаграмі розсіювання, ми виявили, що більшість завдань було виконано за менше ніж два дні, але довгий хвіст великих квитків перевищував наше середнє значення — тому ми ввели обмеження на кількість історій у п’ ять на квиток.” *

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

• “Ми ввели обмеження WIP на три активні завдання на інженера після спостереження, що вищі WIP прямо корелювали з більшими часами циклів і більшими в’язкими місцями перегляду.” *

** Вузький кут** — крок у процесі доставки, коли кількість роботи накопичується швидше, ніж її можна обробити, уповільнюючи весь конвеєр. Ідентифікація і розв’язання вузьких місць є центральною для інженерії потоків і поліпшення метрики DORA по всьому борту.

“Наші вправи з відображення потоку цінностей виявили, що перегляд коду був нашим основним в’язким місцем — запити на захоплення чекали в середньому два дні на перший перегляд, перш ніж будь-яка робота відновлювалася.”

Читання DORA-метрики в контексті

Метрики DORA найбільш корисні, коли їх читають разом, а не окремо. Команда може мати високу частоту розгортання, але зростаючу частоту невдач змін, що свідчить про те, що вони швидко доставляють, але обрізають кути на якість. Команда з низьким MTTR, але низькою частотою розгортання може мати відмінні процеси відновлення, але повільний, небажаний до ризику конвеєр доставки. Метою є поліпшення всіх чотирьох показників одночасно, що є відмітною рисою елітної команди DevOps.

При представленні цих показників керівництву, оформляйте їх з точки зору впливу на бізнес. Високий час для змін означає повільніше реагування на ринкові можливості. Висока частота невдач змін означає більше інциденту з клієнтом. Висока MTTR означає довші перерви. Низька частота розгортання означає меншу частоту доставки цінностей. Переклад технічних показників на бізнес-мову є основним навиком для інженерних менеджерів і DevOps лідерів.

Словник у практиці

Якщо ви берете участь у перегляді стану інженерії або оцінці зрілості DevOps, будьте готові використовувати ці терміни точно. Сказати “ми хочемо поліпшити швидкість” - це неоднозначно. Сказати «ми хочемо скоротити час циклу з 3,5 днів до менше ніж 2 днів і привести наш рівень невдач зміни нижче 10 відсотків» є вимірюваною, дієвою метою. ДОРА-система дає вам словниковий запас для того, щоб вести розмову другого типу.

Навигація Nuance: Вираз швидкості турботи в Slack

Фокус DORA на * швидкості * - по суті, наскільки швидко команда може надійно доставити цінність - часто обрамлюється такими показниками, як частота розгортання, час зміни і доступність послуг. Однак, перекладаючи цю концепцію в повсякденні розмови, особливо коли виражається занепокоєння щодо потенційних проблем, потрібно більш нюансований вираз, ніж просто “ми повинні збільшити нашу швидкість.” Це не тільки про швидкість; це про стійку швидкість і демонстрабельну доставку цінності.

Розглянемо такий сценарій: Ви переглядали запит на збирання нової можливості, і ви помітили декілька невеликих, неперевірених змін, які були внесені у реалізацію ядра. Опис PR короткий - “Виявлення деяких помилок” - і немає чітких вказівок на стратегію тестування або оцінку ризику. Простое “Мы должны ускорить это” не поможет. Замість цього, більш ефективним підходом може бути: «Я бачу багато невеликих змін тут без явного тестового покриття. Я ценую швидкий поворот, але це викликає занепокоєння щодо можливих рецесій і загальної стабільності. Может, мы могли бы обсудить разбивку задачи на более мелкие, индивидуально проверенные компоненты? Покращення нашого * темпу доставки * тут дозволить нам підтримувати вищу якість і зменшити ризик введення помилок. “Ця фраза використовує ключові слова, пов’язані з DORA - “регресія”, “стабільність”, “темп доставки” - демонструючи розуміння основних принципів.

Інший приклад: Під час зустрічі з планування спринту, розробник випускає можливості з мінімальною документацією або критеріями прийняття. Прямий запит “швидше” не зможе його розірвати. Більш конструктивний підхід може бути: «Сфокусуємося на тому, щоб кожна функція мала чіткі критерії прийняття * до того, як * ми розпочнемо розробку. Встановлення цих передових допоможе нам відстежувати наш прогрес проти цілі спринту і вимірювати, наскільки ефективно ми доставляємо цінність. Ми можемо використовувати такі показники, як час циклу, щоб зрозуміти, чи ми справді оптимізуємо наш робочий процес - чи ми витрачаємо занадто багато часу на переробку функцій через неясні вимоги? “Це підкреслює зв’язок між ясними цілями, вимірюваними результатами (часом циклу) і, врешті-решт, швидкістю.

Також важливо визнати, що просто * запит * на більшу швидкість може бути сприйнято як вимогливе або навіть критичне. Ключовим є розуміння ваших запитів і зосередження на спільному поліпшенні. Пам’ятайте, мета не в тому, щоб звинувачувати когось; це про співпрацю оптимізації процесу і послідовне надання цінності.

# Example: Using `git log` to analyze commit frequency (illustrative)
git log --author="John Doe" --since="2 weeks" --graph | head -20

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