[Перевод] 9 метрик, которые могут иметь значение для современных команд по разработке ПО

?v=1

Перевод статьи подготовлен в преддверии старта курса «Team Lead 2.0».
Как я отмечал в статье «Why metrics don«t matter in software development unless you pair them with business goals», выбор метрик нужно продумывать очень тщательно, чтобы дать ответы на вопросы, которые ставит перед собой бизнес. Вот эта критическая точка: измерения должны быть спроектированы так, чтобы отвечать на вопросы бизнеса. И эти вопросы никогда не будут звучать как «Сколько у нас сейчас тысяч строк кода в проекте?»

В этой статье продолжается тема, начатая в предыдущей. Сначала мы поговорим о конкретных метриках, которые должна использовать каждая команда, или по крайней мере планирует использовать для того, чтобы заметно улучшить производительность. Обратите внимание, что название этой статьи начинается как »9 метрик, которые МОГУТ иметь значение…», потому что важно именно то, как эти метрики повышают ценность бизнеса. Как вы их будете использовать зависит только от вас. Завершим мы статью рассказом о том, как осмысленно сочетать эти метрики между собой, а также сформулируем и проверим гипотезу о ценности бизнеса.

Начните с измерения правильных вещей


Здесь представлены 9 объективных показателей (или метрик), которые необходимо постоянно отслеживать, чтобы инкрементально улучшать процессы и производственную среду. Улучшение этих показателей не гарантирует, что уровень удовлетворенности ваших клиентов будет расти не по дням, а по часам. Однако, это те показатели, которые действительно нужно мониторить. В одном из последующих разделов «Собираем все вместе», вы узнаете почему.

Метрики Agile-процесса


Для agile и lean-процессов основными метриками будут leadtime, cycle time, velocity команды, и open/close коэффициент. Эти показатели помогают в планировании и принятии решений по улучшению процессов. Несмотря на то, что они не измеряют успешность или добавочную ценность, не имеют ничего общего с объективным качеством программного обеспечения, вам все равно нужно их отслеживать. Ниже я объясню почему.

  • Leadtime — время, которое проходит от появления идеи до поставки программного обеспечения. Если вы хотите быстрее реагировать на нужды своих клиентов, работайте над уменьшением leadtime, зачастую посредством упрощения процесса принятия решений и сокращения времени ожидания. Leadtime включает в себя cycle time.
  • Сycle time — количество времени, которое требуется на внесение изменений в систему ПО и доставку этих изменений на продакшн. Команды, использующие continuous delivery, могут измерять cycle time в минутах или даже секундах вместо месяцев.
  • Velocity команды — количество единиц программного обеспечения, которое команда обычно выполняет в одну итерацию (спринт). Это число следует использовать только для планирования итераций. Сравнивать команды по показателю velocity — идея бессмысленная, поскольку метрика основана на необъективных оценках. Рассматривать velocity как показатель успешности тоже бесполезно, да и постановка цели вроде «придерживаться определенной velocity» искажает ценность этой метрики для мероприятий по оценке и планированию.
  • open/close коэффициент — количество появившихся и закрытых issue в единицу времени. Общая тенденция будет иметь большее значение, чем конкретные цифры.


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

Вы не можете точно знать или хотя бы предполагать откуда берутся те или иные цифры, но эти метрики дадут вам понимание того, где и на какие процессы стоит обратить внимание. Например, высокий показатель open и низкий close в течение нескольких итераций может означать, что issue продакшена сейчас имеют более низкий приоритет, чем новые функции, или, возможно команда сосредоточена на сокращении технического долга и исправления целых классов проблем, или же, что единственный человек, который знал, как их исправить уволился или с ним что-то случилось. Из чисел вы первопричину точно не узнаете.

Аналитика продакшена


  • Средняя наработка на отказ (Mean time between failures, MTBF)
  • Среднее время восстановления (Mean time to recover/repair, MTTR)


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

Частота сбоев приложения — количество раз, которое приложение «падает», деленное на количество использований. Этот показатель напрямую связан с MTBF и MTTR.

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

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

Помимо MTBF и MTTR, более точные метрики основаны на отдельных транзакциях, приложениях и т.д., и они отражают доставленную бизнес-ценность, а также стоимость устранения сбоев. Если ваше приложение для обработки транзакций падает один раз из ста, но при этом поднимается через 1–2 секунды без критических потерь информации, то и с частотой сбоев в 1% можно жить. Но если с такой частотой падает приложение, которое обрабатывает 100 000 транзакций в день, теряет по 100$ за сбой и восстановление стоит 50$, то исправление этого 1% будет в приоритете. И такое исправление в итоге сильно повлияет на итоговую ситуацию.

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


Безопасность — важный аспект качества программного обеспечения, который на поздних этапах разработки (или последующих этапах жизненного цикла) часто упускается. Инструменты анализа безопасности могут использоваться в процессе сборки вместе с более специализированными методами оценки и стресс-тестами. Требования к безопасности согласуются со здравым смыслом, но команда разработчиков должна всегда о них помнить, ровно как и о метриках от них происходящих.

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

  • Инциденты на конечных точках — количество конечных точек (мобильных устройств, рабочих станций и т.д.), на которых был обнаружен вирус в течение определенного времени.
  • MTTR (среднее время наработки на отказ) — в терминах безопасности — это время между обнаружением нарушения безопасности системы и развертыванием и работой средства защиты. Как и в случае с MTTR, о котором мы говорили в метриках продакшена, вопрос безопасности должен отслеживаться в течение определенных временных интервалов. Если значение MTTR со временем уменьшается, то разработчики работают эффективнее и лучше понимают проблемы безопасности, находят ошибки и устраняют их.


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

Вы найдете больше способов применения метрик безопасности в разработке программного обеспечения в статьях Application Security for Agile Projects и Security Threat Models: An Agile Introduction.

Заметка о метриках исходного кода


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

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

Допустим, вы обнаружили в классе метод с нелепым значением показателя сложности NPATH в 52 миллиона. То есть потребуется 52 миллиона тест-кейсов, чтобы протестировать каждый вариант выполнения метода. Вы можете отрефакторить код и получить более простую структуру, но прежде, чем это сделать, подумайте о том, как это отразится на бизнес-логике. Скорее всего этот старый страшный код работает достаточно хорошо (несмотря на то, что он может быть не полностью покрыт тестами). Ценным будет показать этот антипаттерн своей команде, чтобы они так больше не делали, поскольку фикс этого метода в целом не изменит ни одну стоящую бизнес-метрику.

Лучше всего, если команда согласится с уровнем требований и правилами, которым отвечает их код, но имейте в виду, что изучение аномалий и беспокойство на тему появления каких-либо закономерностей может отнимать время.

Соберем все вместе: Успех — универсальная метрика


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

Как использовать метрики для достижения успеха


У бизнеса есть цели. В целях кроются вопросы, например: «Как выглядит успех?» или «Как продукт повлияет на поведение клиентов?». Правильно сформулированные вопросы таят в себе метрики.

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

Разве не все у всех проектов есть некоторый набор инвариантных целей, вопросов и гипотез, а следовательно, и метрик?

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

На более тонком уровне разрешения каждая функция и User Story могут иметь свой собственный показатель успеха — предпочтительнее, чтобы он был единственным и был связан непосредственно с ценностью, которая доставляется клиенту. Закрытие 9 из 10 историй за спринт для функций, которые остаются недоставленными — это не успех, а поражение. Доставка историй, которые клиентам не нужны, и они их не используют — не успех, а пустая трата времени и сил. Создание историй, которые делают пользователя немного счастливее — вот это успех. Создание истории, которая не улучшила взаимодействие с пользователями, тоже своего рода успех, поскольку теперь вы знаете, что эта бизнес-гипотеза не работает, и можете освободить ресурсы для поиска других идей.

Как сформулировать ценностную гипотезу


Ценностная гипотеза — это утверждение о том, что, по вашему мнению, произойдет в результате добавления определенной функции. Взаимосвязь между программным обеспечением, желаемым результатом и метриками формирует ценностную гипотезу для функции (или системы, истории, обновления и т.д.). Гипотеза должна выражать ожидаемое изменение целевой метрики в течение определённого промежутка времени, а также понятие о ее эффективности. Вам нужно будет поговорить с командой и с Product Owner-ом, чтобы как минимум выяснить, что именно это функция или история может создать или улучшить применительно к бизнесу, чтобы сформулировать относительно нее ценностную гипотезу. Возможно, задать вопрос «почему» вам придется несколько раз (как ребенку), чтобы избавиться от невысказанных предположений, поэтому будьте терпеливы. Когда вы поймете, какой должна быть ценность для бизнеса, вы можете начать задавать вопросы, которые приведут вас к метрикам, дающим на них ответы.

Например, «техническая» история о повышении скорости оформления заказа в интернет-магазине может иметь под собой идею о том, что ускорение продаж приведет к росту их количества. Но почему мы так думаем? Много ли людей оставляют корзины с товарами во время процесса оформления заказа? Если вы пришли к консенсусу (подкрепили свои предположения данными), то ценностная гипотеза может быть звучать так: «Мы считаем, что ускорение процесса оформления заказа приведет к снижению коэффициента «отказа от корзины». В свою очередь это приведет к увеличению продаж и улучшению пользовательского опыта.»

Вероятно, вы предполагаете, что пользователям понравится ускорение оформления заказа, но не будет лишним спросить, заметили ли они это вообще. Коэффициент отказа от корзины и продажи можно замерить в течение определенного времени до внедрения нового процесса и после. Если коэффициент отказа от корзины падает, а продажи увеличиваются (с учетом статистических колебаний), то доказательства подтверждают гипотезу, и вы можете задаться вопросом, оправдано ли дальнейшее увеличение скорости оформления покупки. Если нет, то пускай эта метрика отойдет на задний план (или вообще исключите ее, чтобы не отвлекала), и переключите свое внимание на следующую гипотезу. Если коэффициент отказа от корзины уменьшается, а продажи остаются неизменными, проводите измерения дольше или попробуйте переосмыслить предполагаемую связь между отказом от корзины и продажами. Другими словами, используйте метрики, которые приносят значимые улучшения для того, чтобы учиться.

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

Шесть эвристик для эффективного использования метрик


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

  1. Метрики не расскажут вам всю историю, а вот команда расскажет (снимаю шляпу перед Тоддом Декапула);
  2. Сравнивать снежинки — это бесполезная трата времени.
  3. Вы можете измерить практически все, но не всему можете уделить внимание.
  4. Метрики успеха бизнеса способствуют улучшению программного обеспечения, а не наоборот.
  5. Каждая функция добавляет ценность, измеряете вы ее или нет.
  6. Измеряйте только те показатели, которые имеют значение в данный конкретный момент.


Еще



Узнать подробнее о курсе

© Habrahabr.ru