StasFomin в 16:06, 5 сентября 2009

2009-09-05T16:06:21Z

Новая страница

http://www.infoq.com/articles/project-metrics

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

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

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

Должно быть вы помните знаменитую цитату — «Вы не можете управлять тем, что не можете измерить»<ref>"If you can't measure it, you can't manage it" — Tom DeMarco . Controlling Software Projects: Management, Measurement and Estimation. ''Prentice Hall''. 1986</ref>, а если компания не способна управлять проектом по разработке софта, как узнать, что и как можно было бы улучшить? И какой реальный выхлоп дало какое-нибудь изменение? Например, смена методик и практик разработки (кто-нибудь наверняка подумал «переход от Каскада к Аджайлу»…)?

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

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

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

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

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

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

Наконец мы решили «[[RuPedia:Принцип KISS|быть проще]]», и определили три ключевых IT-метрики:
;Трудозатраты (''Effort''): общее время на задачу построения работающего продукта или сервиса. Запланированное время мы назвали ''Planned Effort'', а реально затраченное время — ''Actual Effort''. Измерять можно в человеко-часах или днях, в зависимости от специфики проекта. ''Задача'' — это часть из необходимого множества действий, по выполнению работы иили решению проблемы, в общем, понятие достаточно общее как для каскадных, так и для agile-проектов, однако стоит понимать различия методологий по управлению задачами, в чем могут быть как плюсы, так и минусы.

На следующем рисунке мы показали, как можно агрегировать эту метрику по всей команде.
[[Image:Cumulative Person Effort Visual Display and Actual Effort distribution per phase.jpg|center|framed|Диаграммы совокупных личных трудозатрат и распределения реальных затрат по фазам проекта]]

''Effort'' («трудозатраты») — это впрямую наблюдаемая величина,

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

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

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

Начинающие компании обычно наблюдают большие различия между «планом» и «фактом», далее, параллельно с тем, как команда набирается опыта, оценки и результат становятся все ближе.
Согласно нашему опыту, если за шесть месяцев оценки «плана» и «факта» так и не стали сходиться, команда должна провести ретроспективу, и найти причины этой проблемы, которые могут быть как внутри, так и вне команды.
Определение такого Ключевого Ограничения — прекрасное место для начальных изменений, как предложила Мери Поппендик<ref>Poppendieck and Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley Professional, 2003.</ref>.

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

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

<m>
Productivity = \frac{ \frac{Planned Effort}{5} }{Actual Effort} \cdot 8
</m>

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

[[Image:Productivity Visual Display (time).jpg|center|framed|Визуализация продуктивности (временная шкала)]]

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

любой приличной демократии.

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

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

[[Image:Productivity Visual Display (Waterfall vs Agile).jpg|center|framed|Визуализация продуктивности «Waterfall против Agile»]]

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

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

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

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

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

;Качество (''Quality''): определяется числом серьезные, типичных, и маловажных дефектов обнаруженных за время жизни проекта. Оно помогает определить доброкачественность продукта для конечного пользователя. Каждая команда должна сама определить критерии «серьезности», «типичности» и «маловажности» для их конкретных проектов. Качество нужно отслеживать в течении всей жизни проекта, ведь чем позже пойман баг, тем больше вреда он нанесет проекту. На следующем рисунке показано, как агрегировать эту метрику по всей команде.
[[Image:Quality Visual Display.jpg|center|framed|Диаграмма ''Качества'']]

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

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

[[Image:Defect Removal Visual Display.jpg|center|framed|Диаграмма «Удаляемые Дефекты»]]

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

Этот набор метрик постоянно собирался, анализировался, и использовался в отчетах.

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

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

{| border=1 style="border-style:dashed; border-width:1px; border-color:orange"
|-
| Metric 1
| Metric 2
| Положительная зависимость
| Отрицательная зависимость
|-
| Производительность (''Productivity'')
| Плотность выпущенных дефектов
| Высокая продуктивность вместе с высокой плотностью выпущенных дефектов это индикатор недостаточных для проекта запланированных трудозатрат на обеспечение качества. Хотя высокая производительность штука хорошая, нужно найти взаимовыгодный компромисс между производительностью и качеством, чтобы был оптимальный уровень производительности при достаточно хорошем качестве.
|

* Высокая производительность с низкой плотностью выпущенных дефектов — хорошее, годное поведение. Тут команде имеет смысл поискать пути повышения производительности, сохраняя контроль-мониторинг над низким уровнем ошибок.

* Высокая плотность ошибок при низкой производительности означает необходимость усиления раннего обнаружения проблем — путем настройки процессов тестирования, или даже его автоматизации.
|-
| Производительность (''Productivity'')
| Эффективность удаления дефектов
| Высокая производительнсоть при высокой эффективности удаления дефектов свидетельствует о хорошем балансе между производительностью и скоростью. Команда может попробовать дальнейшие улучшения производительсности, продолжая отслеживать эффективность удаления дефектов.
|

* Высокая производительность с низким уровнем удаления дефектов означает, что вложения в процессы обеспечения качества (QA) недостаточны.

* Высокая эффективность удаления дефектов при низкой продуктивности означает необходимость несколько большего внимания к качеству на протяжении всего цикла проекта.
|}

==Заключение ==

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

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

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

==Ссылки==

<references/>

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

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

{{replicate-from-custiswiki-to-lib}}

Project Metrics for Software Development - История изменений

BenderBot: 1 версия

StasFomin в 11:25, 6 сентября 2009

BenderBot: 1 версия

StasFomin в 16:06, 5 сентября 2009

← Предыдущая	Версия 00:00, 7 сентября 2009
(нет различий)

← Предыдущая	Версия 00:00, 6 сентября 2009
(нет различий)