Просмотр исходного текста страницы AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle

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

;Автор: [http://www.infoq.com/author/Tamara-Sulaiman Tamara Sulaiman]

----
<small>

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

</small>
----



'''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»<ref>«[http://www.infotechfl.com/ Info Tech, Inc]» — лидер рынка в софте по управлению построением различной инфраструктуры</ref>), стал
использовать информацию об освоенных объемах в своем оперативном отчете, чтобы учитывать важную информацию о бюджетах и планах по всему своему портфелю проектов.

[[Image:AgileEVM Dashboard.gif|center|thumb|332px]]

Руководители разработки отдельных продуктов для принятия решений о вложении средств и ресурсов использовали эти данные совместно со стандартной SCRUM-информацией о «сгорании запланированных работ» (''burndown data''). 
Дополнительно, эти метрики освоенных объемом вывешивались каждый спринт в командных офисах разработчиков вместе с ''Burndown Chart'' и прочими ''agile''-метриками,
что улучшало информированность и коммуникацию на всем жизненном цикле продукта.

----
<small>
«Мы осознали, что основные достоинства AgileEVM заключаются в совместном использовании его данных вместе с ''Burndown''-информацией.
Это обеспечивает ранее предупреждение о какой-нибудь негативной тенденции.
Чем больше информации у нас есть, тем лучшее решение мы можем принять» — говорил Том Блекберн.

«Я отслеживаю изменение значение индекса выполнения стоимости (ИВСТ, CPI, ''Cost Performance Index'') и индекса выполнения сроков (ИВСР, SPI ''Schedule Performance Index''), как средство позволяющее моим командам лучше понять происходящее в проекте»
</small>
----

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

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

{{note}} Термин объем (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 нужны пять параметров:

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

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

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

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

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

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


== Схема вычисления ==
----
Переводчик взял на себя смелость дополнить статью графической гипертекстовой схемой вычисления, ибо иначе все выглядит несколько туманно.
----

<graph>
digraph G{
rankdir=LR;
node [style=filled colorscheme="accent5"]; 

node [shape=folder fillcolor=1]

SprintsPlanned;
PRSP [URL="#PRSP"]
BAC [URL="#BAC"]

node [shape=note fillcolor=2]
SprintsComplete 
StoryPointsComplete 
AC   [URL="#AC"]

node [shape=Mcircle fillcolor=3]

APC [URL="#APC"]
EPC [URL="#EPC"]
EV [URL="#EV"]
PV [URL="#PV"]

node [shape=box3d fillcolor=4]

CPI [URL="#CPI"]
SPI [URL="#SPI"]


SprintsPlanned->EPC;
SprintsComplete->EPC;
PRSP->APC;
StoryPointsComplete ->APC;

BAC->PV
EPC->PV

BAC->EV
APC->EV

EV->CPI 
AC->CPI

EV -> SPI 
PV -> SPI 

}
</graph>

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