Аудит інженерних процесів: на що ми дивимося і чому

Коли команда доставляє повільно, причина майже ніколи не в інженерах. Зазвичай це чотири-п'ять конкретних тертя, яких ніхто не виміряв.

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

Почніть із чотирьох вимірювань

Ці чотири добре усталені і, що важливіше, діагностичні: кожен поганий результат вказує на конкретний клас проблеми.

Звичні знахідки

Code review — це вузьке місце, а не ворота якості

• Пул-реквести завеликі, щоб їх осмислено переглянути, тож review стає театром схвалення
• Немає очікувань щодо швидкості review, тож зміни лежать днями
• Один сеньйор — єдиний, хто апрувить: черга з одним віконцем

Розгортання — це подія

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

Робота насправді не визначена

• Тікети, які потребують розмови, перш ніж хтось зможе почати
• Немає спільного визначення готовності, тож робота стрибає між розробкою і QA
• Забагато роботи в процесі — усі зайняті, нічого не завершується

Що змінювати першим

1. Зробіть розгортання нудними — автоматизуйте, додайте відкат, відпрацюйте його. Усе інше покращується, щойно випуск стає безпечним.
2. Зменшіть розмір партії — менші зміни легше переглядати, безпечніше випускати, швидше діагностувати.
3. Встановіть SLA на review — години, а не дні, з другим апрувером, щоб одна людина ніколи не була вузьким місцем.
4. Обмежте роботу в процесі — завершувати важливіше, ніж починати.
5. Інструментуйте те, що відчувають клієнти, щоб інциденти знаходились усередині, а не приходили у скаргах.

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

Досліджуйте роботу без рейтингу людей за метриками

Зіставні задачі показують обмеження системи. Пояснюйте очікування й переробки, не прирівнюючи активність до продуктивності.

1. Оберіть кілька завершених змін, зокрема термінове виправлення.
2. Виміряйте черги, цикли рев'ю, передавання та труднощі розгортання.
3. Перевірте покращення з початковим показником і датою оцінки.

• DevOps консалтинг →
• postmortem найкращі практики →