AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle

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

http://www.infoq.com/articles/agile-evm

Автор

Tamara Sulaiman

---

Tamara Sulaiman — консультант по управлению в компании SolutionsIQ, специализирующаяся на тренингах по переходу на SCRUM команды и организаций. У Тамары более 15 лет опыта в бизнес-управлении и разработке ПО. Она Certified Scrum Trainer (CST) и Project Management Professional (PMP).

---

AgileEVM — это некоторая адаптация традиционной практики управления проектами, заключающейся в измерении и сверке текущих значений:

• общих затрат (integrated cost);
• сроков (schedule);
• объема функционала (scope);

с первоначальным планом (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»), стал использовать информацию об освоенных объемах в своем оперативном отчете, чтобы учитывать важную информацию о бюджетах и планах по всему своему портфелю проектов.

Руководители разработки отдельных продуктов для принятия решений о вложении средств и ресурсов использовали эти данные совместно со стандартной 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), действительный прогресс сравнивается с запланированным. По этой информации, вычисляются метрики, определяющие эффективность затрат и сроков. Метрики предсказывают ожидаемые затраты завершения проекта и его полную стоимость, основываясь на наблюдаемой в прошлом производительности.

Глоссарий управления освоенными объемами

Термин объем (value) не стоит путать с business value (ценностью для бизнеса). Объем обычно относится к бюджету проекта или направления.

PV

Запланированный объем (Planned Value): Объем работ, запланированной к выполнению, основываясь на заданном бюджете (в деньгах или трудочасах).

EV

Освоенный объем (Earned Value): Общий объем завершенных работ, на которых потратили заданный бюджет (в деньгах или трудочасах).

AC

Фактическая стоимость (Actual Cost): фактическая стоимость, приведенная для этой части работ.

BAC

Бюджет по завершению (Budget At Complete): Плановая стоимость проекта, т.е. бюджет, назначенный для выполнения работы.

ETC

Оценка до завершения (Estimate To Complete): Оценка оставшейся стоимости операции, группы операций или проекта, необходимой для их завершения, основанная на производительности в прошлом (измеряется в деньгах или трудочасах).

EAC

Оценка по завершению (Estimate At Complete): Ожидаемый общий объем всех работ по плану проекта, основанный на прошлой производительности.

Метрики Освоенных Объемов

PV

Запланированный объем (Planned Value): Какой объем выполненной работы был запланирован к конкретной вехе проекта или дате.

BAC * Planned Percent Complete

EV

Освоенный объем (Earned Value): Какой объем работы был выполнен к конкретной вехе проекта или дате.

BAC * Actual Percent Complete

CPI

Индекс выполнения стоимости (Cost Performance Index): Сколько процентов от затрат «обернулось» полезным объемом работ. Измеряет эффективность затрат.

 EV/AC

Индекс выполнения сроков (Schedule Performance Index, SPI)

Эффективность выполнения сроков — насколько быстро вы «прогрессируете» по отношению к запланированной скорости работ.

 PV/AC

ETC

Оценка до завершения (Estimate To Complete): Прогнозирует оставшуюся стоимость незавершенных работ.

 (BAC - EV)/CPI

EAC

Оценка по завершению (Estimate At Completion): Ожидаемая стоимость всей запланированной работы.

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 нужны пять параметров:

1. Число запланированных спринтов внутри заданного релиза.
2. Длина каждого спринта в календарных днях.
3. Число story points запланнированных на релиз.
4. Выделенный на релиз бюджет.
5. Стартовая дата проекта.

Граница каждого спринта задает точку отсчета для переоценки всех изменений (т.е. работы добавленной или удаленной из плана) и переоценки освоенных объемов.

Чтобы вычислить метрики AgileEVM нужны четыре входных параметра:

1. Число выполненных спринтов: из этого выводится ожидаемый процент выполнения, путем деления этого параметра на число запланированных спринтов.
2. Число добавленных story points (может быть отрицательным, если их число в релизе уменьшилось). Отражает изменение в объеме запланированной на релиз работы, чем по сути и приводит к переоценке релиза.
3. Фактические затраты на данную дату на каждой границе (?спринта). Мы измеряем результаты на заданную дату, поэтому мы используем накопленные актуальные затраты на границу этого спринта
4. Суммарное число выполненных story points. Так измеряется полный объем работы выполненной для релиза в рамках данного спринта.

Исследовательская работа, представленная на конференции «Agile 2007», доказывает корректность AgileEVM. В этой статье утверждается, что AgileEVM:

• Легкий. AgileEVM удачно использует учитываемые рабочие метрики, практически не нагружая текущие процессы.
• Полезен как Agile-командам, так и другим заинтересованным лицам, предоставляя данные для принятия решений.
• Выгоден в реализации.
• Точность метода не хуже, чем у существующих. Математическое доказательство представленно в опубликованной IEEE исследовательской статье: http://solutionsiq.com/agile/.

Формулы AgileEVM

BAC

Бюджет по завершению (Budget At Complete): Плановая стоимость проекта, т.е. бюджет, назначенный для выполнения работы.

AC

Фактическая стоимость (Actual Cost): фактическая стоимость, приведенная для этой части работ.

PRSP

Story 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».