Метрика программного обеспечения в гибких [закрытых] методологиях
5 ответов
Agile - это бизнес-ориентированная вещь, Agile - это максимизация ценности для клиента при минимизации потерь для обеспечения наиболее оптимальной рентабельности инвестиций . Это то, что нужно измерить. И для этого я использую систему, которую рекомендует Мэри Поппендик . Эта система основана на трех целостных измерениях, которые следует рассматривать как единый пакет:
- Время цикла
- От концепции продукта до первого выпуска или
- От запроса функции до развертывания функции или
- От обнаружения ошибки до разрешения
- Реализация бизнес-модели (без этого все остальное не имеет значения)
- P&L или
- ROI или
- Цель инвестиций
- Удовлетворенность клиентов
- например Net Promoter Score
Конечно, на уровне команды вы можете отслеживать такие вещи, как охват тестами, цикломатическая сложность, соответствие стандартам кодирования и т. Д., Но высокое качество - это не самоцель, это просто средство.Не поймите меня неправильно, я не говорю, что высокое качество не имеет значения, высокое качество является обязательным для достижения устойчивого темпа (и мы включаем «отсутствие увеличения технического долга» в наше определение готовности), но, тем не менее, цель заключается в том, чтобы чтобы доставить ценность клиенту быстрым и выгодным способом.
1.1) На LOC легко ответить
Они действительно зависят от используемого вами языка! Одна и та же функция может иметь большую разницу при написании на JAVA или Ruby, например
В не очень хорошо написанном программном обеспечении может быть больше строк, чем в хорошем!
1.2) Покрытие кода
ИМХО, вам следует использовать метрику, хотя она и не идеальна, но она должна дать вам хорошее представление о том, где вашему коду нужно больше тестов.
Только один момент, о котором вы должны позаботиться, это то, что он также зависит от языка. Могут возникнуть ситуации, когда у вас есть класс или метод, которые вам действительно не нужно тестировать! Например, класс только с геттерами и сеттерами.
2) Из (1) вы только что упомянули метрики кода, но, судя по вашему вопросу о скорости, вас интересуют метрики всего процесса создания, поэтому я бы перечислил некоторые из них:
Скорость: классический и, при правильном использовании он может довольно хорошо повысить производительность гибкой команды, поскольку вы будете знать, что ваша команда действительно может сделать в установленное время.
Сжигайте и сжигайте графики: они могут дать вам хорошее представление о том, как команда работает во время взаимодействия (спринт).
Что касается вопроса 1, я не вижу причин, по которым эти показатели могут быть плохими в Agile-процессе.
LOC обеспечивает измерение относительного размера. Хотя сравнение чисел между проектами не всегда полезно, оно может дать вам представление о темпах роста в рамках проекта. Если вы можете получить это, количество строк, измененных в течение спринта, также может быть полезно для отслеживания скорости или рефакторинга.
Покрытие кода (строк кода) дает вам общее представление о том, соответствует ли ваша команда минимальной планке автоматического тестирования в рамках проекта.
Что касается вопроса 2, сохраните пункты выше и еще несколько:
- LOC по сравнению с количеством тестов. По возможности поддерживайте отдельные соотношения для модульных, интеграционных и системных тестов.
- Среднее количество критериев приемлемости по сравнению с тестовыми сценариями (или тестами) для каждой истории. Это может помочь лучше понять, соответствует ли ваше тестирование цели рассказа.
- Количество обнаруженных дефектов
- Объем обнаруженных работ (часто фиксируется с помощью программного обеспечения для отслеживания Agile), который не был частью исходной оценки. Это поможет вам оценить, достаточно ли вы планируете.
- Отслеживание согласованности или отсутствия таковой скорости от спринта к спринту
- Хотя, вероятно, это не популярно и, вероятно, потенциально опасно, отслеживание оценок работы, выполненной для каждого разработчика. Хотя предполагается, что команды должны быть самоорганизованными и управляемыми, не все команды способны решать человеческие проблемы.
Независимо от методологии, есть некоторые базовые метрики, которые можно и нужно использовать.
Согласно S. Кан , наиболее важными являются следующие три:
- размер продукта
- количество дефектов, обнаруженных на заключительном этапе тестирования
- и количество дефектов, обнаруженных в полевых условиях.
Если это все, что вы отслеживаете, есть по крайней мере пять способов их использования:
- вычислить процент дефектов продукта (A)
- вычислить процент дефектов теста (B)
- определить желаемую цель для A и отслеживать производительность
- определять желаемую цель для B и отслеживать производительность
- оценивать корреляцию между A и B
- , если корреляция обнаружена, формировать метрику эффективности теста (B / A * 100%)
Хотя читать не обязательно интересно, Метрики и модели проектирования качества программного обеспечения предоставляет превосходный подробный обзор программной инженерии и показателей.
Просто добавлю
Почему LOC и Code Coverage of Tests менее чем идеальны:
Agile подчеркивает результат, а не выход (см. Agile Manifesto). Эти два показателя просто отслеживают результат. Кроме того, они не измеряют должным образом рефакторинг, который является жизненно важным аспектом Agile-процессов.
Еще одна метрика, которую стоит рассмотреть, - это Running Tested Features. Я не могу описать ее лучше, чем это: http://xprogramming.com/articles/jatrtsmetric/