Как выйти на новый уровень измерения показателей качества ИТ-продуктов
«Качество — это не действие, это привычка» — Аристотель. Эта цитата актуальна и сегодня, особенно когда речь идёт о ИТ-продуктах, процессах или командах. Качество должно стоять в центре всего, к чему стремится компания. Качество само по себе — субъективно, но механизм его оценки и измерения имеет огромное значение.
Компаниям, которые занимаются разработкой и выпуском приложений и продуктов, рекомендуем внедрить конкретные метрики измерения. Большинство компаний никак не измеряют качество. В лучшем случае команда тестирования готовит отчёты на основании найденных дефектов, а менеджер следит за ходом реализации проекта, опираясь на несколько метрик, о которых знает только он.
В статье мы описали некоторые показатели, которые позволят обеспечить и подтвердить качество не только процесса тестирования, но и всего жизненного цикла разработки ПО. Эти метрики помогут инженерам придерживаться подхода «качество прежде всего» и искать области улучшения и повышения эффективности продукта, а не использовать одни лишь метрики тестирования для отражения прогресса. Рассмотрим подход использования различных метрик в следующих областях:
- Разработка
- Тестирование
- Управление
- DevOps
Важно, чтобы сотрудники осознавали конечную пользу этих метрик: они нужны, чтобы отражать ценную информацию о командах, процессах и продуктах. Слепое создание «одноразовых» метрик, только потому что «так всегда делалось», является препятствием на пути компании к выстраиванию высокой культуры качества разрабатываемых продуктов.
Конечно, выбор конкретных метрик остаётся за командой, отвечающей за свою область разработки ПО. В этой статье мы рассмотрим базовые показатели, которые можно взять за основу и в дальнейшем развивать и модифицировать в соответствии с потребностями команды.
Показатели для оценки эффективности разработки
Насколько продуктивно работает команда разработчиков? Когда планировать релиз? Будет ли продукт полезен и удобен для пользователей? Чтобы ответы на эти вопросы не переходили в разряд философских, нужно опираться на цифры. Для этого и необходимы метрики разработки ПО.
В измерении и управлении продуктивностью разработчиков пока что нет единого международного стандарта качества. Высокотехнологичные IT-компании разрабатывают собственные метрики, и некоторые из них практически невозможно сравнить с традиционными KPI в других сферах бизнеса.
Наиболее распространённые метрики в разработке:
- Формальные метрики кода — количество строк кода, сложность кода, длина пути к инструкции и т. д. В современных командах разработки эти метрики считаются менее полезными.
- Показатели продуктивности разработчиков — количество затраченных часов / дней, объём выполненных задач, эффективность и качество кода. Эти метрики помогут понять, сколько времени и трудозатрат разработчики вкладывают в проект.
- Метрики Agile-процессов — время реализации проекта, время каждого цикла и скорость. Они измеряют прогресс команды разработчиков в создании новых функций ПО. Скорость Agile покажет, насколько продуктивна работа команды в течение одного спринта.
- Эксплуатационные метрики — среднее время между отказами (MTBF) и среднее время восстановления (MTTR). Позволяют проверить, как работает программное обеспечение на продакшене и насколько эффективно сотрудники его поддерживают.
- Удовлетворённость потребителя — индекс потребительской лояльности (NPS), индекс клиентских усилий (CES), показатель удовлетворённости клиентов после взаимодействия с вашим продуктом и т.д. Метрики помогут понять, насколько клиентов устраивает ваш продукт.
Всё менее актуальными считаются показатели количества отработанных часов, числа строк в тексте исходного кода (SLOC), функционального балла и количества дефектов. Для разработчиков работать больше — не значит работать лучше.
Многие команды вместо того, чтобы пытаться измерить непосредственно производительность программиста, смещают фокус на измерение всего, что препятствует предоставлять клиентам новые функции.
Когда ключевой показатель успеха — удовлетворённость клиента, намного эффективнее применять метрики, пришедшие из маркетинга: коэффициент конверсии, поведение пользователей или оценка отзывов.
Метрики для команды тестирования
Наиболее очевидным показателем качества в традиционной модели тестирования считается количество выявленных дефектов и скорость их обнаружения. Не путать с плотностью дефектов (Defect Density), что является отдельной метрикой. Общее количество выявленных дефектов — это числовое значение, и чем оно выше, тем считается ниже качество продукта. Другие метрики измерения качества для команды тестирования включают:
- Эффективность планирования — показывает соотношение затраченного и запланированного времени за определённый период.
- Производительность тестирования — отношение количества внесённых дефектов к времени, затраченному на тестирование.
- Производительность валидации дефектов — отношение количества проверенных дефектов к времени, затраченному на это.
- Активные дефекты по критичности — количество активных дефектов каждой критичности в определённый момент времени.
- FAD — functions as designed, спроектированная функция, которую по ошибке принимают за дефект. Метрика показывает отношение количества FAD к общему количеству внесённых дефектов за отчётный период.
- Время жизни дефекта — среднее время от момента внесения дефекта до его исправления.
- Процент отклоненных дефектов — отношение отклонённых дефектов к количеству всех проверенных дефектов.
- Прирост дефектов — отношение количества исправленных дефектов к количеству новых дефектов за отчётный период.
- Общая плотность дефектов — отношение количества активных дефектов в модуле к размеру модуля.
- TBR — процент дефектов, которые разработчик не смог воспроизвести из-за некачественного описания.
- Удаление старых дефектов низкой критичности — динамика изменения числа активных дефектов низкой критичности, старше определённого значения.
- Количество регрессионных дефектов — понимание и отслеживание источников появления регрессионных дефектов.
В отчётах также часто указывают такие показатели, как трудозатраты, связанные с тестированием, стабильность работы функций и т. д.
В традиционной структуре реализации проекта команды зачастую внедряют метрики, только потому что им это поручил сделать руководитель. А руководитель проекта хочет видеть цифры, которые, как правило, демонстрируют количество проведённых тестов, что означает: «чем больше тестов, тем лучше прогресс / качество решения».
Такой взгляд порождает неверный подход к метрикам, поскольку становится всё труднее показать ценность проведения тестирования и, что более важно, продемонстрировать реальное обеспечение качества.
Метрики для команды управления проектом
Существует множество областей, по которым командам следует использовать метрики для отчёта о прогрессе, эффективности и статусе проекта. Вот некоторые из них:
- Оценка состояния продукта. Имея визуальное или числовое представление о том, насколько «исправен» ваш продукт, вы сможете быстро определить, на чём стоит сосредоточить внимание, чтобы либо скорректировать, либо сохранить текущий план реализации проекта.
- Определение прогресса позволит вам понять, когда будет достигнута конкретная цель. Это также позволит увидеть препятствия, с которыми может столкнуться команда и которые мешают прогрессу и качеству продукта.
- Покрытие требований и отслеживаемость. Так вы быстро определите, где есть «западающие зоны», когда дело дойдёт до покрытия, и выявите области риска.
- Выявление неэффективных методов. Это касается релизов, доработки кода, определения ценности решения, времени выхода на рынок и т.д. Набор показателей, демонстрирующих неэффективные методы разработки продукта, поможет определить «западающие» области.
- Выделение рисков / проблемных зон. Благодаря этим метрикам вы поймёте, какие риски могут возникнуть как в продукте, так и в процессе разработки. Во многих метриках не всегда указывается степень риска, и это может негативно сказаться на отдельных процессах разработки.
- Окупаемость инвестиций. Количественная оценка того, как вложения или изменения стратегии помогли повысить качество продукта или производительность команды.
- Эффективность автоматизации поможет определить, позволяет ли ваша стратегия автоматизации поставлять на рынок более качественные продукты без существенных финансовых вложений.
- Скорость выхода на рынок / выпуска продукта. Пользователь хочет новое приложение и быстро. Спрос постоянно растёт, и понимание темпов выпуска новых функций на рынок поможет определить, насколько довольны пользователи.
Программа исследования и оценки качества DevOps (DORA)
В течение 7 лет группа DevOps Research and Assessment (DORA) из Google анализировала состояние DevOps в разных компаниях. С 2014 года эксперты изучили данные более 32 000 ИТ-специалистов по всему миру. В 2018 году DORA опубликовала книгу «Ускорение» («Accelerate»), в которой команда определила основной набор метрик по разработке и выпуску программного обеспечения. Эксперты пришли к выводу, что оценить качество DevOps можно по четырём ключевым показателям:
1. Время внесения изменений
Метрика показывает, сколько времени требуется команде для того, чтобы код успешно заработал в продакшене после того, как его зафиксировали в среде разработки. Чем меньше времени — тем лучше. Метрика помогает определить зрелость деливери или выделить неэффективные области процесса.
Более длительное время реализации зачастую можно объяснить такими причинами, как отсутствие конвейеров CI/CD, общих сред, отдельных команд разработки и тестирования. Продвинутые команды могут запустить код, успешно работающий в продакшене, за один день, в то время как другие команды могут проводить релиз только раз в месяц, квартал или даже полугодие.
Здесь есть риск, что вы попытаетесь выпустить слишком большой объём новых функций, что приведёт к негативному пользовательскому опыту или сбоям в работе продукта.
2. Частота внесения изменений
Метрика отвечает на вопрос — как часто ваша команда успешно делает релиз на продакшене? Чем чаще — тем лучше. Команды вносят небольшие, но частые изменения в продакшн, что в конечном итоге ускоряет выпуск новых функций для пользователя.
Дополнительным преимуществом здесь является то, что, поскольку эти изменения минимальные, риск производственных сбоев или регресса значительно снижается. Идеально, когда у вас столько автоматических тестов, что вы уверены в своём сервисе.
Продвинутые команды выпускают релизы максимально быстро, в то время как другие — раз в несколько месяцев. Частоту внесения изменений можно легко рассчитать. Это следует делать, чтобы иметь представление о том, как команды могут работать быстрее и есть ли другие препятствия, которые могут мешать более быстрому и частому релизу.
3. Коэффициент ошибок
Как бы вы ни старались, бывает так, что после релиза возникают ошибки. Коэффициент ошибок — процент релизов, которые привели к проблемам на продакшене. Чем их меньше — тем лучше.
Измеряя коэффициент ошибок, команда может оценить зрелость процесса разработки и выпуска решений. Метрика также поможет выявить проблемы, которые могли просочиться из более ранних этапов жизненного цикла продукта.
В фокусе команды всегда должно быть предоставление исправно работающих продуктов / функций, а не их количество. В идеале команды должны стремиться к практически нулевым показателям ошибок.
4. Время восстановления
Метрика показывает, сколько времени нужно команде, чтобы восстановить продукт после сбоя или ошибки на продакшене. Здесь фокус делается на возможности измерить надёжность вашего ПО и приложений. Сбои неизбежны, но способность быстро восстанавливаться после них является ключевым фактором успеха.
Продвинутые команды могут восстановить решение за несколько минут или часов, в то время как другие команды, у которых нет отлаженных процессов управления рисками, будут это делать гораздо дольше, иногда недели или даже месяцы. Как написано выше, более мелкие и повторяющиеся доработки снижают риск сбоев в работе продукта, что, в свою очередь, ведёт к положительному опыту пользователей.
Вывод
Мы рассмотрели подходы по использованию различного набора метрик для разработчиков, тестировщиков, менеджеров проекта и DevOps-команд. Прекрасно, когда решения в компании принимаются на основе фактов, но ещё лучше когда эти факты подкреплены цифрами и их можно сравнить друг с другом и переносить на реальный бизнес и реальный пользовательский опыт.
Мы описали лишь некоторые метрики, чтобы показать, что не существует какого-то одного способа измерения качества и надёжности решений и зрелости команд, однако в сочетании с другими инструментами они могут стать хорошей отправной точкой.
Показатели помогут командам принимать решения на основе данных, чтобы постоянно улучшать скорость поставки, методы и процессы и обеспечивать надёжность и качество ИТ-решений.
Метрики помогут сместить мышление специалистов с «Мы должны предоставить метрики, потому что нас об этом просят» на «Что же эти показатели на самом деле говорят о качестве наших продуктов?».
Наиболее эффективные команды стремятся к постоянному улучшению показателей измерения качества. А как именно измерять и улучшать метрики и как грамотно внедрить тестирование в разработку ПО вам подскажут QA-инженеры.