Что такое метрики программной инженерии

Метрики программной инженерии это количественные показатели, с помощью которых оценивают, отслеживают и улучшают качество, эффективность и влияние процессов, продуктов и команд разработки программного обеспечения. При грамотном использовании они служат системным диагностическим инструментом: выявляют операционные узкие места, обосновывают погашение технического долга и согласуют инженерную деятельность с конкретными бизнес-результатами. При неграмотном искажают поведение, подтачивают доверие и вознаграждают как раз не то, что нужно.

Эта книга существует потому, что большинство команд хватаются за метрики, не решив, для чего метрика нужна. Дашборд заполняется всем, что легко посчитать, руководство начинает спрашивать «это число выросло или упало?», и за квартал команда уже оптимизирует число, а не тот результат, который оно должно было представлять. У этого сбоя есть имя: закон Гудхарта. Когда мера становится целью, она перестаёт быть хорошей мерой. Каждая тема этой книги написана с оглядкой на этот закон.

Две базовые модели

Отрасль в основном сошлась на двух исследовательских моделях для измерения инженерной поставки и здоровья команды.

Метрики DORA (из программы DevOps Research and Assessment) измеряют пропускную способность и стабильность системы: частоту развёртываний, время выполнения изменений, долю неудачных изменений и время восстановления после неудачного развёртывания. Часть 2 этой книги рассматривает все четыре в одной справочной теме, наряду с Flow Framework, который мы используем для более широкой организации метрик поставки и потока, потому что DORA хорошо измеряет механику конвейера, но ничего не говорит о том, какая ценность по нему течёт.

Модель SPACE, созданная исследователями из Microsoft, GitHub и Университета Виктории, уравновешивает сырую пропускную способность опытом разработчиков по пяти измерениям: удовлетворённость и благополучие, производительность, активность, коммуникация и сотрудничество, эффективность и поток. Часть 3 разбирает её подробно.

Помимо этих двух моделей, команды отслеживают локальные метрики, сгруппированные по областям: метрики кода и качества (часть 4), продуктовые и бизнес-метрики (часть 5) и метрики надёжности, эксплуатации и безопасности (часть 6). Часть 7 посвящена сдвигу, который уже идёт: инструменты генеративного ИИ сделали выпуск сырого кода почти бесплатным, а значит, некоторые метрики, на которые отрасль опиралась десятилетие, больше не значат того, что значили раньше.

Для кого эта книга

Основные читатели это те, кто выбирает, что и зачем измеряет команда: инженерные руководители, staff- и principal-инженеры, платформенные команды и команды DevOps, а также программные и продуктовые менеджеры, которые впервые строят дашборд метрик или скоркард либо чинят тот, что начал искажать поведение. Второстепенные читатели это все инженеры, которые хотят понять, почему их организация отслеживает то, что отслеживает, и как возразить, когда метрику используют неправильно.

Как читать

Начните отсюда, затем прочитайте введение, чтобы увидеть, как устроена книга, или переходите сразу к оглавлению. Каждая тема самодостаточна: она сначала излагает принцип, даёт конкретные рекомендации, называет способ, которым манипулируют рассматриваемой метрикой, и заканчивается моделью зрелости, вопросами для обсуждения и источниками. Читать книгу от корки до корки, чтобы извлечь из неё пользу, не обязательно.