|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Project Metrics for Software DevelopmentМатериал из CustisWikiПеревод статьи http://www.infoq.com/articles/project-metrics
СодержаниеВведениеC 2007 года, я участвовал в попытках померить успешность проектов по разработке ПО (с совершенно разными методами управления), чтобы отчитаться перед высшим руководством. Эта статья содержит некоторые выводы, которых я сделал пытаясь донести до широкой аудитории проблемы с которыми мы столкнулись, и как мы пытались с ними разделаться. В основном рассказ будет про метрики производительности, а не «прогресса выполнения», так как лично я верю, что последние фокусируются на настоящем и мало влияют на будущие достижения команды. Я рассматриваю метрики «прогресса» (объема выполненных работ и т. п.) как путь, помогающий вашей команде достичь цели вовремя, однако если они не будут отражать производительность команды, уменьшаются шансы на улучшение процессов. Например, если проджект-менеджер будет пугать всех чем-то типа «Выполненный Объем и Запланированные Сроки», то команда будет ломиться, нагоняя отставания без передыху и рефлексий — «что идет не так?», «как и что можно улучшить?» — ведь на это нет времени. Вот почему я считаю, что метрики «прогресса» может и полезны, но никак не достаточны. Должно быть вы помните знаменитую цитату — «Вы не можете управлять тем, что не можете измерить»[1], а если компания не способна управлять проектом по разработке софта, как узнать, что и как можно было бы улучшить? И какой реальный выхлоп дало какое-нибудь изменение? Например, смена методик и практик разработки (кто-нибудь наверняка подумал «переход от Каскада к Аджайлу»…)? Целью софтверной индустрии всегда были успешные проекты, однако измеряющие этот успех метрики невообразимо разношерстны. Наборы метрик зависят от используемой методологии, и могут между собой вообще не иметь ничего общего! Мы столкнулись с этим в Hewlett Packard, когда был разнобой проектов, использующих различные методологии, в результате чего высшее руководство получало коктейль из разных метрик. Да, товарищи аджайлисты, мы знаем, что ваши agile-проекты идеально метризуемы, причем данные собираются абсолютно легко и без отвлечения команды от конструктивного труда, однако набор этих метрик трудно как-то соотнести с проектами не погруженными в такие Agilе-практики, как velocity , cumulative flow и burndown. Что же делать, когда есть проекты как те, в которых все это есть, так и те, где нет? Управление процессом разработки софта требует определения мер над основными параметрами управления, что дает и контроль и направления для постоянного улучшения процесса. Три ключевых метрикиПосле нескольких попыток и исследований как внутри компании, так и во внешнем мире, мы закончили эту возню с огромным набором предложенных метрик (порядка двадцати), но затем, в Agile-стиле, мы усадили команду экспертов для ретроспективы каждой предложенной метрики. Первым делом мы выкинули все метрики, основанные на «размерах» — проекта, артефактов, кода, дистрибутивов — все то, чем обычно рулят софтовыми проектами в больших компаний. Мы просто жестко спросили себя — «хотим ли мы это мерить?». Ответ был — «нет», так как мы в первую очередь хотим набор простых метрик, не «про загрузку» команды, и при этом более полезных для определения командного опыта и производительности. Наконец мы решили «быть проще», и определили три ключевых IT-метрики:
На следующем рисунке мы показали, как можно агрегировать эту метрику по всей команде. Effort («трудозатраты») — это впрямую наблюдаемая величина, которую можно агрегировать по задачам, назначенным разным людям или командам, ее можно вычислять для отдельных задач, вех или фаз. «Запланированные трудозатраты» (Planned Effort) устанавливают для некоторой запланированной задачи, и уточняют при дальнейшем анализе или проектировании. «Затраченные трудозатраты» по некоторой задаче собирают при ее разработке, тестировании и техподдержке. У начинающих компаний обычно большие различия между «планом» и «фактом», далее, параллельно с тем, как команда набирается опыта, оценки и результат становятся все ближе. По нашему опыту, если за шесть месяцев оценки «плана» и «факта» так и не стали сходиться, команда должна провести ретроспективу, и найти причины этой проблемы, которые могут быть как внутри, так и вне команды. Определение такого Ключевого Ограничения, согласно Мери Поппендик[2], прекрасное место для начальных изменений.
Определение «простая задача» обычно всегда порождает жаркие споры. В конце концов мы определили это как «время, необходимое чтобы выпустить и внедрить что-то объемом часов в пять» (разумеется, многие простые задачи могут быть и меньше, но мы зафиксировали именно пять часов). В соответствие с определением «число простых задач поставляемых за 8-часовой рабочий день» формула будет следующей:
На этом рисунке видно, как эту метрику можно суммировать по команде. Очевидно, что с этой метрикой можно поспорить, и против нашего определения можно выдвинуть много разумных возражений, однако нам, как в любой приличной демократии, надо было найти какой-то устраивающий всех компромисс. А как только мы получили такую метрику, сразу стало возможным мониторить «здоровье проекта» по неделям, месяцам, отдельным ресурсам и т.п. Метрика производительности «начинается» на уровне отдельной задачи, затем ее можно «свернуть» до уровня релиза, фазы, и целиком уровня проекта. Вот эта картинка показывает общую производительность по двум схожим выпускам одного продукта, где работала одна и та же команда, причем измеряли, используя одни и те же метрики. Сначала эта команда работала шесть месяцев использую привычный старый добрый Waterfall (сначала весь анализ, потом кодирование и только потом тестирование), затем после того, как они перешли на Agile, был некоторый релиз, на который они также затратили более полугода. Померив нашей формулой оба релиза, мы обнаружили, то, что обычно предсказывает «Agile-партия»: в Waterfall-подходе куча работы переносится с одной фазы в другую (например, из кодирования в тестирование), что в долгосрочной перспективе мешает команде выпускать качественный продукт, и тем самым уменьшает производительность, определенную предыдущей формулой, ибо куча времени тратиться на переключение контекста при возникшей «многозадачности». Та же команда с использованием принципов и практик Agile, таких как итеративная разработка, сконцентированность на требуемых свойствах, и уклонение от преждевременной разработки (атака в первую очередь на высокоприоритетные требования и технологические риски), смогла существенно увеличить свою продуктивность. Используя одинаковую метрику стало возможным мерить и предсказуемость выпуска (для Agile-проектов), и также улучшать точность оценок по мере развития проекта.
Параллельно с регистрацией дефектов, мы также отслеживали производную метрику «удаление дефектов». Это нужно, чтобы оценить, какой процент проблем мы нашли на поздних стадиях (эти проблемы очевидно обошлись нам дороже), по сравнению с рано найденными. Сравнивая наши Agile и Waterfall проекты по этому параметру, мы опять обнаружили интересные особенности. На предущем рисунке видно, что в Agile-проекте более-менее постоянная частота дефектов на протяжении всего жизненного цикла, в то время как в Waterfall-проекте, наблюдается явный пик ближе к концу. Да, напомним, что информацию для этого сравнения мы собрали от двух разных, но примерно одинаковых по объему, релизов одного продукта, разработываемых одной и той же командой, но в разное время и с использованием этих двух подходов. Этот набор метрик постоянно собирался, анализировался, и использовался в отчетах. Мы собрали все метрики на «приборной доске проекта», чтобы информировать всех заинтересованных лиц и совместно анализировать результаты. КорреляцииНаблюдались очевидные корреляции между этими метриками, см. следующую таблицу.
ЗаключениеGuilherme Souto, один из наших ПМов в бразильском исследовательском подразделении, предложил несколько кратких советов, по практичному внедрению метрик:
Конечно, представленные метрики — это еще не все, и их применимость для принятия решений зависит от понимания всей цепочки событий, запустивших некоторое изменение в командной тенденции. Этот подход и определенный здесь набор метрик может не быть оптимальным решением для вашей команды, но мы пришли именно к этому и оно у нас работает. Надеемся, это сработает и у некоторых наших читателей, но разумеется, гарантий дать не можем. Ссылки
Дополнительная литература
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |