Project Metrics for Software Development

Ссылки сюда (1) →

Перевод статьи http://www.infoq.com/articles/project-metrics

Автор

Carlos Sirias.

Перевод

Стас Фомин.

Введение

C 2007 года, я участвовал в попытках померить успешность проектов по разработке ПО (с совершенно разными методами управления), чтобы отчитаться перед высшим руководством.

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

Я рассматриваю метрики «прогресса» (объема выполненных работ и т. п.) как путь, помогающий вашей команде достичь цели вовремя, однако если они не будут отражать производительность команды, уменьшаются шансы на улучшение процессов. Например, если проджект-менеджер будет пугать всех чем-то типа «Выполненный Объем и Запланированные Сроки», то команда будет ломиться, нагоняя отставания без передыху и рефлексий — «что идет не так?», «как и что можно улучшить?» — ведь на это нет времени. Вот почему я считаю, что метрики «прогресса» может и полезны, но никак не достаточны.

Должно быть вы помните знаменитую цитату — «Вы не можете управлять тем, что не можете измерить», а если компания не способна управлять проектом по разработке софта, как узнать, что и как можно было бы улучшить? И какой реальный выхлоп дало какое-нибудь изменение? Например, смена методик и практик разработки (кто-нибудь наверняка подумал «переход от Каскада к Аджайлу»…)?

Целью софтверной индустрии всегда были успешные проекты, однако измеряющие этот успех метрики невообразимо разношерстны. Наборы метрик зависят от используемой методологии, и могут между собой вообще не иметь ничего общего! Мы столкнулись с этим в Hewlett Packard, когда был разнобой проектов, использующих различные методологии, в результате чего высшее руководство получало коктейль из разных метрик.

Да, товарищи аджайлисты, мы знаем, что ваши agile-проекты идеально метризуемы, причем данные собираются абсолютно легко и без отвлечения команды от конструктивного труда, однако набор этих метрик трудно как-то соотнести с проектами не погруженными в такие Agilе-практики, как velocity , cumulative flow и burndown. Что же делать, когда есть проекты как те, в которых все это есть, так и те, где нет?

Управление процессом разработки софта требует определения мер над основными параметрами управления, что дает и контроль и направления для постоянного улучшения процесса.

Три ключевых метрики

После нескольких попыток и исследований как внутри компании, так и во внешнем мире, мы закончили эту возню с огромным набором предложенных метрик (порядка двадцати), но затем, в Agile-стиле, мы усадили команду экспертов для ретроспективы каждой предложенной метрики. Первым делом мы выкинули все метрики, основанные на «размерах» — проекта, артефактов, кода, дистрибутивов — все то, чем обычно рулят софтовыми проектами в больших компаний. Мы просто жестко спросили себя — «хотим ли мы это мерить?».

Ответ был — «нет», так как мы в первую очередь хотим набор простых метрик, не «про загрузку» команды, и при этом более полезных для определения командного опыта и производительности.

Наконец мы решили «быть проще», и определили три ключевых IT-метрики:

Трудозатраты (Effort)

общее время на задачу построения работающего продукта или сервиса. Запланированное время мы назвали Planned Effort, а реально затраченное время — Actual Effort. Измерять можно в человеко-часах или днях, в зависимости от специфики проекта. Задача — это часть из необходимого множества действий, по выполнению работы или решению проблемы. В общем, понятие достаточно общее как для каскадных, так и для agile-проектов, однако стоит понимать различия этих методологий по управлению задачами.

На следующем рисунке мы показали, как можно агрегировать эту метрику по всей команде.

Диаграммы совокупных личных трудозатрат и распределения реальных затрат по фазам проекта

Effort («трудозатраты») — это впрямую наблюдаемая величина, которую можно агрегировать по задачам, назначенным разным людям или командам, ее можно вычислять для отдельных задач, вех или фаз.

«Запланированные трудозатраты» (Planned Effort) устанавливают для некоторой запланированной задачи, и уточняют при дальнейшем анализе или проектировании.

«Затраченные трудозатраты» по некоторой задаче собирают при ее разработке, тестировании и техподдержке.

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

Производительность (Productivity)

Определяется, сколько «простых задач» может быть выполнено за день. Производительность можно вычислять на разных уровнях: для отдельных участников, для роли или профессионального профиля, для фазы проекта или для проекта целиком.

Определение «простая задача» обычно всегда порождает жаркие споры. В конце концов мы определили это как «время, необходимое чтобы выпустить и внедрить что-то объемом часов в пять» (разумеется, многие простые задачи могут быть и меньше, но мы зафиксировали именно пять часов).

В соответствие с определением «число простых задач поставляемых за 8-часовой рабочий день» формула будет следующей:

На этом рисунке видно, как эту метрику можно суммировать по команде.

Визуализация продуктивности (временная шкала)

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

Метрика производительности «начинается» на уровне отдельной задачи, затем ее можно «свернуть» до уровня релиза, фазы, и целиком уровня проекта.

Визуализация продуктивности «Waterfall против Agile»

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

Сначала эта команда работала шесть месяцев использую привычный старый добрый Waterfall (сначала весь анализ, потом кодирование и только потом тестирование), затем после того, как они перешли на Agile, был некоторый релиз, на который они также затратили более полугода.

Померив нашей формулой оба релиза, мы обнаружили, то, что обычно предсказывает «Agile-партия»: в Waterfall-подходе куча работы переносится с одной фазы в другую (например, из кодирования в тестирование), что в долгосрочной перспективе мешает команде выпускать качественный продукт, и тем самым уменьшает производительность, определенную предыдущей формулой, ибо куча времени тратиться на переключение контекста при возникшей «многозадачности».

Та же команда с использованием принципов и практик Agile, таких как итеративная разработка, сконцентированность на требуемых свойствах, и уклонение от преждевременной разработки (атака в первую очередь на высокоприоритетные требования и технологические риски), смогла существенно увеличить свою продуктивность.

Используя одинаковую метрику стало возможным мерить и предсказуемость выпуска (для Agile-проектов), и также улучшать точность оценок по мере развития проекта.

Качество (Quality)

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

Диаграмма Качества

Параллельно с регистрацией дефектов, мы также отслеживали производную метрику «удаление дефектов». Это нужно, чтобы оценить, какой процент проблем мы нашли на поздних стадиях (эти проблемы очевидно обошлись нам дороже), по сравнению с рано найденными.

Сравнивая наши Agile и Waterfall проекты по этому параметру, мы опять обнаружили интересные особенности.

Диаграмма «Удаляемые Дефекты»

На предущем рисунке видно, что в Agile-проекте более-менее постоянная частота дефектов на протяжении всего жизненного цикла, в то время как в Waterfall-проекте, наблюдается явный пик ближе к концу. Да, напомним, что информацию для этого сравнения мы собрали от двух разных, но примерно одинаковых по объему, релизов одного продукта, разработываемых одной и той же командой, но в разное время и с использованием этих двух подходов.

Этот набор метрик постоянно собирался, анализировался, и использовался в отчетах. Мы собрали все метрики на «приборной доске проекта», чтобы информировать всех заинтересованных лиц и совместно анализировать результаты.

Корреляции

Наблюдались очевидные корреляции между этими метриками, см. следующую таблицу.

Metric 1	Metric 2	Положительная зависимость	Отрицательная зависимость
Производительность (Productivity)	Плотность выпущенных дефектов	Высокая продуктивность вместе с высокой плотностью выпущенных дефектов это индикатор недостаточных для проекта запланированных трудозатрат на обеспечение качества. Хотя высокая производительность штука хорошая, нужно найти взаимовыгодный компромисс между производительностью и качеством, чтобы был оптимальный уровень производительности при достаточно хорошем качестве.	Высокая производительность с низкой плотностью выпущенных дефектов — хорошее, годное поведение. Тут команде имеет смысл поискать пути повышения производительности, сохраняя контроль-мониторинг над низким уровнем ошибок. Высокая плотность ошибок при низкой производительности означает необходимость усиления раннего обнаружения проблем — путем настройки процессов тестирования, или даже его автоматизации.
Производительность (Productivity)	Эффективность удаления дефектов	Высокая производительность при высокой эффективности удаления дефектов свидетельствует о хорошем балансе между производительностью и скоростью. Команда может попробовать дальнейшие улучшения производительности, продолжая отслеживать эффективность удаления дефектов.	Высокая производительность с низким уровнем удаления дефектов означает, что вложения в процессы обеспечения качества (QA) недостаточны. Высокая эффективность удаления дефектов при низкой продуктивности означает необходимость несколько большего внимания к качеству на протяжении всего цикла проекта.

Заключение

Guilherme Souto, один из наших ПМов в бразильском исследовательском подразделении, предложил несколько кратких советов, по практичному внедрению метрик:

• Метрики должны быть связаны с целями проекта или компании, чтобы было видно, чего мы достигли на пути к ним.
• Метрики должны быть максимально интегрированы в ежедневные процессы, чтобы избегать трат времени на сбор данных.
• Нужно проверить, что выбранные метрики охватывают разные области, и в конце концов определяют, успешен ли был проект.
• Метрики, имеют смысл только в контексте остальных метрик, как слова, имеющие смысл только внутри предложения. Поэтому нужно по возможности избегать анализа метрик по отдельности. Когда такое случается, команды слишком фокусируются на производительности, а нам приходиться выполнять роль злого следователя, рассматривая остальные переменные например, «а насколько сложен проект сам по себе?» или уровень качества производимого командой. И наконец, мы предостерегаем от совершенных нами ошибок, когда мы, ведомые изолированными метриками типа «производительность на фоне плановых сроков», жертвовали качеством и другими ресурсами.
• Бессмысленно использовать метрику, которую никак нельзя конструктивно использовать.
• Для метрик типа производительности, нужно определить целевые значения и диапазоны, чтобы команда их придерживалась, и в случае необходимости принимала корректирующие действия.

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

Дополнительная литература

• H T. Goranson, The Agile Virtual Enterprise: Cases, Metrics, Tools. Quorum Books. 2003.
• Dr. Cem Kaner, Software Engineer Metrics: What do they measure and how do we know? 10th International Software Metrics Symposium. 2004
• Rüdiger Lincke, Jonas Lundberg, Welf Löwe: Comparing software metrics tools. International Symposium on Software Testing and Analysis. 2008

---

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».