Release train engineer это что

Запусти поезд SAFe с правильным бизнесом на борту

Кто такие представители бизнеса? В чем отличие от заинтересованных лиц? Как их определить в иерархии компании? Сколько по количеству их может быть? В чем их обязанности и полномочия?

Перевод статьи Mark Richards Unleash your ART with the right Business Owners выполнен с разрешения автора.

Много лет я удивлялся, почему Дину Леффингуэллу приходилось вместо термина «заинтересованные лица» (stakeholders) использовать иной — «Представители Бизнеса» (Business Owners). На тренинге я объяснял это так: «У ART много заинтересованных лиц, но поддержка 4-6 из них будет критичной для вашего успеха — это и есть Представители Бизнеса».

В какой-то момент времени меня осенило. В любом случае нужна какая-то форма управляющего комитета, чтобы учитывать инвестиции на обеспечение работы Agile Release Train. По сути, вы предлагаете концепцию Представителей Бизнеса для ART в виде Lean|Agile-альтернативы традиционным управляющим комитетам.

За целенаправленный поиск ответа я был награжден. Я решил одну из ключевых головоломок децентрализации, с которыми сталкивался в SAFe. Перед запуском ART вам может потребоваться определить Менеджера Продукта (Product Manager). Это человек с колоссальным количеством делегированной ответственности, стратегический представитель клиента. Кажется практически невозможным, что один человек сможет эффективно представлять все конкурирующие стратегические и тактические интересы для ART. Аналогичная проблема и с Release Train Engineer (RTE). Большинство ART будут продолжать работать одновременно по несколькими стратегическим направлениям с множеством заинтересованных лиц в рамках всей ИТ-организации, каждый из которых переживает из-за конкуренции за ресурсы с остальными.

Я пришел к мысли, что RTE и Менеджер Продукта — это полномочные агенты Представителей Бизнеса для ART. В таком случае, Представители Бизнеса несут коллективную ответственность за быстрый ответ на любое решение, которое эскалировано на их уровень. Магия случается, когда оба уровня управления эффективно взаимодействуют между собой.

Когда и Как выбирать Представителей Бизнеса

Путешествие ART начинается с тренинга руководителей и семинара по определению концепции. Мы собираем группу руководителей и заинтересованных лиц, чтобы вместе согласовать понимание фреймворка и концепцию будущего ART.

В идеале вовлечь Представителей Бизнеса уже на этом раннем этапе, для этого нужно составить список потенциальных представителей бизнеса и отправить их на тренинг Leading SAFe и семинар по определению концепции.

При выборе кандидатов на роль представителей бизнеса можно воспользоваться общей картой заинтересованных лиц. Вам необходимо два типа представителей.

Заинтересованные лица со стороны бизнеса:

Заинтересованные лица со стороны технологии:

Какого уровня руководитель?

Если выбрать недостаточно высокопоставленных Представителей Бизнеса, им не хватит полномочий, чтобы выполнять свою миссию. И наоборот, слишком высокопоставленные руководители дадут вам больше полномочий, но скорость принятия ими решений вряд ли устроит вас.

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

Сколько человек мне нужно?

Четкого ответа на вопрос: «Сколько должно быть Представителей Бизнеса ART» — нет. Но на основе опыта я выработал несколько правил. Несколько раз были назначены два представителя: Бизнес-спонсор (Business Sponsor) и Владелец Технологии (Technology Owner). Между ними были постоянные противоречия как из-за отсутствия сторонних точек зрения, так и очень часто из-за множества заинтересованных лиц, которым казалось, что Бизнес-спонсор плохо представляет их разносторонние интересы.

Итак, сейчас я напрягаюсь, когда вижу меньше 4 Представителей Бизнеса. С другой стороны, когда их слишком много — это тоже огромная проблема. Невероятно сложно достигать и поддерживать согласованность и прогресс по критичным решениям с большой и расфокусированной группой. Однажды я потерпел фиаско при проведении семинара по определению концепции ART с 30 кандидатами на роль Представителей Бизнеса — принять решение было практически невозможно.

Вам нужно достаточное количество представителей (обычно как минимум 4), но их не должно быть настолько много, что вам придется с ними бороться при принятии решений (обычно боль начинается при приближении к 8-10).

Важность согласования ожиданий

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

Им нужно будет присутствовать и активно участвовать в нескольких событиях SAFe, которые отнимают достаточно много времени. Как минимум, от них потребуется следующее:

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

Я считаю, что на позицию Представителя Бизнеса ART сотрудники должны выдвигаться и согласовываться формально, чтобы в конечном счете был явно определен Перечень Полномочий Представителей Бизнеса.

Что должны делать ваши Представители Бизнеса

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

Семинар по определению концепции ART

Каждый ART следует стартовать с четкой концепцией и этот семинар — первое, что позволит это сделать (подробное описание см. в статье: Facilitating Release Train design with the ART Canvas Part 1 — Vision). Нужно добиться согласованности о том, кто наши Клиенты, какие у нас Метрики Успеха, сформировать Описание Концепции и сути создаваемого решения, а также согласовать роли представителей бизнеса. Они — ключевые владельцы ART, поэтому важно не только вовлечь представителей бизнеса в формирование концепции, но и достигнуть четкого и единого понимания, как оценивается успех ART.

Семинары по приоритизации Бэклога Программы

В рамках подготовки к этому семинару Менеджер Продукта декомпозирует Эпики (Epics), беседуя с клиентами и учитывая опыт уже доставленных Фич (Features), чтобы определить и сформировать набор фич-кандидатов для добавления в Бэклог Программы. Каждая фича имеет предполагаемую ценность, потому что в SAFe мы используем относительную оценку Стоимости Задержки (Cost of Delay, CoD) и алгоритм «более ценная короткая работа сначала» (Weighted Shortest Job First, WSJF), чтобы приоритеты определялись экономическим взглядом.

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

PI-планирование

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

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

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

Системная Демонстрация

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

Инспекция и Адаптация

Представители Бизнеса играют роль во всех 3 этапах семинара Инспекции и Адаптации. Во время PI-демонстрации (PI Demo) они получают представление о том, «что было достигнуто» в рамках PI с оценкой прогресса по целям, зафиксированным на PI-планировании. В рамках этапа количественного измерения они как рецензируют PI-метрики ART, так и оценивают производительность команд по согласованным целям на основе увиденного на демонстрации.

Наконец, во время семинара по решению проблем они предоставляют крайне важный взгляд топ-менеджмента для анализа корневых причин и мозгового штурма. Это предоставляет им бесценную возможность «выйти из офиса» (Gemba), чтобы оценить потенциальные инициативы, которые необходимо будет далее приоритизировать.

Управление

Каждое из событий SAFe, описанное выше — это мероприятия по управлению. Совокупно они дают возможность Представителям Бизнеса управлять стратегией ART, обеспечивать быстрые решения по ключевым моментам жизненного цикла и поддерживать прозрачность через Системные Демонстрации и Инспекцию и Адаптацию.

Однако, обычно проводят дополнительные регулярные встречи «Управление ART». В предыдущих версиях SAFe они назывались «Управление Релизами» (Release Management). Я подозреваю, что их удалили из описания фреймворка из-за путаницы в названиях. Встреча по мониторингу и эскалации необходима ART в рамках реализации PI. Вводные на эту встречу поступают со стандартных событий SAFe. Встреча облегчает мониторинг и отслеживание возникающих рисков и проблем.

Поддержка

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

Заключение

Я настолько убедился в силе правильно определенной и вовлеченной группы Представителей Бизнеса, что сейчас эта активность имеет один из высших приоритетов во время формирования мною нового ART. Я обнаружил, что это чрезвычайно важно для раскрытия возможности и способности действовать Менеджерам Продукта и RTE, при этом обеспечивая Представителям Бизнеса прекрасное чувство комфорта в уровне понимания того, что происходит, на основе получения объективных входных данных.

Источник

Как отличить первоклассного RTE: 12 качеств и 3 навыка

На рынке труда дефицит на Agile Delivery Manager. Как эту роль описывает Scaled Agile Framework глазами его практиков.

Ниже представлен вольный пересказ статьи Roy Maines 12 Traits of a Great Release Train Engineer (RTE) + 3 Must-Have Tech Skills об основных навыках и качествах, которыми должен обладать RTE.

Продолжающееся развитие Agile-подходов к разработке продуктов влечет за собой появление новых ролей. Не является исключением и наиболее популярный фреймворк масштабирования Agile — Scaled Agile Framework (SAFe) — подход к управлению корпоративными изменениями, включающий в себя несколько уровней: портфель, решение, программа и команды. Одна из ключевых ролей в SAFe — Release Train Engineer (RTE). Это относительно новая роль, которая нередко ставит в тупик руководителей и сотрудников HR при выборе наиболее подходящих кандидатов.

Основатели SAFe из компании Scaled Agile определяют эту роль следующим образом — RTE фасилитирует процессы ART (Agile Release Train), работает над устранением препятствий, управляет рисками, помогает обеспечить поставку ценности, лидирует процесс непрерывного улучшения.

RTE выполняет роль супер Scrum-мастера, следовательно, обладает всеми качествами, присущими Scrum-мастерам. Однако, в отличие Scrum-мастера, главным фокусом которого является команда, RTE взаимодействует в организации с множеством людей различного уровня. Чтобы оставаться эффективным, RTE должен обладать более глубоким пониманием того, каким образом Agile и SAFe приносят ценность организации. Ниже представлены принципы Lean-Agile. Именно они определяют 15 качеств и навыков, которые отличают первоклассных RTE.

Принципы Lean-Agile Лидерства

12 качеств первоклассного RTE

1. Agile-образ мышления — первоклассный RTE не только понимает основы Agile и SAFe, но и обладает образом мышления Agile, а также стремится передать этот навык другим. Это означает, что RTE должен быть ориентирован на создание ценности и движим Lean-Agile принципами, обладать системным мышлением.

2. Внутренняя устойчивость — как и Scrum-мастер, первоклассный RTE обладает мужеством сказать то, что должно быть сказано. Он следует направлению, которое определило руководство, но имеет силу донести правду, даже если это не то, что люди ожидают услышать. Кроме того, RTE должен быть способен сказать «нет», когда дело касается взятия излишних обязательств.

3. Лидерство — первоклассный RTE прежде всего — это служащий лидер. Он стремится к тому, чтобы ART пользовался уважением как стороны руководства, так и со стороны команд.

4. Ответственность — первоклассный RTE несет ответственность за взятые обязательства и сотрудничает с каждым участником процессов ART.

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

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

7. Коммуникация — первоклассный RTE способен правильно донести информацию и должен быть чувствителен к тому, как эта информация воспринимается командой или руководством.

8. Обучение — первоклассный RTE при помощи семинаров, Agile-игр и презентаций способствует тому, чтобы команда понимала Agile-принципы и практики.

9. Наставничество — первоклассный RTE выступает для всех участников ART гидом по процессам и подходам, используемым в Agile-поезде

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

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

12. Потребность в обучении — первоклассный RTE понимает, что процесс обучения никогда не должен прекращаться. Он стремится развивать свои навыки и знания через непрерывное обучение. Форма обучения может быть различной: тренинги, книги, блоги, подкасты, семинары и даже коллеги – ведь каждый окружающий может стать источником знаний, которые могут быть применимы в ежедневной работе с командами.

3 ключевых навыка

Первоклассный RTE должен обладать T-подобным профилем навыков (T-shaped skills). Это означает, что он глубоко понимает Agile, обладает знаниями о развитии продуктов, владеет экспертизой в индустрии которой работает организация. Часто RTE имеет опыт проектного управления, благодаря которому он отточил навыки планирования, управления организацией, временем, бюджетированием. В частности, RTE должен обладать глубокими знаниями и опытом в следующих технических областях:

1. SAFe-фреймворк — первоклассный RTE обладает совершенным пониманием Scaled Agile Framework, а также других фреймворков Lean-Agile.

2. Agile-бюджетирование — первоклассный RTE четко знает принципы бюджетирования в Agile среде, а именно бюджетирование Value Streams и его отличие от проектно-ориентированного бюджетирования.

3. Agile-метрики — первоклассный RTE понимает какие ключевые показатели необходимо отслеживать, как их интерпретировать и какой курс выбрать, когда цифры говорят о том, что ситуация выходит из под контроля. Ниже приведены метрики, которые RTE должен учитывать во время SAFe-трансформации и создания выгод для бизнеса.

Путь развития RTE

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

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

Источники аккредитации

На данный момент есть ряд аккредитаций, ориентированных на RTE:

Scrum Alliance

Project Management Institute

Scaled Agile

Неаккредитованное обучение

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

Заключение

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

Источник

Метрики в SAFe

Метрики, которые предлагает Scaled Agile Framework: от уровня всей компании до уровня команды.

“Самые важные вещи не могут быть измерены. То, что важно в долгосрочной перспективе, не может быть измерено заранее” (c) Эдвардс Деминг

“Работающий продукт — основной показатель прогресса” (c) Agile-манифеcт

Метрики

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

Благодаря Kanban-методу, фиксированным временным интервалам и быстрой обратной связи Agile гораздо более измерим, чем предшествующая ему водопадная модель разработки. Более того, в Agile-подходе система постоянно изменяется, поэтому наиболее подходящий способ оценки — это демонстрация работающей системы. Непрерывная поставка (Continuous Delivery) и DevOps-практики обогащают Agile полезными процессными метриками. Однако, все метрики, которые описаны ниже, вторичны по отношению к ключевой цели — фокусировке на быстрой поставке ценного продукта.

Метрики важны в контексте всего предприятия, поэтому SAFe предлагает метрики для каждого уровня фреймворка: от уровня всей компании до уровня команды.

Метрики уровня компании

Оценка бизнес-гибкости всей компании

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

На рисунке 1 представлены 15 секторов для оценки.

Рисунок 1. Оценка бизнес-гибкости всей компании

Таблица для оценки построена по 5 ключевым компетенциям SAFe, внутри каждой есть 3 подраздела. Сектор оценивается по шкале от 1 до 10, где каждый диапазон цифр имеет свою метафору: Сидим (1-2), Ползем (3-4), Идем (5-6), Бежим (7-8), Летим (9-10).

Построение этого радара позволяет понять, в каком состоянии компания сейчас и выявить точки роста. Для проработки надо брать топ 2-3 секторов, нуждающихся в улучшении. Также важно понимать взаимосвязь между ними: часто работа в одном секторе может вытянуть и улучшить остальные.

Метрики уровня портфеля

Метрики Lean-портфеля

Краткий набор метрик, приведенный ниже, может быть использован для оценки внутреннего и внешнего прогресса всего портфеля. Следуя принципу простоты из Agile-манифеста таблица 1 предоставляет минимальный список метрик, который может оказаться достаточным для оценки Agile-трансформации.

Таблица 1. Метрики Lean-портфеля

Самооценка команды Lean-управления портфелем

Команда Lean-управления портфелем непрерывно оценивает и улучшает свои методы работы. Для этого проводится регулярный опрос, результаты которого агрегируются в виде радара на Рисунке 2. Он подсвечивает относительные слабые и сильные стороны.

Рисунок 2. Радар самооценки портфеля

Откройте таблицу для проведения опроса и построения радара.

Метрики уровня крупных решений

Метрика предсказуемости Solution Train

Метрики предсказуемости (Predictability Measure) поездов (Agile Release Trains, ARTs), участвующих в решении, агрегируются в общую метрику Solution Train Predictability Measure как показано на Рисунке 3.

Рисунок 3. Метрика предсказуемости Solution Train

Метрики результативности Solution Train

Метрики результативности поездов, участвующих в решении, агрегируются в метрики Solution Train, как показано на Рисунке 4.

Рисунок 4. Метрики результативности Solution Train

Метрики уровня программы

Отчет «Прогресс по фичам»

Данный отчет показывает статус по каждой фиче и Enabler в течение PI-интервала.

Он показывает, насколько фича в плане или отстает от него.

График имеет 2 столбца:

На Рисунке 5 представлен пример отчета.

Рисунок 5. Отчет о прогрессе фичей: сравнивает план с фактом по каждой фиче внутри PI

График должен подталкивать к обсуждению: как необходимо изменить план, чтобы PI был успешен.

Метрика предсказуемости программы

Это одна из ключевых метрик SAFe.

Метрика предсказуемости команд поезда усредняется по всем командам для того, чтобы определить метрику предсказуемости программы (Program Predictability Measure).

Рисунок 6. Метрика предсказуемости программы показывает точность планирования 2 команд в разрезе PI (пунктирные красная и синяя линии), а также всего поезда/программы (жирная оранжевая линия).

График отображает процент фактически доставленной бизнес-ценности командами и поездом (по оценке представителей бизнеса) от планируемых показателей. Дополнительные цели (stretch goals) не входят в плановую часть расчета (знаменатель), но входят в фактическую часть (числитель).

Метрики продуктивности программы

Конец каждого PI — это наиболее подходящая точка самых важных измерений.

Таблица 2 показывает набор метрик продуктивности программы.

Таблица 2. Метрики поезда

Кумулятивная диаграмма потока

Кумулятивная диаграмма потока (Cumulative Flow Diagram, CFD) показывает количество задач, находившихся в определенном этапе процесса в заданный интервал времени.

Рассмотрим пример типичного процесса уровня программы:

Рисунок 7 показывает количество фич в каждом шаге процесса для каждой итерации на интервале трех PI.

Толстые области сигнализируют об узких горлышках потока.

Рисунок 7. Пример кумулятивной диаграммы уровня программы

Самооценка ART

Достижение целей программы — это ключевая ценность SAFe. Agile Release Train (ART) постоянно прикладывает усилия для улучшения своей результативности. Release Train Engineer (RTE) заполняет форму самооценки поезда на границах PI или в любой момент, когда есть возможность остановиться и подумать о точках роста его поезда.

Рисунок 8. Пример радара самооценки поезда ART

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

Эффективность конвейера непрерывной поставки

Метрика «Эффективность конвейера непрерывной поставки» сравнивает количество времени, проведенного над реальной работой по процессу (touch time), и количество времени ожидания в процессе (wait time). Часть информации может быть получена из инструментов непрерывной интеграции (Continuous Integration) и непрерывной поставки (Continuous Delivery), другая — должна быть внесена в таблицу вручную.

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

Примечание: время реальной работы (touch time) — это время, когда команды добавляет ценность к своему продукту или услуге. Обычно это время составляет небольшой процент (10-20%) от общего времени производства (cycle time), потому что бОльшая часть времени теряется в очередях (ожиданиях) и тратится на перемещения работы из одного состояния в другое.

Рисунок 9. Пример графика эффективности конвейера непрерывной поставки

Количество развертываний и релизов за интервал времени

Эта метрика демонстрирует, насколько программа продвигается к более частым развертываниям и релизам. Обычно интервалом времени является PI (Program Increment).

Рисунок 10. Количество развертываний и релизов в течение PI

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

Рисунок 11. Количество развертываний и релизов в разрезе итераций

Восстановление в течение времени

Этот отчет показывает количество откатов (как откатов программного кода, так и выключения фичи через механизм feature toggling). Даты развертываний и релизов отображаются на графике в виде вертикальных линий, чтобы видеть их корреляцию с откатами.

Рисунок 12. Восстановление в течение времени

Учет инноваций и опережающие метрики

Одной из целей процесса непрерывной поставки является обеспечение организации возможностью проводить быстрые эксперименты для проверки гипотез. В результате, как минимальная фича, ценная для потребителей (Minimum Marketable Feature, MMF), так и минимально-жизнеспособный продукт (Minimal Viable Product, MVP) должны иметь опережающие метрики, по которым можно оценить прогресс достижения гипотезы.

Таблица 3 показывает метрики сайта SAFe, которые являются опережающими для разработки фреймворка.

Таблица 3. Опережающие метрики учета инноваций с сайта SAFe

Радар DevOps-здоровья

Рисунок показывает 16 секторов для оценки программой своей зрелости. Сектор оценивается по шкале от 1 до 10, где каждый диапазон цифр имеет свою метафору: Сидим (1-2), Ползем (3-4), Идем (5-6), Бежим (7-8), Летим (9-10):

Рисунок 13. Радар DevOps-здоровья

Откройте таблицу для оценки и построения радара.

Метрики команды

Метрики итерации

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

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

В течение системной демонстрации представители бизнеса оценивают актуальное количество бизнес-ценности, доставленной командой по каждой PI-цели.

Рисунок 14. Фактическая оценка бизнес-ценности в разрезе PI-целей команды

Заслуживающий доверия поезд должен работать на уровне 80-100%. Это позволяет представителям бизнеса опираться на план PI.

Примечания от том, как строится график:

Сумма данной метрики по всем командам поезда называется метрикой предсказуемости программы (Program Predictability measure).

Самооценка команды

Agile-команда постоянно оценивает и улучшает свою работу. Ниже приведем пример подобного инструмента для оценки. После заполнения таблицы автоматически строиться радар. Построение этого радара позволяет понять, в каком состоянии команда сейчас и выявить точки роста.

Рисунок 15. Радар самооценки команды.

Откройте таблицу для оценки и построения радара.

Источник