- PVSM.RU - https://www.pvsm.ru -
“Вы не можете управлять тем, что не можете измерить” — избитая фраза, которую любят употреблять консультанты на дорогостоящих тренингах. У многих людей выработалась аллергия к разного рода метрикам, из-за маниакального желания менеджеров навесить KPI куда только можно. Однако, без определенной системы измерений, невозможно говорить о систематическом улучшении качества программного продукта и процесса его разработки. В этой статье я расскажу о GQM (Goal — Question — Measure) подходе, который поможет определить действительно объективные метрики и приведу пару примеров.
Разрабатывая ПО, команды регулярно сталкиваются с проблемами неэффективности процесса и низкого качества продукта. Однако, проекты, содержащие несколько десятков тысяч строк кода, написанного сотнями разработчиков, невозможно охватить одним взглядом и принять какое-либо решение. В таких случаях, на помощь приходят специальные показатели, позволяющие “просветить” программный продукт.
Принимая решение о внесении изменений в продукт или процесс, команда начинает эксперимент, с целью проверить некоторую гипотезу. Каким образом можно понять, что гипотеза верна? Командам помогут заранее определенные метрики, характеризующие важные аспекты проводимого эксперимента.
Виктор Бэйзил предложил модель GQM ( Goal — Question — Metric; Цель — Вопрос — Показатель) [1]. Основная идея описывается тремя базовыми пунктами:
Для наглядности модель изображают в виде трехуровневой иерархической диаграммы.
Важные аспекты при построении GQM модели:
Предположим, наша цель — уменьшить время бездействия системы (время, когда система не доступна для пользователей). GQM модель для этой ситуации представлена на рисунке:
Цели могут быть, как техническими, так и процессными. Команда, к примеру, может определить метрики, которые помогут ей улучшить качество оценивания трудозатрат или эффективность различных стандартов написания кода. Ниже представлена GQM модель для определения эффективности того или иного стандарта написания программного кода:
В некоторых случаях цели команды слишком глобальны и требуют некоторой декомпозиции. В этом случае, на помощь приходит GQM+ подход [2], предполагающий построение дерева целей команды или целой компании и построения отдельной модели для каждой цели дерева. Цель “снизить время доставки функции клиенту (time to market)” — глобальна. Ее можно декомпозировать следующим образом:
Подводя итог, стоит отметить, что данный инструмент наиболее эффективен, когда команды разработки самостоятельно определяют свои цели по улучшению программного продукта и выявляют подходящие метрики. В случае, когда показатели навязываются сверху — эффективность GQM модели резко снижается, поскольку команда начинает воспринимать метрики, как инструмент контроля, а не как важный аспект процесса совершенствования продукта.
Ссылки:
Автор: Василий Зорин
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/263971
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/338120/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.