в Agile, Инженерка

Engineering Assessment: как измерить техническое состояние проекта?

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

Сегодня я расскажу о метриках на самом низком уровне создания 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, показывающий:

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

Что дальше?

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

 

Написать Комментарий

Комментарии