Частый вопрос руководителей уровня команды команд – как определить продуктивность команды? Давно понимают, что количество строк кода не говорит об эффективности. Но и количество стори поинтов или идеальных часов тоже не сообщает, какая польза бизнесу предоставлена. Полезный и простой вариант – назначение бизнес-ценности командным целям, а затем определение фактического достижения.
Зачем команды формулируют цели на квартал
1. Подтверждается понимание командами того, чего хотят добиться бизнес-владельцы. 2. Фокусироваться на том, “что” нужно получить, а не “как” это сделать. 3. Обобщение плана на управляемый уровень детализации - желательно не более 10 пунктов. 4. Получение в конце квартала информации о продуктивности программы путем присвоения каждой цели бизнес-ценности - об этом ниже (ART, Release train, PI).
Нужно выбрать proxy для определения бизнес-ценности
Для наших фичей в бэклоге программе мы рассчитали WSJF, чтобы упорядочить их. Почему бы не использовать WSJF в качестве бизнес-ценности? 1. Фичи могут распределиться между командами. 2. В бэклоге команды могут появиться истории, связанные с эпиками, но не фичами.
Критерии, которые полезно учитывать при определении бизнес-ценности:
Ценность для пользователя и удовлетворенность клиента.
Критичность по времени – Можно ли выполнить в следующем квартале, или нужно сделать сейчас? И почему?
Риски – Поможет ли это снизить риски или повысить будущую предсказуемость?
Доля рынка – Позволит ли это привлечь новых или удержать текущих хороших клиентов?
Операционная эффективность – Поможет ли это снизить операционные расходы?
Штрафы – Будут ли штрафы, если не сделаем? Какие?
Новые знания – Поможет ли это проверить гипотезу?
Постоянные улучшения – Поможет ли это улучшить нашу систему?
Соответствие Team Objective и Feature
Некоторые фичи могут быть поставлены одной командой, и однозначно 1-1 соответствуют цели этой команды (Team’s PI objective). Однако цель стоит формулировать в виде получаемого результата, поскольку зачастую эту же цель можно достичь и фичей меньшего размера.
Некоторые фичи требуют взаимодействия нескольких команд, и у этих команд появится соответствующая цель на квартал.
Дополнительно у команды могут появиться технические цели (enabler), упрощающие последующие доработки: PoC, инфраструктура, архитектура, производительность и пр.
Рис. 1 Соответствие между фичами и целями команд
Примеры целей команды приведены в таблице ниже.
Присвоение BV при планировании инкремента программы
Во время планирования инкремента программы в ходе личного общения с командой владельцы бизнесов присваивают значение “бизнес-ценности” каждой из целей команды (PI Planning, Team's PI Objectives, Business owners, Business value, BV). Цели команды – это результаты, которых команда собирается достичь.
Такой живой диалог между бизнес-владельцами и командой во время планирования квартала крайне полезен, поскольку помогает: 1. Укрепить взаимоотношения между Agile-командами и владельцами бизнесов. 2. Выявить общие риски, для работы по которым необходимо вовлечение всех участников. 3. Лучше понять бизнес-цели и их ценность. 4. Транслировать стратегию и контекст, объясняющий присвоенные целям веса. 5. Эти оценки используются командами для планирования последовательности реализации. 6. После планирования при реализации команды смогут самостоятельно децентрализованно производить корректировки скоупа, по-прежнему предоставляя максимально возможную пользу. 7. Дополнительно, эти оценки будут использованы для расчета метрики предсказуемости программы в конце квартала (PPM, Program Predictability Measure).
Бизнес-ценность именно присваивается, а не рассчитывается. Это гипотезы бизнес владельцев о том, что принесет наибольшую ценность организации. Обратная связь по этим гипотезам будет получена уже через квартал – небольшой срок для крупной корпорации. Владельцы бизнесов оценивают каждую цель команды, используя шкалу от 1 (самая низкая) до 10 (самая высокая). Цель с оценкой 10 в 2 ценнее, чем цель с оценкой 5. Оценки не обязательно выравнивать между командами, тогда у каждой команды есть своя “10”, или даже несколько таких “десяток” – элементов бэклога команды с наивысшим приоритетом. Однако можно и выравнять.
Целями команды могут быть (Team's PI Objectives):
Пользовательские фичи (features) – основная часть целей команды. Они сразу же и напрямую приносят ценность пользователям, клиенту, рынку. Поэтому обычно бизнес-владельцы присваивают им наивысшие значения ценностей.
Технические задачи (enablers) включают улучшение инфраструктуры, развитие сред разработки, изменение архитектуры, повышение качества. Их выполнение позволяет командам в дальнейшем встречать меньше технических препятствий и быстрее создавать бизнес-ценность. Владельцы бизнесов обращаются за советом к техническими специалистами, чтобы присвоить бизнес-ценность таким целям.
BV присваивается и обязательным, и необязательным целям (committed & uncommitted). Иногда BV необязательной цели больше, чем BV обязательной – это ОК. Так бывает, когда какая-то зависимость, риск и блокер не позволяют команде пообещать достижение важной цели.
Business value проясняет ценность задач, но не подразумевает последовательность выполнения задач. Последовательность определяется далее в ходе PI Planning, когда команды совместно создают общий план квартала на PI Board, учитывая зависимости, доступную трудомощность и общие вехи.
Оценка фактической BV при инспекции и адаптации PI
В конце квартала программа (ART, релизный поезд) проводит встречу “Инспекции и адаптации” (Inspect and Adapt, I&A), чтобы оценить и проанализировать прогресс и системные проблемы. Встреча состоит из трех частей:
Демонстрация инкремента программы (PI System Demo)
Качественные и количественные оценки
Ретроспектива и решение проблем
Перед демонстрацией или во время нее владельцы бизнесов снова встречаются с каждой Agile-командой (как и при планировании) и оценивают фактически полученную бизнес-ценность для каждой цели команды.
Команда может ощущать дискомфорт, потому что их оценивают. Поэтому эта оценка производится в диалоге между командой и владельцами бизнеса. Смотрят на:
Качество – цель достигнута частично.
Содержание – цель достигнута частично, если, например, планировали повысить скорость на 50%, а повысили только на 30%.
Своевременность – цель достигнута не вовремя, например, необходимо было запустить сервис раньше.
Actual BV может быть равной Planned BV, ниже нее или нулю.
Если команда достигла цели, то ABV устанавливается равной PBV, даже если бизнес-владелец уже не считает эту цель настолько ценной для бизнеса – ведь не получится оценить предсказуемость достижения цели, если цель изменяется.
Если команда вообще не достигла цели, то ABV = 0.
Если команда достигла цели частично, то происходит обсуждение между бизнес-владельцем и командой. Например, если достижение цели предполагало реализацию нескольких фичей, а команда поставило лишь часть из них, то бизнес-владелец присвоит какое-то значение ABV < PBV. Не используется подход “либо полное значение PBV, либо 0” – если команда доставила частичную ценность, то ее заслуги стоит признать.
Важно, чтобы бизнес-ценность определялась только уровне командных целей PI.
Далее для каждой команды рассчитывается суммарный фактический размер предоставленной бизнесу ценности. При подсчете учитываются и обязательные, и необязательные цели (committed & uncommitted), как показано на рисунке ниже. Напомню, что при подсчете плановой BV необязательные цели не учитываются.
Рис. 5 Необязательные цели тоже учитываются в фактическом размере предоставленной бизнесу ценности
Использование BV для расчета метрики предсказуемости программы PPM
PPM – одна из метрик потока. Мы подробнее рассмотрели эти метрики здесь.
Бизнес-ценность определяется только уровне целей каждой команды. При планировании квартала – плановые, в конце квартала – фактические.
Затем значения бизнес-ценности целей суммируются для каждой отдельной команды – см. “Totals 50 / 45” на рисунке выше.
Затем вычисляется отношение "actual / planned" для каждой команды – это предсказуемость команды – см. “Achievement = 90%" на рисунке выше.
Затем по предсказуемостям всех команд программы вычисляется средняя – это метрика предсказуемости программы (МПП, PPM) – см. рисунок ниже.
Рис. 6 Предсказуемость программы по кварталам – средние по значениям предсказуемостей команд
Надежные команды и программы работают в диапазоне 80–100% предсказуемости. Это позволяет бизнесу и заинтересованным сторонам планировать эффективно. Подробнее об этой метрике читайте с статье “Метрики потока”.
Использованные источники
Для написания этой короткой прикладной статьи собраны части информации из 6 разных статей SAFe (ниже) и 6 видеороликов, которых нет в свободном доступе: