Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?

Сегодня я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те метрики, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.

Если тема заинтересовала, добро пожаловать под кат.

Метрики бизнеса, продукта и проекта

Для начала немного о метриках на более высоких уровнях.

• Показатели бизнеса мы измеряем стоимостью компании, стоимостью акций, долей на рынке, показателями роста. Эти показатели понятны и уже давно устоялись. Рост цен на акции — больше доходов у акционеров.
  Спускаясь ниже, бизнес делает некий продукт, приносящий пользователям определенную ценность.
• У продукта свои метрики, позволяющие с ним работать: стоимость привлечения клиента, retention, количество платных клиентов, отказавшихся от подписки и т.д. Эти метрики используются продукт-овнерами для развития продукта и и построения приоритетов. Бизнес использует эти метрики для прогнозирования своих показателей — прибыли, стоимости акций и т.д.
• У проектов свои метрики. Проекты мобильного приложения, сайта и пр. могут быть частью одного продукта. Проектовые метрики помогают менеджерам управлять проектом и реагировать на отклонения от нормы. Метрики скорости, capacity, lead time, если вы используете Kanban. Эти метрики так же помогают продукт-овнерам и владельцам бизнеса прогнозировать развитие. Связь снова прослеживается на уровень выше.
• Спускаясь ниже, попадаем на уровень кода, и вот тут начинаюся проблемы. Метрик, которые помогают проектовым менеджерам строить прогнозы относительно развития проекта, отсутствуют. Метрики сложности, количества дубликатов, покрытия тестами не помогают найти связь с метриками продукта и бизнесом. С тем, какие метрики помогут связать код с целями продукта и бизнеса, мы вас и познакомим.

Метрики кода

Поработав над несколькими проектами, как с малыми по 2-3 месяца, так и долгосрочными на 2-5 лет, исследовав десятки проектов с 2008 года, мы пришли к выводу, что команды используют похожие инструменты для оценки состояния кода.

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

Engineering Assessment Framework состоит из 9 вопросов, ответить на которые можно за 10 минут. Часть из вопросов завязаны на человеческий фактор, поэтому, собрать ответы из автоматической системы не получится. С течением времени мы будем адаптировать и улучшать вопросы, расширять метрики, чтобы они лучше описывали ситуацию, не забывая об обратной совместимости для тех, кто уже использует Engineering Assessment Framework

Поподробнее остановимся на том, что это за 9 вопросов, как к ним подходить и что такое карта приоритетов метрик

1. Сколько людей в команде могут объяснить каждый конкретный участок кода?
   Измеряет кроссфунцкиональность. Большинство команд понимают ценность, чтобы над любым куском приложения мог работать любой человек. Bus-factor, болезни, давно запланированные отпуска, отвлечения на сторонние митинги, встречи или поддержку старых проектов, которую скидывает менеджер. Отсутствие кроссфункциональности ведет к издержкам. Даже если у вас стабильная скорость в 10 поинтов в неделю, нет гарантий, что в следующую неделю вы сделаете 10 поинтов. Потому, что единственный специалист в текущей области, над которой работает команда, приболел.
2. Сколько ручных шагов необходимо выполнить для выхода на Production?
   Прямая отсылка к автоматизации. Автоматизация должна быть на всех фронтах, чтобы избежать человеческие ошибки, а так же, ускорить процедуру развертывания. Скорость доставки ценности для пользователя выходит на первый план.
   
3. Как быстро команда узнавала о том, что свежая сборка оказывается нерабочей?
   Скорость получения фидбека — важнейший элемент разработки. Снова к уровню автоматизации. Узнать о нерабочей сборке можно через 10 минут, если упадет билд. А можно через 2-3 дня, когда вы попросите проверить ее тестировщика, который сейчас занят, завтра у него выходной, послезавтра он придет и протестирует. А вы ведь за это время уже внесете изменения в код.
4. Как долго за последнюю неделю/итерацию свежая сборка оставалась нерабочей?
   Нерабочая сборка означает, что доставить ценность пользователю мы не можем. Все последующие изменения лишены смысла, поскольку сделаны на основе неправильных выводов. Если команда останавливает работу и мгновенно бросается исправлять нерабочую сборку — это хороший знак.
5. Технический долг увеличился или уменьшился за последнюю неделю/итерацию?
   Один из лучших вопросов. Часто приходилось слышать такое: «Ну, тут вот сделали так, надо бы отрефакторить, я ToDo написал, потом сделаем.»? Или «Все готовы, тесты только не написали, но на них сейчас времени нет, потом напишем». Такие «потом» могут расти как снежный ком, вгоняя проект в долговую яму. Технический долг придется отдавать. И чем выше он сейчас, тем выше будут проценты по нему.
6. Сколько изменений в проект команда отправляла в тестирование за 1 час?
   Опечатки нет. Именно за один час. Не день, не неделю, а час. Что такое изменение? Подвинули кнопку — изменение или нет? Изменение — любая модификация системы, приносящая пользователю некую ценность. Ценности должны быть связаны с целями бизнеса. Этот вопрос хорошо показывает, насколько команда умеет декомпозировать задачи. Причем не просто на технические задачи, а на те, что приносят ценность пользователям и бизнесу.
7. Сколько изменений вы выкатили на Production за последнюю неделю/итерацию?
   Еще один отсыл к автоматизации и декомпозиции, но больше сфокусирован на том, чтобы облегчить процедуру выхода на Production. Отвечая на этот вопрос, задумайтесь, сколько бюрократических шагов вы применяете? Сколько ревью перед выходом, каких-то дополнительных махинаций, которых можно избежать? Если процедура выхода на Production лишена этой шелухи, вы сможете быстрее и чаще доставлять пользователям ценность.
8. Сколько человек в команде отправляли код в центральный репозиторий хотя бы раз в день на протяжении недели/итерации?
   Feature-branch используют часто. Это подходит, когда каждая отдельная функциональная часть делается в своей ветке и когда-то будет отправлена в центральный репозиторий. Когда? А кто ж его знает? Обычно такой подход приводит к тому, что изменения не вливаются в центральный репозиторий на протяжении недель или даже месяцев. Чем дольше вы маринуете изменения в собственной ветке, тем сложнее вам интегрироваться в master. Мы в своей практике сталкивались с компаниями, в которых интеграция изменений занимает 1-2 месяца. Месяца, я не шучу!
   
9. Как быстро вы получаете обратную связь от тестов после написания одной строчки кода?
   Каждый раз, когда разработчики делают что-то новое, им нужен фидбек на то, что они делают. Фидбек от автоматических тестов получете спустя 5 секунд. Фидбек от тестировщика — через часы или даже дни. Чем быстрее вы получаете фидбек, тем быстрее скорректируете свои действия. Это как GPS. Представьте, если бы вы свернули не туда, а он бы только через пару часов оповещал вас об этом.

Эти 9 метрик дают возможность проектовым менеджерам и продукт-овнерам прогнозировать, когда будет сделана тот или иной функционал, когда мы подключим новых клиентов, когда бизнес будет занимать бОльшую долю рынка и когда, в конце-концов, акционеры и команда получат больше денег.

Приоритеты метрик

Чтобы определить, в какой момент времени какую метрику стоит улучшать, нужно понимать цели бизнеса и то, в какой стадии он находится сейчас. В стадии запуска нового продукта, когда каждый день промедления может стоить больших денег, потери доли на рынке или упущенного момента, можно, например, не обращать внимания на метрику 1, отвечающую за кроссфункциональность. В то же время, в быстром темпе, критически важна автоматизация и нужно как можно больше внимания уделять тем метрикам, которые показывают степень автоматизации при развертывании на Production. Технический долг также не критичен в самом начале, там он растет.

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

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



Зеленое поле в карте метрик означает, что на данном этапе она важна. Красное — приоритет этой метрики на данном этапе ниже остальных. Такие карты будут составляться индивидуально под каждый продукт и бизнес.

Выводы

В результате, получается набор метрик, который мы назвали Engineering Assessment Framework, показывающий:

• Степень кроссфункциональности команды
• Уровень автоматизации
• Фокусировка на доставке ценности пользователю (здесь отсылка к тому, насколько хорошо команда декомпозирует задачи, сохраняя в каждой ценность для пользователей и бизнеса)
• Качество кода (технический долг именно об этом)

Что дальше?

Сейчас мы набираем команды, которые хотят попробовать подход к измерению технического состояния проекта и будем работать с ними вплотную. Прежде всего для того, чтобы помочь им улучшить свои проекты, а так же, адаптировать метрики под конкретные случаи (такого тоже не исключаем). Не исключено, что со временем метрики притерпят изменения и устоятся уже по прошествии некоторого времени. Если готовы подключиться к такому эксперименту, пишите.