Квартальные цели в SAFe®

Вольный перевод статьи PI Objectives — Scaled Agile Framework®.

Взятие на себя и выполнение небольших обязательств укрепляет доверие. —Нонака и Такеучи, The Knowledge-Creating Company

PI-цели

Цели Инкремента Программы (Program Increment Objectives, PI Objectives) составляются из бизнес-и технических целей, которые Agile-команда или поезд (Agile Release Train, ART) намерены достичь в предстоящем Инкременте Программы (PI).

Во время PI-планирования команды формируют PI-цели, которые они намерены достичь в предстоящем Инкременте Программы (PI). Это дает следующие преимущества:

• Обеспечивает общий язык общения между заинтересованными лицами от бизнеса и разработки.
• Задает фокус и концепцию на ближайшую перспективу.
• Позволяет ART оценивать свою производительность и достигнутую бизнес-ценность с помощью измерения Метрики Предсказуемости Программы (Program Predictability Measure).
• Информирует и подчеркивает вклад каждой команды в бизнес-ценность.
• Выявляет зависимости, которые требуют координации.

SAFe опирается на набегающую волну краткосрочных обязательств Agile-команд и поездов, чтобы обеспечить бизнес-планирование и бизнес-результаты, которые повышают согласованность и доверие между заинтересованными лицами разработки и бизнеса. Для этого и нужны PI-цели.

Хотя по самой своей природе разработка несет неопределенность, бизнесу нужны от команд  надежные и предсказуемые прогнозы. Если нет прогнозов, бизнес не может планировать. Если прогнозы слишком детальные, то бизнес стремится к долгосрочным планам, которые в лучшем случае ненадежны, а также ограничивают гибкость. Заинтересованным лицам в бизнесе и разработке нужна золотая середина, для этого как раз и нужны PI-цели. Помимо согласования процесс постановки реалистичных целей также помогает избежать слишком большого объема незавершенной работы (Work In Progress, WIP) в системе. PI-цели формируются в основном снизу вверх, поскольку команды определяют их во время PI-планирования.

Формирование PI-целей команды

Во время PI-планирования команды знакомятся с новыми Фичами и планируют Истории, которые нужны для их достижения, наряду с Историями для выполнения своих обычных задач. Эта работа описывается в виде конкретных PI-целей команды. Для этого требуется оценка и планирование, знание емкости команды, анализ предстоящих фич, определение историй для Бэклога Команды и, наконец, обобщение информации в простых бизнес-терминах, понятных всем.

Нет фиксированного правила по количеству целей команды, но 7-10 обязательных (committed) целей плюс 2-3 рискованных (uncommitted), похоже, работают лучше всего. Если целей будет больше, то детали и специфику будет трудно понять и обработать другим командам и партнерам команды от бизнеса. Кроме того, их слишком много, чтобы их можно было просмотреть и обработать в масштабе среднего и крупного ART. Если целей будет меньше, то уровень абстракции или агрегации, вероятно, будет слишком высок, чтобы результат можно было объективно измерить в конце PI.

На рисунке 1 показан пример PI-целей одной команды.

Рисунок 1. PI-цели команды

Отличие Фич и PI-целей

PI-цели команды часто напрямую связаны с ожидаемыми фичами; действительно, многие из них совпадают. Однако, сопоставление не всегда является прямым, поскольку некоторые фичи требуют совместной работы нескольких команд, как показано на рисунке 2.

Рисунок 2. От фичей к целям; некоторые фичи будут отображаться в PI-целях более чем одной команды

Обратите внимание, что некоторые фичи (например, фича A) могут быть разработаны отдельной командой, а другие (фича B) требуют сотрудничества нескольких команд. В дополнение к фичам и входным данным для фич появятся и другие цели команды. Они могут включать технические цели (например, подтверждение концепции на рисунке 1), которые обеспечивают будущие фичи, улучшения инфраструктуры разработки, Вехи и прочее. Все результаты процесса планирования отражаются в целях команды.

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

Лучшее понимание намерений, получаемое в результате прямых бесед с Представителями Бизнеса, часто приводит к тому, что команды предоставляют новые видения Системным Архитекторам/Инженерам и Продуктовому Менеджменту и быстро находят способы применения своего опыта для создания лучших решений.

Обязательные и рискованные цели

Взятие на себя и реализация ряда краткосрочных целей помогает укрепить доверие. Доверие позволяет всем заинтересованным лицам уверенно двигаться вперед и основывать решения и планы на том, что «с большой вероятностью сбудется очень скоро». Но планирование с уверенностью в условиях неопределенности, присущей исследованиям и разработкам, затруднено. Не всегда все идет так, как планировалось, и просто разумно встроить в систему небольшой объем буфера. Если буфер слишком велик, то может быть выполнено меньше, чем могло было быть. Если буфер слишком мал, то многие обязательства могут оказаться невыполнимыми, а планирование и уверенность ослабеют. Для решения этой проблемы SAFe рекомендует командам использовать как обязательные (committed), так и рискованные (uncommitted) цели. Рискованные цели помогают повысить предсказуемость создания ценности для бизнеса, поскольку они не включены в обязательства команды и не учитываются командами в метрике предсказуемости программы.

Рискованные цели используются для определения работы, которая может изменяться во время PI. Работа запланирована, но результат просто не определен. Команды могут применять рискованные цели, когда у них низкая уверенность в достижении цели. Это может быть связано со следующими обстоятельствами:

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

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

