“Вы не можете управлять тем, что не можете измерить” — избитая фраза, которую любят употреблять консультанты на дорогостоящих тренингах. У многих людей выработалась аллергия к разного рода метрикам, из-за маниакального желания менеджеров навесить KPI куда только можно. Однако, без определенной системы измерений, невозможно говорить о систематическом улучшении качества программного продукта и процесса его разработки. В этой статье я расскажу о GQM (Goal — Question — Measure) подходе, который поможет определить действительно объективные метрики и приведу пару примеров.




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

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

GQM модель

Виктор Бэйзил предложил модель GQM ( Goal — Question — Metric; Цель — Вопрос — Показатель) [1]. Основная идея описывается тремя базовыми пунктами:

1. Определите цель, которую вы хотите достичь.
2. Сформулируйте вопросы, характеризующие важные аспекты, связанные с поставленной целью.
3. Подберите метрики, позволяющие ответить на заданные вопросы.

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

Важные аспекты при построении GQM модели:

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

Примеры построения модели

Предположим, наша цель — уменьшить время бездействия системы (время, когда система не доступна для пользователей). GQM модель для этой ситуации представлена на рисунке:


Цели могут быть, как техническими, так и процессными. Команда, к примеру, может определить метрики, которые помогут ей улучшить качество оценивания трудозатрат или эффективность различных стандартов написания кода. Ниже представлена GQM модель для определения эффективности того или иного стандарта написания программного кода:


В некоторых случаях цели команды слишком глобальны и требуют некоторой декомпозиции. В этом случае, на помощь приходит GQM+ подход [2], предполагающий построение дерева целей команды или целой компании и построения отдельной модели для каждой цели дерева. Цель “снизить время доставки функции клиенту (time to market)” — глобальна. Ее можно декомпозировать следующим образом:


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

Ссылки:

1. Basili V. R. Software modeling and measurement: the Goal/Question/Metric paradigm. – 1992.
2. Basili V. et al. GQM+ Strategies in a Nutshell //Aligning Organizations Through Measurement. – Springer International Publishing, 2014. – С. 9-17.

Original source: habrahabr.ru (comments, light).