«Невозможно управлять тем, что нельзя измерить» — это клише, которое консультанты любят использовать на дорогостоящих тренингах.
У многих людей возникла аллергия на различного рода метрики, из-за маниакального стремления менеджеров повесить KPI везде, где только можно.
Однако без конкретной системы измерений невозможно говорить о систематическом повышении качества программного продукта и процесса его разработки.
В этой статье я расскажу о подходе GQM (Цель – Вопрос – Мера), который поможет определить действительно объективные метрики и приведу пару примеров.
При разработке программного обеспечения команды регулярно сталкиваются с проблемами неэффективности процессов и низкого качества продукта.
Однако проекты, содержащие десятки тысяч строк кода, написанные сотнями разработчиков, невозможно охватить одним взглядом и принять какое-либо решение.
В таких случаях на помощь приходят специальные индикаторы, позволяющие «просветить» программный продукт. Принимая решение внести изменения в продукт или процесс, команда начинает эксперимент для проверки некоторой гипотезы.
Как узнать, что гипотеза верна? Командам помогут заранее заданные метрики, характеризующие важные аспекты проводимого эксперимента.
Модель GQM
Виктор Бэзил предложил модель GQM (Цель – Вопрос – Метрика; Цель – Вопрос – Индикатор) [1].Основная идея описывается тремя основными моментами:
- Определите цель, которую вы хотите достичь.
- Сформулируйте вопросы, характеризующие важные аспекты, связанные с целью.
- Выбирайте показатели, которые отвечают на заданные вопросы.
Важные аспекты при построении модели GQM:
- Формулируя цель, опирайтесь на критерии SMART. Это позволит избежать абстрактных философских целей.
- При выборе основных аспектов обращайте внимание не только на очевидные характеристики, но и на те характеристики, которые косвенно подвержены изменению.
- При определении важных характеристик необходимо учитывать используемые технологии, технологические процессы и средства разработки.
Все эти критерии влияют на то, какой показатель является наиболее подходящим в данном контексте.
Кроме того, необходимо выбрать те метрики, которые можно собирать автоматически или полуавтоматически, поскольку ручной сбор метрик чреват неверными результатами вывода.
Примеры построения модели
Допустим, наша цель — сократить время простоя системы (время, когда система недоступна для пользователей).
Модель GQM для этой ситуации представлена на рисунке: 
Цели могут быть как техническими, так и процессуальными.
Например, команда может определить метрики, которые помогут ей улучшить качество оценки усилий или эффективность различных стандартов кодирования.
Ниже представлена модель GQM для определения эффективности конкретного стандарта написания кода: 
В некоторых случаях цели команды слишком глобальны и требуют некоторой декомпозиции.
В этом случае на помощь приходит GQM+ подход [2], который предполагает построение дерева целей команды или всей компании и построение отдельной модели для каждой цели дерева.
Цель «сократить время доставки функции клиенту (time to market)» глобальна.
Его можно разложить следующим образом: 
Подводя итог, можно сказать, что этот инструмент наиболее эффективен, когда команды разработчиков самостоятельно Определите свои цели по улучшению программного продукта и определите соответствующие показатели.
В случае, когда показатели навязываются сверху, эффективность модели GQM резко снижается, поскольку команда начинает воспринимать метрики как инструмент контроля, а не как важный аспект процесса улучшения продукта.
Ссылки:
- Базили В.
Р.
Программное моделирование и измерение: парадигма «Цель/Вопрос/Метрика».
– 1992.
- Базили В.
и др.
Коротко о стратегиях GQM+ // Согласование организаций посредством измерений.
– Springer International Publishing, 2014. – стр.
9–17.
-
Postmaster.mail.ru – Умная Статистика
19 Oct, 24 -
Практика Ведения Крупных Проектов От Oracle
19 Oct, 24