Рискованные цели предоставляют следующие преимущества:

• Лучше экономика – без рискованных целей команда берет на себя обязательства по 100% объему работ в установленные сроки. Это вынуждает команды идти на компромисс с качеством или создавать другие буферы в системе. Такие буферы могут накапливаться, что приводит к снижению общей пропускной способности.
• Выше надежность – рискованные цели представляют собой переменный объем работ, что позволяет быть уверенным в выполнении основных приоритетов. В свою очередь выполнение заявленных обязательств является наиболее важным фактором укрепления доверия между командами и заинтересованными лицами.
• Адаптивность к изменениям – для надежного выполнения поставленных задач рискованные цели предоставляют запас по объему, необходимый для выполнения обязательств, при этом, при необходимости, этот запас позволяют управлять приоритетами, когда меняются фактические данные. То есть запас можно использовать для выполнения обязательных целей.

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

PI-цели по SMART

PI-цели команды — это краткое изложение плана команды на PI. Они критически важны. Иногда описания могут быть очень техническими и/или немного расплывчатыми. В качестве контрмеры команды составляют свои цели по SMART:

• Specific (Конкретная) – стоит излагать предполагаемый результат кратко и четко, насколько это возможно. Подсказка: попробуйте начать с глагола действия.
• Measurable (Измеримая) – должно быть ясно, что команде нужно сделать для достижения цели. Меры могут быть описательными, да/нет, количественными или предоставлять из себя диапазон.
• Achievable (Достижимая) – достижение цели должно находиться под контролем и влиянием команды.
• Realistic (Реалистичная) – стоит учитывать факторы, которые невозможно контролировать. Подсказка: избегайте оптимистичных предположений.
• Time-bound (Ограниченная по времени) — период времени для достижения должен быть в пределах PI, поэтому все цели должны быть определены соответственно.

Бизнес-ценность PI-целей

По мере того, как цели уточняются во время PI-планирования, Представители Бизнеса совместно оценивают бизнес-ценность каждой из целей команды в личном разговоре. Ценность этого конкретного разговора с командой невозможно переоценить, поскольку он раскрывает стратегию и контекст, лежащие в основе последующих оценок. Представители Бизнеса используют шкалу от 1 (наименее важная) до 10 (наиболее важная) для оценки каждой цели. Оценки не нужно нормализовать для разных команд; у каждой команды есть несколько пунктов с наивысшим приоритетом (рейтинг 10).

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

Итоговые PI-цели команды

Когда цели были сделаны по SMART, были определены рискованные цели и определена оценка бизнес-ценности, тогда цели на рисунке 1 могут измениться и начать выглядеть так, как показано на рисунке 3.

Рисунок 3. Итоговые PI-цели команды с назначенной бизнес-ценностью и рискованной целью

Взятие обязательств по PI-целям

Голосование о доверии проводится ближе к концу PI-планирования, и во время него команды берут на себя обязательство достичь PI-целей. Рискованные цели не включены в это обязательство. Тем не менее, это должен быть реалистично достижимый результат для людей, которые выполняют эту работу. Таким образом, обязательство в SAFe состоит из двух частей:

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

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

PI-цели программы и решения

Результатом процесса PI-планирования должен стать набор согласованных PI-целей всех команд. Команды голосуют за уровень доверия для набора целей, и если уровень доверия достаточно высок (выше трёх пальцев), совокупный набор целей становится согласованным планом ART.

RTE (Release Train Engineer) обобщает цели команды в PI-цели программы в формате, подходящем для коммуникации руководству.

Обобщенные цели должны соответствовать SMART, так же, как и PI-цели команды, и иметь рискованные цели. Кроме того, как и PI-цели команды, так и PI-цели программы могут описывать бизнес-фичи, над которыми работает ART, Enablers или другие бизнес- или технические цели.

Если ART является частью Solution Train, то во время заключительного PI-планирования (Post-PI Planning), после того, как все виды работ запланированы, STE (Solution Train Engineer) дополнительно сводит цели в PI-цели решения. Это верхний уровень PI-целей в SAFe, они сообщают заинтересованным лицам, что Solution Train разработает в предстоящем PI. Рисунок 4 ниже иллюстрирует сведение данных от команды к программе и от программы к PI-целям решения.

Важно, чтобы бизнес-ценность присваивалась только PI-целям команды. При этом метрики предсказуемости команд сводятся в метрику предсказуемости Agile Release Train, а метрики предсказуемости поездов — в метрику предсказуемости Solution Train.

Рисунок 4. Сводная информация о PI-целях команды, программы и решения

Сокращение объема незавершенной работы с помощью реалистичных PI-целей

Во время анализа PI-целей команды, не всё, что было запрошено различными заинтересованными лицами от бизнеса, вероятно, будет достигнуто во время PI. Поэтому часть запланированной работы необходимо будет пересмотреть с Представителями Бизнеса, чтобы согласовать с PI-целями.

Эти рабочие элементы с более низким приоритетом перемещаются обратно в Бэклог Программы. Сокращение избыточного объема незавершенной работы снижает накладные расходы и затраты, а также повышает производительность и скорость. Конечным результатом является выполнимый набор PI-целей, с которыми согласны все заинтересованные лица бизнеса и члены команды, а также повышенная эффективность и более высокая вероятность успеха разработки.

Планирование на уровне большого решения может быть очень похожим; планирование каждого из ART будет влиять на других, возвращая часть работы в Бэклог Решения для повторной оценки в более позднем PI-планировании.

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