|
Персональные инструменты |
![]() |
||
|
![]() |
![]() AgileEVM: Measuring Cost Efficiency Across the Product LifecycleМатериал из CustisWikihttp://www.infoq.com/articles/agile-evm
Tamara Sulaiman — консультант по управлению в компании SolutionsIQ, специализирующаяся на тренингах по переходу на SCRUM команды и организаций. У Тамары более 15 лет опыта в бизнес-управлении и разработке ПО. Она Certified Scrum Trainer (CST) и Project Management Professional (PMP).
AgileEVM — это некоторая адаптация традиционной практики управления проектами, заключающейся в измерении и сверке текущих значений:
с первоначальным планом (baseline plan), используя метрики «Управления Освоенными Объемами» (Earned Value Management, EVM). Эти методы измерений были модифицированы, чтобы с легкостью вписаться в рамки SCRUM-практик управления проектами. AgileEVM можно использовать для измерения эффективности затрат совместно с традиционными EVM-метриками в течении всего жизненного цикла продукта. Это существенно дополнит Agile-управление на протяжении всего жизненного цикла продукта, заранее предупреждая о нездоровых тенденциях. Так как «AgileEVM» использует те же метрики, что и традиционные EVM-техники управления освоенными объемами, их обоих можно сочетать, получая комбинированную методологию, дающую результаты на более высоком уровне. Например, «освоенные объемы», полученные из какого-нибудь Agile-проекта, можно скомбинировать с таковыми, вычисленными для традиционно-планового проекта, или даже портфеля проектов, и получить таким образом общие «освоенные объемы» (earned value). Предоставив информацию об эффективности затрат по всем типам проектов внутри некоторого направления, AgileEVM заранее предупреждает о потенциально опасных областях и предоставляет основанную на метриках информацию для принятия решений. Содержание
Использование AgileEVM в компании «Info Tech, Inc»Методика AgileEVM изначально разработана для информирования о производительности динамичных SCRUM-проектов. История такова: SCRUM-команда для некоторого релиза решила перейти на однонедельные спринты. Окончательный план релиза был вполне гибким, и ответственный за продукт (Product Owner) каждую неделю добавлял новый функционал, который необходимо включить в релиз. Адаптация традиционных метрик управления освоенными объемами для этого SCRUM-проекта позволила SCRUM-мастеру точно предсказывать влияние этих изменений требований, несмотря на флуктуации скорости разработки (velocity), бюджета и сроков поставки этого релиза. SCRUM-мастер делился этой информацией с владельцем продукта (product owner) и командой, что помогало им принимать обоснованные решения. Года два спустя обкатки SCRUM и AgileEVM на первом проекте, Том Блэкберн (Tom Blackburn), менеджер по продукту в компании «Info Tech, Inc»[1]), стал использовать информацию об освоенных объемах в своем оперативном отчете, чтобы учитывать важную информацию о бюджетах и планах по всему своему портфелю проектов. Руководители разработки отдельных продуктов для принятия решений о вложении средств и ресурсов использовали эти данные совместно со стандартной SCRUM-информацией о «сгорании запланированных работ» (burndown data). Дополнительно, эти метрики освоенных объемом вывешивались каждый спринт в командных офисах разработчиков вместе с Burndown Chart и прочими agile-метриками, что улучшало информированность и коммуникацию на всем жизненном цикле продукта. «Мы осознали, что основные достоинства AgileEVM заключаются в совместном использовании его данных вместе с Burndown-информацией. Это обеспечивает ранее предупреждение о какой-нибудь негативной тенденции. Чем больше информации у нас есть, тем лучшее решение мы можем принять» — говорил Том Блекберн. «Я отслеживаю изменение значение индекса выполнения стоимости (ИВСТ, CPI, Cost Performance Index) и индекса выполнения сроков (ИВСР, SPI Schedule Performance Index), как средство позволяющее моим командам лучше понять происходящее в проекте» Метод AgileEVM предоставляет легкое отслеживание затрат с использованием ранее доступной информации, и связывает текущую выполненную работу с бюджетом и сроками четким и ясным образом. Это помогает планировать выпуски, так как сбор временных трендов по всем метрикам, дает более глубокое понимание производительности каждой команды. Расширение практик AgileEVM на уровень управления направлениями (Program Management Level)EVM-метрики объема освоенных ресурсов принято агрегировать с уровня метрик проекта до следующих уровней — продукта или направления. Все это, разумеется, можно делать и для Agile-продуктов. Вне зависимости от того, используются ли Agile-практики на всех фазах жизненного цикла (разработка, внедрение, и техподдержка), или это смесь традиционных и Agile методик, для всех проектов можно собирать и агрегировать EVM-метрики в единый набор, отражающий отклонения от плана на уровне продукта или отдельного выпуска. Как менеджер, ответственный за продукты «Info Tech», Блэкберн расширил использование AgileEVM с одного девелоперского пилотного проекта до уровня направления по двум отдельным продуктам. Два года спустя первого применения этой техники, он расширил использование этих метрик по направлениями продуктов Appia® и Bid Express®, двум программным приложениям используемым в транспортно-строительной индустрии. Эти направления включали проекты с полным жизненным циклом по каждому продукту — от разработки до внедрения и техподдержки, а также маркетинговые проекты, управляемые смесью традиционных и Agile-методов. Теперь по каждой программе там набор простых метрик для измерения эффективности затрат, единый по всем проектам всех продуктов. История и основы управления освоенными объемамиУправление освоенными объемами (Earned Value Management, EVM) — это широко известная техника управления проектами. Эту технику подробно изучают в Институте Управления Проектами (Project Management Institute, PMI) Колледжа Управления Производительностью (College of Performance Management) и это включено как стандарт в знаменитый PBBoK: «Guide to the Project Management Body of Knowledge», регулярно публикуемый институтом управления проектами. EVM объединяет области технической производительности, планов и сроков, и актуальной цены, чтобы обеспечить метрики для действительно законченной работы. Сравнивая освоенные объемы (earned value, EV) c запланироваными значениями (planned value, PV), действительный прогресс сравнивается с запланированным. По этой информации, вычисляются метрики, определяющие эффективность затрат и сроков. Метрики предсказывают ожидаемые затраты завершения проекта и его полную стоимость, основываясь на наблюдаемой в прошлом производительности. Глоссарий управления освоенными объемами
Метрики Освоенных Объемов
BAC * Planned Percent Complete
BAC * Actual Percent Complete
EV/AC
PV/AC
(BAC - EV)/CPI
BAC / CPI или AC + ETC Все эти ключевые метрики означают одно и то же и в AgileEVM и в традиционном управлении освоенными объемами (EVM). Адаптируется лишь метод измерения этих метрик. Agile делает акцент на мощном взаимодействии и частой отгрузке полнофункциональных и оттестированных систем, а также на серьезном учете человеческого фактора в разработке ПО. Agile-разработка ПО сфокусирована на раннем достижении бизнес-целей, основываясь на регулярное получаемых запросах заказчика или рынка. И AgileEVM специально разработан для измерения и прогнозирования прогресса в SCRUM-проектах. Хотя эта техника вполне применима и при других Agile-методиках, AgileEVM особенно хорош вместе с такими SCRUM-практиками, как оцененный и приоритезированный беклог (backlog), а также измерения в границах отдельной итерации-спринта. Адаптация AgileEVM для ScrumВ AgileEVM, оценочные баллы (они же «отсчеты истории», обычно оставляют оригинальное наименование — story points без перевода) используются для измерения запланированной и выполненной работы, тем самым обеспечивая базис для всех традиционных вычислений «освоенных объемов». В других EV-адаптациях можно более хитро задавать правила вычисления ожидаемого и актуального процента выполненных работ. В AgileEVM же, ожидаемый процент выполненных работ есть число выполненных спринтов-итераций на их общее число. Актуальный процент получается делением числа выполненных story points на число story points запланированных на весь релиз. Важно отметить, что в AgileEVM используются story point-ы уровня бэклога продукта, как оценки относительного размера задач, а не баллы уровня задач для отдельного спринта.
Граница каждого спринта задает точку отсчета для переоценки всех изменений (т.е. работы добавленной или удаленной из плана) и переоценки освоенных объемов. Чтобы вычислить метрики AgileEVM нужны четыре входных параметра:
Исследовательская работа, представленная на конференции «Agile 2007», доказывает корректность AgileEVM. В этой статье утверждается, что AgileEVM:
Формулы AgileEVMBACБюджет по завершению (Budget At Complete): Плановая стоимость проекта, т.е. бюджет, назначенный для выполнения работы. ACФактическая стоимость (Actual Cost): фактическая стоимость, приведенная для этой части работ. PRSPStory points, запланированных на данный релиз (Planned Release Story Points). Story points берутся определенными на уровне бэклога продукта. EPCОжидаемый процент завершения (Expected Percent Complete): Current Sprint(n) / Total planned Sprints APCФактический процент завершения (Actual Percent Complete): Story points completed / Total planned Story points; PVЗапланированный объем (Planned Value, PV): PV = BAC * EPC EVОсвоенный объем (Earned Value, EV): EV = BAC * APC CPIИндекс выполнения стоимости (Cost Performance Index): CPI = EV / AC SPIИндекс выполнения сроков (Schedule Performance Index): SPI = EV/PV
Схема вычисленияПереводчик взял на себя смелость дополнить статью графической гипертекстовой схемой вычисления, ибо иначе все выглядит несколько туманно.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |