Измерение «успеха Agile-трансформации» на самом деле означает измерение успеха взаимодействия между IT и бизнесом, а также между бизнесом и его внешними клиентами. Измерение внутренних процессов и практик, которые IT-компании внедряют в рамках этой «трансформации», не имеет значения. Это подразумевает, что начинать нужно с тщательного определения границ, которые покажут очертания этого взаимодействия (который мы хотим измерить). К примеру, соответствие предназначению внешнего клиента может иметь большее значение, чем IT-операции. Это необходимо учитывать при определении метрик Agile-трансформации, особенно, если позже мы будем делать выводы о причинно-следственных связях.
Определение метрик Agile-трансформации, конечно же, будет всегда лежать в неком контексте, потому что каждая бизнес-организация индивидуальна. Но тем не менее, мы можем снова позаимствовать у Канбан-сообщества некоторые общие рекомендации о том, что искать. Их идейные лидеры говорят
о классификации показателей на 3 категории: показатели соответствия предназначению, показатели здоровья и драйверы улучшения. Используя эту структуру, когда мы говорим о «показателях Agile-трансформации», мы имеем в виду в основном первую категорию и, возможно, немного вторую. На их основе могут быть реализованы инициативы по улучшению, которые, возможно, будут управляться с помощью показателей, относящихся к третьей категории.
Показатель соответствия предназначению (также известный как KPI) — это показатель того, что нужно клиенту. Это ключевое различие: если показатель не является легко узнаваемым и значимым для клиента, то это не ключевой показатель эффективности. Другой ключевой характеристикой является то, что можно определить минимальный порог для его значения: если показатель опускается ниже порогового значения, бизнес ставит под угрозу отношения со своими клиентами (возможно, они уйдут, инициируют судебные иски и т. д.). Другими словами, бизнес больше не «соответствует предназначению». Затем мы можем измерить эффективность «Agile-трансформации», проанализировав, как значения KPI с течением времени сравниваются с соответствующими пороговыми значениями. Типичный KPI — это время доставки, которое измеряется с момента принятия и выполнения запроса клиента до момента его поставки в производство. Обычно, это хорошая метрика Agile-трансформации.
Индикаторы здоровья — это метрики, обращенные вовнутрь. На самом деле, клиенты не заботятся о них (или даже не понимают), но они показывают, как работает тот или иной аспект системы. Ключевой особенностью является то, что они не имеют прямого действия; они только предоставляют информацию, которую необходимо проанализировать и поместить в контекст. По мере изменения значения индикатора работоспособности мы можем сделать некоторые выводы о том, как работает система, или объяснить, почему что-то происходит (или нет), но это не обязательно ведёт к конкретным действиям. Яркий пример этого — подсчёт дефектов. Клиенты, безусловно, будут заботиться о качестве продукта, и мы можем сделать выводы об этом качестве, посмотрев, сколько у нас дефектов, но абсолютное количество дефектов не обязательно сделает продукт более или менее пригодным для использования. Может случиться так, что покупатели сочтут текущее качество «достаточно хорошим» независимо от количества дефектов.
Наконец,
метрики драйвера улучшения — это показатели, которые используются для влияния на поведение по отношению к конкретному изменению. Их ключевая особенность в том, что они временные: мы устанавливаем для них цель, и как только цель достигнута, метрика больше не нужна. Причина этого связана с непреднамеренным поведением, которое метрика может стимулировать у людей, что может привести к локальной оптимизации метрики за счёт других аспектов, что приведёт к глобальной субоптимизации системы. Здесь примером может служить покрытие кода модульными тестами: если мы определили, что данный сервис не соответствует предназначению, и причина связана с плохим покрытием модульными тестами, то установка целевого показателя минимального покрытия может повлиять на разработчиков, чтобы они работали над добавлением тестов для изменения ситуации.