Стоимость в мире SAFe®

Перевод статьи Em Campbell-Pretty Understanding Cost in a SAFe World выполнен с разрешения автора.

В пособии по внедрению SAFe^® Lean Portfolio Management выделяет бюджет каждому Value Stream и, следовательно, каждому ART (Agile Release Train, далее — поезд). Для приоритизации задач, потребляющих этот бюджет, менеджер продукта каждого поезда работает с заинтересованными лицами. Поезд планирует и реализует задачи с учетом этих приоритетов, и никого не заботит стоимость поставки отдельно взятой фичи. Однако, часто между идеальным внедрением SAFe и вашей текущей действительностью могут быть отличия, и одно из таких отличий — это ожидание того, что поезд сможет дать четкое понимание стоимости поставки фичи! Чаще всего такое происходит в случае, когда ваш поезд находится внутри организации, продолжающей применять проектный подход к бюджетированию.

Организации могут отвечать на такие вопросы так же, как и раньше — требуя от специалистов заполнения отчетов о затраченном времени с указанием проектных и непроектных активностей. Для мира, в котором мы хотим видеть наши команды, где отчетность и оценки трудоемкости даются в сторипоинтах, это выглядит как огромный шаг назад! Как могла бы выглядеть альтернатива, если бы мы использовали уже имеющуюся информацию и минимизировали бы затраты команды на сбор информации исключительно с целью узнать стоимость реализации?

Подход, который я успешно использовал много раз — это модель стоимости одного сторипоинта. Идея в том, что когда я знаю стоимость сотрудников поезда и историческую производительность поезда, то, следовательно, я знаю и стоимость каждого сторипоинта. И если я захочу понять «стоимость» фичи, я могу взять нормализованные сторипоинты с PI-планирования, перемножить их на стоимость одного сторипоинта и получить достаточно точное значение.

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

Модель стоимости сторипоинта для SAFe-поездов

Концепция бережливого управления портфелем (Lean Portfolio Management) в SAFe подразумевает выделение собственного бюджета каждому потоку ценности (Value Stream). Это хорошая, но вряд ли достижимая цель для компании, запускающей свои первые поезда.

В этой концепции бэклог программы для поезда приоритизируется Продуктовым Менеджментом (при взаимодействии с Представителями Бизнеса, относящимися к поезду), и стоимость реализации определенной фичи не имеет большого значения. Вместо стоимости реализации Продуктовый Менеджмент отвечает за фокус поезда на реализации нужных фич — тех, которые могут максимизировать финансовые результаты организации. И если для этого потребуется выбрать, какая фича нужнее, Продуктовый Менеджмент имеет право это сделать!

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

«Стоимость сторипоинта» — это проверенная модель распределения затрат на проекты в ситуации, когда SAFe внедряется без выделения собственных бюджетов потокам ценности и поездам. Любые поезда, независимо от модели финансирования, могут использовать «стоимость сторипоинта» как метрику, которую можно отслеживать для понимания эффективности поезда.

Также, полученные из этой модели данные о стоимости сторипоинта могут быть использованы для:

1. Прогнозирования стоимости реализации фичи, эпика или проекта.
2. Расчета стоимости реализованной фичи, эпика или проекта.
3. Разделения затрат на OPEX и CAPEX.
4. Распределения затрат на проект вместо списаний времени.

Модель стоимости сторипоинта

Идея модели стоимости сторипоинта на самом деле очень проста. Если вы знаете, сколько стоит работа вашего поезда в промежуток времени, и вы знаете сколько сторипоинтов реализовал ваш поезд в этот промежуток времени, то вы знаете и стоимость каждого сторипоинта:

Стоимость работы (оплаты труда команд) поезда в промежуток времени / Количество сторипоинтов, реализованных поездом в промежуток времени = Стоимость сторипоинта.

Оценка в сторипоинтах в Agile базируется на следующих теориях:

1. Люди пытаются оценивать время точно, особенно, если речь идет более чем о нескольких часах.
2. Борьба за точность провоцируется количеством неопределенности в разработке ПО и командами, которые выгорают под давлением менеджмента, использующего оценки как жесткие обязательства.
3. Люди сильны в сравнении объектов, потому сравнительный подход к оценке трудоемкости является более точным.

Это работает следующим образом: команда берет небольшую пользовательскую историю как ориентир трудоемкости и измеряет остальные истории относительно этого ориентира. То есть если ваша история-ориентир — это 1 сторипоинт, а другая история требует в три раза больше усилий для реализации и поставки значит эта история «весит» 3 сторипоинта. Сторипоинты оцениваются с использованием доработанной последовательности Фибоначчи, то есть 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. В таком стиле оценки каждая цифра на самом деле представляет диапазон: 3 на самом деле — это диапазон от 2 до 5, а 5 — от 3 до 8 и т.д. Таким образом мы не делаем оценки, дающие ложное ощущение точности. Как правило, сумма нескольких неточных оценок дает достаточно точную оценку планируемой работы (ошибки в оценке имеют тенденцию к взаимному исключению, а не к суммированию).

И хотя расчет достаточно простой, есть компоненты, без которых модель не будет точной:

1. Единый подход к оценке в сторипоинтах во всем поезде.
2. Управление бизнес-правилами:
   1. Какие работы включаются в затраты поезда?
   2. Как распределять затраты на «общие» команды?
   3. Как работать со временем, выделяемым на инновации, анализ или уточнения к следующему PI и IP?
3. Фиксация «реальной» производительности.
4. Измерение производительности с учетом присутствия членов команды.

Большинство поездов, с которыми мы работаем, выделяют 10% своего времени на инновации (время на безжалостное улучшение) и 10% на исследования (анализ задач к следующему PI) — каждая команда, в каждом спринте.

Единый подход к оценке в сторипоинтах

Необходимо применять единый подход к оценке во всех командах поезда. Один из способов это сделать — использовать алгоритм SAFe для определения сторипоинта. Так как этот подход включен в тренинг SAFe for Teams, являющийся частью процедуры запуска поезда, то чаще всего именно с него и стоит начинать!

Алгоритм SAFe для приведения команд к единым базовым сторипоинтам:

• За каждого разработчика и тестировщика дайте команде 8 очков на итерацию (для участвующих часть времени уменьшите очки соответственно).
• Вычтите 1 очко за каждый день отпуска или выходной члена команды.
• Найдите небольшую историю на полдня разработки и полдня тестирования. Пусть это будет 1 сторипоинт.
• Оцените остальные истории в сравнении с первой историей в сторипоинтах.

Источник: Iteration Planning — Scaled Agile Framework.

Управление бизнес-правилами

Для обеспечения модели нужной информацией необходимо принять несколько управленческих решений:

1. Какие работы включать в затраты поезда?
2. Как распределять затраты на «общие» команды?
3. Как работать со временем, выделяемым на инновации, анализ или уточнения к следующему PI и IP?

a) Работы.

Вам нужно решить, какие работы включается в затраты поезда. Обычно в них входят затраты на команды (фиче-команды, компонентные команды, системные команды, общие сервисы и т.д.), а также троица (RTE, Продуктовый Менеджмент, Системный Архитектор\Инженер) и Agile-коуч.

b) Общие сервисы.

Хорошей практикой является равномерное распределение нагрузки «общих сервисов» на весь поезд в фиксированном объеме на базе сторипоинтов. К общим сервисам относятся системные команды, троица (RTE, Продуктовый Менеджмент, Системный Архитектор\Инженер) и Agile-коуч.

с) Выделение времени на инновации и т.д.

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

Фиксация «реальной» производительности

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

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

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

Как команде рассчитать реальную производительность в конце итерации:

• В начале итерации команды должны оценить истории относительно усилий на реализацию используя покер-планирование.
• Команды должны планировать на основе «вчерашней погоды», так как производительность команды в прошлой итерации является лучшим прогнозом производительности команды в следующей итерации.
• Прогнозируемая производительность должна быть скорректирована с учетом планируемых отпусков.
• Время распределяется с учетом договоренностей по распределению времени поезда, то есть по выделению времени на инновации, изучение, поддержку.
• В конце итерации команда должна пересмотреть начальные оценки с учетом понимания реально затраченных на итерацию усилий и зафиксировать все значительные отклонения в большую или меньшую сторону.
• Во время ретроспективы команда должна рассмотреть истории, с наибольшими отклонениями реальных усилий от плановых, и понять чем вызваны отклонения, чтобы улучшить оценки будущих задач.
• Незапланированная работа\дополнительные истории, неожиданно возникшие и реализованные в течение итерации, тоже оцениваются.
• Если история реализована в итерации не полностью, ее нужно разделить на две истории: первая история должна содержать реализованную часть задачи с фактическими затратами на плановую дату реализации в итерации. Вторая, новая история, будет содержать нереализованную часть задачи с описанием того, что нужно доделать, и ее нужно поместить в бэклог команды.

Оцениваем производительность по присутствию

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

Рассчитываем нормированную производительность:

1. Определите стандартную производительность поезда в днях (предполагая полное присутствие команды).
2. Посчитайте дни присутствия команды, вычитая запланированные и незапланированные дни отпусков, государственные праздники из стандартной мощности.
3. Рассчитайте процент производительности, разделив дни присутствия команды на стандартную производительность поезда.
4. Зафиксируйте фактическую производительность поезда за итерацию.
5. Рассчитайте нормированную производительность за период, разделив фактическую производительность поезда на процент производительности.

Стандартная мощность поезда — Плановые и внеплановые отпуска за период = Дни присутствия команды поезда

Дни присутствия команды поезда / Стандартную мощность поезда = % мощности за период

Фактическая производительность поезда / % мощности за период = Нормированная производительность.

Пример:

Поезд из 100 человек, работающий в 10-дневной итерации, будет иметь стандартную производительность равную 1000 дней (100 человек * 10 дней).

Если в течение итерации был государственный праздник на 1 день, а также 5 человек взяли по 1 дню незапланированного отпуска, то мы получим 895 дней присутствия команды (1000 — 100 дней праздника (1 день у всех сотрудников) — 5 дней отпуска (по 1 дню у 5 человек)) и процент производительности будет равен 89,5%. Если фактическая производительность поезда составила 448 сторипоинтов, то нормированная производительность будет равна 501 сторипоинту.

Рассчитываем стоимость сторипоинта

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

Чтобы рассчитать стоимость сторипоинта, нужно посчитать:

• Полную стоимость оплаты труда сотрудников поезда за инкремент программы:

Стоимость часа * Количество рабочих часов в день * Количество дней в спринте * (Количество спринтов в инкременте программы — Спринт инноваций и планирования) = Полная стоимость оплаты труда сотрудников поезда

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

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

Использование стоимости сторипоинта

Теперь, когда вы узнали стоимость одного сторипоинта, вы можете:

1. Спрогнозировать стоимость фичи, эпика и проекта.
2. Рассчитать стоимость реализованных фич, эпиков и проектов.
3. Разделить затраты на CAPEX и OPEX.
4. Распределить затраты на проекты, используя стоимость сторипоинта вместо отчетов о затраченном времени.

Прогнозирование стоимости фичи, эпика или проекта

Для того, чтобы сделать это, вам понадобится использовать подход с нормализованной оценкой фич и эпиков. Затем, чтобы получить оценку в деньгах, надо просто перемножить полученные оценки на стоимость одного сторипоинта.

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

Расчет стоимости реализованной фичи или эпика

Это так просто, что, наверное, даже не требует объяснения. Просто сложите все реализованные сторипоинты из историй, относящихся к конкретной фиче, и умножьте на стоимость сторипоинта.

Разделение затрат на CAPEX и OPEX

Это тоже достаточно просто. Вам понадобятся консультации финансистов о том, какие затраты можно капитализировать, а какие должны учитываться как операционные расходы. Для начала вы можете использовать руководство по капитализации затрат с сайта Scaled Agile Framework^®. Как только вы разберетесь с правилами, просто проставьте тэги с типом в ваших историях и вы сможете увидеть, как много сторипоинтов приходится на каждый тип истории в фичах, эпиках или проектах, и распределить затраты соответствующим образом.

Распределение затрат на проекты с использованием стоимости сторипоинта вместо отчетов о затраченном времени

Пожалуйста, обратите внимание: описанное выше руководство не должно использоваться без явного подтверждения применимости этих практик в вашей организации от финансового департамента.

Вместо привязки списаний времени членов команд к отдельным проектам и видам деятельности используйте один вид деятельности для всех сотрудников поезда.

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.