http://lib.custis.ru/index.php?title=AgileEVM:_Measuring_Cost_Efficiency_Across_the_Product_Lifecycle&feed=atom&action=historyAgileEVM: Measuring Cost Efficiency Across the Product Lifecycle - История изменений2024-03-28T12:52:30ZИстория изменений этой страницы в викиMediaWiki 1.26.4http://lib.custis.ru/index.php?title=AgileEVM:_Measuring_Cost_Efficiency_Across_the_Product_Lifecycle&diff=11154&oldid=prevBenderBot: 1 версия2009-08-29T00:00:31Z<p>1 версия</p>
<table class='diff diff-contentalign-left'>
<tr style='vertical-align: top;' lang='ru'>
<td colspan='1' style="background-color: white; color:black; text-align: center;">← Предыдущая</td>
<td colspan='1' style="background-color: white; color:black; text-align: center;">Версия 00:00, 29 августа 2009</td>
</tr><tr><td colspan='2' style='text-align: center;' lang='ru'><div class="mw-diff-empty">(нет различий)</div>
</td></tr></table>BenderBothttp://lib.custis.ru/index.php?title=AgileEVM:_Measuring_Cost_Efficiency_Across_the_Product_Lifecycle&diff=11153&oldid=prevStasFomin: /* Схема вычисления */2009-08-28T15:45:07Z<p><span dir="auto"><span class="autocomment">Схема вычисления</span></span></p>
<p><b>Новая страница</b></p><div>http://www.infoq.com/articles/agile-evm<br />
<br />
;Автор: [http://www.infoq.com/author/Tamara-Sulaiman Tamara Sulaiman]<br />
<br />
----<br />
<small><br />
<br />
Tamara Sulaiman — консультант по управлению в компании SolutionsIQ, специализирующаяся на тренингах по переходу на SCRUM команды и организаций. У Тамары более 15 лет опыта в бизнес-управлении и разработке ПО. Она ''Certified Scrum Trainer'' (CST) и ''Project Management Professional'' (PMP).<br />
<br />
</small><br />
----<br />
<br />
<br />
<br />
'''AgileEVM''' — это некоторая адаптация традиционной практики управления проектами, заключающейся в измерении и сверке текущих значений: <br />
* общих затрат (''integrated cost'');<br />
* сроков (''schedule'');<br />
* объема функционала (''scope'');<br />
с первоначальным планом (''baseline plan''), используя метрики «Управления Освоенными Объемами» (''Earned Value Management'', EVM).<br />
<br />
Эти методы измерений были модифицированы, чтобы с легкостью вписаться в рамки SCRUM-практик управления проектами. <br />
AgileEVM можно использовать для измерения эффективности затрат совместно с традиционными EVM-метриками в течении всего жизненного цикла продукта. <br />
Это существенно дополнит Agile-управление на протяжении всего жизненного цикла продукта, заранее предупреждая о нездоровых тенденциях.<br />
<br />
Так как «AgileEVM» использует те же метрики, что и традиционные EVM-техники ''управления освоенными объемами'', их обоих можно сочетать, получая комбинированную методологию, дающую результаты на более высоком уровне.<br />
<br />
Например, «освоенные объемы», полученные из какого-нибудь Agile-проекта, можно скомбинировать с таковыми, вычисленными для традиционно-планового проекта, или даже портфеля проектов, и получить таким образом общие «освоенные объемы» (''earned value''). <br />
<br />
Предоставив информацию об эффективности затрат по всем типам проектов внутри некоторого направления, AgileEVM заранее предупреждает о потенциально опасных областях и предоставляет основанную на метриках информацию для принятия решений.<br />
<br />
== Использование AgileEVM в компании «Info Tech, Inc» ==<br />
<br />
Методика AgileEVM изначально разработана для информирования о производительности динамичных SCRUM-проектов. <br />
История такова: <br />
SCRUM-команда для некоторого релиза решила перейти на однонедельные спринты. Окончательный план релиза был вполне гибким, и ответственный за продукт (''Product Owner'') каждую неделю добавлял новый функционал, который необходимо включить в релиз.<br />
Адаптация традиционных метрик управления освоенными объемами для этого SCRUM-проекта позволила SCRUM-мастеру точно предсказывать влияние этих изменений требований, несмотря на флуктуации скорости разработки (''velocity''), бюджета и сроков поставки этого релиза.<br />
<br />
SCRUM-мастер делился этой информацией с владельцем продукта (''product owner'') и командой, что помогало им принимать обоснованные решения.<br />
<br />
Года два спустя обкатки SCRUM и AgileEVM на первом проекте, Том Блэкберн <br />
(''Tom Blackburn''), менеджер по продукту в компании «Info Tech, Inc»<ref>«[http://www.infotechfl.com/ Info Tech, Inc]» — лидер рынка в софте по управлению построением различной инфраструктуры</ref>), стал<br />
использовать информацию об освоенных объемах в своем оперативном отчете, чтобы учитывать важную информацию о бюджетах и планах по всему своему портфелю проектов.<br />
<br />
[[Image:AgileEVM Dashboard.gif|center|thumb|332px]]<br />
<br />
Руководители разработки отдельных продуктов для принятия решений о вложении средств и ресурсов использовали эти данные совместно со стандартной SCRUM-информацией о «сгорании запланированных работ» (''burndown data''). <br />
Дополнительно, эти метрики освоенных объемом вывешивались каждый спринт в командных офисах разработчиков вместе с ''Burndown Chart'' и прочими ''agile''-метриками,<br />
что улучшало информированность и коммуникацию на всем жизненном цикле продукта.<br />
<br />
----<br />
<small><br />
«Мы осознали, что основные достоинства AgileEVM заключаются в совместном использовании его данных вместе с ''Burndown''-информацией.<br />
Это обеспечивает ранее предупреждение о какой-нибудь негативной тенденции.<br />
Чем больше информации у нас есть, тем лучшее решение мы можем принять» — говорил Том Блекберн.<br />
<br />
«Я отслеживаю изменение значение индекса выполнения стоимости (ИВСТ, CPI, ''Cost Performance Index'') и индекса выполнения сроков (ИВСР, SPI ''Schedule Performance Index''), как средство позволяющее моим командам лучше понять происходящее в проекте»<br />
</small><br />
----<br />
<br />
Метод AgileEVM предоставляет легкое отслеживание затрат с использованием ранее доступной информации, и связывает текущую выполненную работу с бюджетом и сроками четким и ясным образом. <br />
Это помогает планировать выпуски, так как сбор временных трендов по всем метрикам, дает более глубокое понимание производительности каждой команды.<br />
<br />
== Расширение практик AgileEVM на уровень управления направлениями (''Program Management Level'') ==<br />
<br />
EVM-метрики объема освоенных ресурсов принято агрегировать с уровня метрик проекта до следующих уровней — продукта или направления.<br />
Все это, разумеется, можно делать и для Agile-продуктов. <br />
Вне зависимости от того, используются ли Agile-практики на всех фазах жизненного цикла (разработка, внедрение, и техподдержка), или это смесь традиционных и Agile методик, для всех проектов можно собирать и агрегировать EVM-метрики в единый набор, отражающий отклонения от плана на уровне продукта или отдельного выпуска.<br />
<br />
Как менеджер, ответственный за продукты «Info Tech», Блэкберн расширил использование AgileEVM с одного девелоперского пилотного проекта до уровня направления по двум отдельным продуктам. <br />
Два года спустя первого применения этой техники, он расширил использование этих метрик по направлениями продуктов Appia® и Bid Express®, двум программным приложениям используемым в транспортно-строительной индустрии.<br />
<br />
Эти направления включали проекты с полным жизненным циклом по каждому продукту — от разработки до внедрения и техподдержки, а также маркетинговые проекты, управляемые смесью традиционных и Agile-методов. <br />
Теперь по каждой программе там набор простых метрик для измерения эффективности затрат, единый по всем проектам всех продуктов.<br />
<br />
== История и основы управления освоенными объемами ==<br />
<br />
Управление освоенными объемами (''Earned Value Management'', EVM) — это широко известная техника управления проектами.<br />
Эту технику подробно изучают в Институте Управления Проектами (''Project Management Institute'', PMI) Колледжа Управления Производительностью (''College of Performance Management'') и это включено как стандарт в знаменитый PBBoK: «Guide to the Project Management Body of Knowledge», регулярно публикуемый институтом управления проектами.<br />
<br />
EVM объединяет области технической производительности, планов и сроков, и актуальной цены, чтобы обеспечить метрики для действительно законченной работы. Сравнивая освоенные объемы (''earned value'', EV) c запланироваными значениями (''planned value'', PV), действительный прогресс сравнивается с запланированным. <br />
По этой информации, вычисляются метрики, определяющие эффективность затрат и сроков. <br />
Метрики предсказывают ожидаемые затраты завершения проекта и его полную стоимость, основываясь на наблюдаемой в прошлом производительности.<br />
<br />
== Глоссарий управления освоенными объемами ==<br />
<br />
{{note}} Термин объем (value) не стоит путать с ''business value'' (ценностью для бизнеса). Объем обычно относится к бюджету проекта или направления.<br />
<br />
;PV: Запланированный объем (''Planned Value''): Объем работ, запланированной к выполнению, основываясь на заданном бюджете (в деньгах или трудочасах).<br />
<br />
;EV: Освоенный объем (''Earned Value''): Общий объем завершенных работ, на которых потратили заданный бюджет (в деньгах или трудочасах).<br />
<br />
;AC: Фактическая стоимость (''Actual Cost''): фактическая стоимость, приведенная для этой части работ.<br />
<br />
;BAC: Бюджет по завершению (''Budget At Complete''): Плановая стоимость проекта, т.е. бюджет, назначенный для выполнения работы.<br />
<br />
;ETC: Оценка до завершения (''Estimate To Complete''): Оценка оставшейся стоимости операции, группы операций или проекта, необходимой для их завершения, основанная на производительности в прошлом (измеряется в деньгах или трудочасах).<br />
<br />
;EAC: Оценка по завершению (''Estimate At Complete''): Ожидаемый общий объем всех работ по плану проекта, основанный на прошлой производительности.<br />
<br />
==Метрики Освоенных Объемов ==<br />
;PV: Запланированный объем (''Planned Value''): Какой объем выполненной работы был запланирован к конкретной вехе проекта или дате.<br />
BAC * Planned Percent Complete<br />
<br />
;EV: Освоенный объем (''Earned Value''): Какой объем работы был выполнен к конкретной вехе проекта или дате.<br />
BAC * Actual Percent Complete<br />
<br />
;CPI: Индекс выполнения стоимости (''Cost Performance Index''): Сколько процентов от затрат «обернулось» полезным объемом работ. Измеряет эффективность затрат.<br />
EV/AC<br />
<br />
;Индекс выполнения сроков (''Schedule Performance Index'', SPI): Эффективность выполнения сроков — насколько быстро вы «прогрессируете» по отношению к запланированной скорости работ. <br />
PV/AC<br />
<br />
;ETC: Оценка до завершения (''Estimate To Complete''): Прогнозирует оставшуюся стоимость незавершенных работ.<br />
(BAC - EV)/CPI<br />
<br />
;EAC: Оценка по завершению (''Estimate At Completion''): Ожидаемая стоимость всей запланированной работы.<br />
BAC / CPI<br />
или<br />
AC + ETC<br />
<br />
Все эти ключевые метрики означают одно и то же и в AgileEVM и в традиционном управлении освоенными объемами (EVM).<br />
Адаптируется лишь метод измерения этих метрик.<br />
Agile делает акцент на мощном взаимодействии и частой отгрузке полнофункциональных и оттестированных систем, а также на серьезном учете человеческого фактора в разработке ПО.<br />
Agile-разработка ПО сфокусирована на раннем достижении бизнес-целей, основываясь на регулярное получаемых запросах заказчика или рынка.<br />
<br />
И AgileEVM специально разработан для измерения и прогнозирования прогресса в SCRUM-проектах. <br />
Хотя эта техника вполне применима и при других Agile-методиках, <br />
AgileEVM особенно хорош вместе с такими SCRUM-практиками, как<br />
оцененный и приоритезированный беклог (''backlog''), а также измерения в границах отдельной итерации-спринта.<br />
<br />
== Адаптация AgileEVM для Scrum ==<br />
<br />
В AgileEVM, оценочные баллы (они же «отсчеты истории», обычно оставляют оригинальное наименование — ''story points'' без перевода)<br />
используются для измерения запланированной и выполненной работы, тем самым обеспечивая базис для всех традиционных вычислений «освоенных объемов». <br />
<br />
В других EV-адаптациях можно более хитро задавать правила вычисления ожидаемого и актуального процента выполненных работ.<br />
В AgileEVM же, ожидаемый процент выполненных работ есть число <br />
выполненных спринтов-итераций на их общее число.<br />
<br />
Актуальный процент получается делением числа выполненных ''story points'' на число ''story points'' запланированных на весь релиз.<br />
Важно отметить, что в AgileEVM используются story point-ы уровня бэклога продукта, как оценки относительного размера задач, а не баллы уровня задач для отдельного спринта.<br />
<br />
<br />
Чтобы вычислить начальную точку отсчета в AgileEVM нужны пять параметров:<br />
<br />
# Число запланированных спринтов внутри заданного релиза.<br />
# Длина каждого спринта в календарных днях.<br />
# Число ''story points'' запланнированных на релиз.<br />
# Выделенный на релиз бюджет.<br />
# Стартовая дата проекта.<br />
<br />
Граница каждого спринта задает точку отсчета для переоценки всех изменений (т.е. работы добавленной или удаленной из плана) и переоценки освоенных объемов.<br />
<br />
Чтобы вычислить метрики AgileEVM нужны четыре входных параметра:<br />
<br />
# Число выполненных спринтов: из этого выводится ожидаемый процент выполнения, путем деления этого параметра на число запланированных спринтов.<br />
# Число добавленных story points (может быть отрицательным, если их число в релизе уменьшилось). Отражает изменение в объеме запланированной на релиз работы, чем по сути и приводит к переоценке релиза.<br />
# Фактические затраты на данную дату на каждой границе (?спринта). Мы измеряем результаты на заданную дату, поэтому мы используем накопленные актуальные затраты на границу этого спринта<br />
# Суммарное число выполненных ''story points''. Так измеряется полный объем работы выполненной для релиза в рамках данного спринта.<br />
<br />
Исследовательская работа, представленная на конференции «Agile 2007», доказывает корректность AgileEVM. <br />
В этой статье утверждается, что AgileEVM:<br />
<br />
* Легкий. AgileEVM удачно использует учитываемые рабочие метрики, практически не нагружая текущие процессы.<br />
* Полезен как Agile-командам, так и другим заинтересованным лицам, предоставляя данные для принятия решений.<br />
* Выгоден в реализации.<br />
* Точность метода не хуже, чем у существующих. Математическое доказательство представленно в опубликованной IEEE исследовательской статье: [http://solutionsiq.com/agile/ http://solutionsiq.com/agile/].<br />
<br />
== Формулы AgileEVM ==<br />
<br />
===BAC===<br />
Бюджет по завершению (''Budget At Complete''): Плановая стоимость проекта, т.е. бюджет, назначенный для выполнения работы.<br />
===AC===<br />
Фактическая стоимость (''Actual Cost''): фактическая стоимость, приведенная для этой части работ.<br />
===PRSP===<br />
Story points, запланированных на данный релиз (''Planned Release Story Points''). Story points берутся определенными на уровне бэклога продукта.<br />
===EPC===<br />
Ожидаемый процент завершения (''Expected Percent Complete''): Current Sprint(n) / Total planned Sprints<br />
===APC===<br />
Фактический процент завершения (''Actual Percent Complete''): Story points completed / Total planned Story points;<br />
<br />
===PV===<br />
Запланированный объем (''Planned Value'', PV): <br />
PV = BAC * EPC<br />
<br />
===EV===<br />
Освоенный объем (''Earned Value'', EV): <br />
EV = BAC * APC<br />
<br />
===CPI=== <br />
Индекс выполнения стоимости (''Cost Performance Index''): <br />
CPI = EV / AC<br />
<br />
===SPI=== <br />
Индекс выполнения сроков (''Schedule Performance Index''): <br />
SPI = EV/PV<br />
<br />
<br />
== Схема вычисления ==<br />
----<br />
Переводчик взял на себя смелость дополнить статью графической гипертекстовой схемой вычисления, ибо иначе все выглядит несколько туманно.<br />
----<br />
<br />
<graph><br />
digraph G{<br />
rankdir=LR;<br />
node [style=filled colorscheme="accent5"]; <br />
<br />
node [shape=folder fillcolor=1]<br />
<br />
SprintsPlanned;<br />
PRSP [URL="#PRSP"]<br />
BAC [URL="#BAC"]<br />
<br />
node [shape=note fillcolor=2]<br />
SprintsComplete <br />
StoryPointsComplete <br />
AC [URL="#AC"]<br />
<br />
node [shape=Mcircle fillcolor=3]<br />
<br />
APC [URL="#APC"]<br />
EPC [URL="#EPC"]<br />
EV [URL="#EV"]<br />
PV [URL="#PV"]<br />
<br />
node [shape=box3d fillcolor=4]<br />
<br />
CPI [URL="#CPI"]<br />
SPI [URL="#SPI"]<br />
<br />
<br />
SprintsPlanned->EPC;<br />
SprintsComplete->EPC;<br />
PRSP->APC;<br />
StoryPointsComplete ->APC;<br />
<br />
BAC->PV<br />
EPC->PV<br />
<br />
BAC->EV<br />
APC->EV<br />
<br />
EV->CPI <br />
AC->CPI<br />
<br />
EV -> SPI <br />
PV -> SPI <br />
<br />
}<br />
</graph><br />
<br />
{{replicate-from-custiswiki-to-lib}}</div>StasFomin