Продуктовая группа с бюджетом $24 млн объединяет 10 команд и 96 человек, которые работают над тремя продуктами на общей платформе, используют двухнедельные итерации и получают финансирование поквартально на следующие 18 месяцев. Какой подход к масштабированию вы выберете, не внедряя весь фреймворк по умолчанию?

Я сначала определю потоки ценности разработки, потому что общая платформа сама по себе не доказывает, что все 10 команд должны входить в один ART. - Продуктовые и инженерные руководители нанесут на карту путь каждого продукта от спроса до выпущенной ценности, включая клиентов, ритм релизов, границы систем, передачи и повторяющиеся зависимости. - Если все 10 команд должны совместно выпускать одно интегрированное решение, я протестирую один ART; если три продукта выпускаются независимо, я сохраню отдельные продуктовые группы и задам для платформы явные сервисные правила и правила зависимостей. - Я зафиксирую решение после двухнедельной сессии картирования и пересмотрю его через два цикла планирования по возрасту зависимостей, частоте интегрированной поставки и стоимости координации с лимитом 8% емкости.

Шесть feature-команд из 54 человек создают один продукт для электронной коммерции из единого Product Backlog, работают двухнедельными Спринтами и должны за девять месяцев сократить lead time фич с 42 до 25 дней в рамках дорожной карты на $7 млн. Вы выберете LeSS, SAFe, Nexus или облегченную координацию?

Я выберу LeSS, потому что один продукт, один Product Owner, один Product Backlog и шесть feature-команд соответствуют его рабочей модели. - Вместе с Product Owner я буду вести схему внедрения LeSS, где определены граница продукта, реорганизация команд, единый ритм Спринта, Overall Product Backlog Refinement, Sprint Review и Overall Retrospective. - Я заложу четыре недели на коучинг перехода к многокомандной feature-модели и уберу отдельные программные роли, а Product Owner сохранит ответственность за упорядочивание единого Product Backlog. - Мы продолжим через три месяца, только если не менее 70% элементов бэклога будут завершаться одной командой, а 85-й процентиль lead time фич будет двигаться к 25 дням.

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

Я введу Nexus, потому что основное ограничение состоит в создании единого интегрированного Инкремента пятью Scrum Teams в каждом Спринте. - Я создам рабочее соглашение Nexus под ответственностью Nexus Integration Team, охватывающее межкомандный refinement, Nexus Sprint Backlog, Nexus Daily Scrum, интегрированное тестирование и единый Nexus Sprint Review. - Nexus Integration Team, включающая Product Owner, Scrum Master и подходящих участников, отвечает за создание ценного интегрированного Инкремента; она не становится отдельной командой поставки и не раздает задачи. - Я ограничу настройку 180 человеко-часами и завершу интервенцию после шести Спринтов, когда интеграционных дефектов будет меньше 10 в квартал, а готовый интегрированный Инкремент будет появляться каждый Спринт.

Четыре автономные продуктовые команды из 36 человек выпускают изменения еженедельно, имеют лишь две зависимости в месяц, планируют двухнедельными Спринтами и работают с шестимесячным горизонтом роста на $3 млн. Добавите ли вы фреймворк масштабирования?

Я не буду его добавлять, потому что количество зависимостей не оправдывает постоянные масштабированные роли и события. - Вместе с четырьмя Product Owners я буду отвечать за одностраничную политику координации с ежемесячным обзором продуктовой группы, асинхронным журналом зависимостей и эскалацией только элементов старше пяти рабочих дней. - Каждая команда сохраняет собственные Scrum-ответственности и Product Backlog, а сменяющийся Scrum Master фасилитирует 45-минутный ежемесячный обзор стоимостью менее 12 человеко-часов в месяц. - Мы вернемся к Nexus, LeSS или ART, только если общих зависимостей станет больше восьми в месяц, понадобятся интегрированные релизы или возраст зависимостей будет выше 10 дней два месяца подряд.

Восемь команд из 78 человек создают единый регулируемый медицинский продукт двухнедельными итерациями, ежеквартально проходят проверки доказательств и располагают 12 месяцами и $18 млн для получения разрешения. Как вы адаптируете SAFe, не превращая compliance в дополнительные церемонии?

Я использую ART по Essential SAFe и встрою compliance-работу в Definition of Done и ART Backlog вместо параллельного водопадного трека. - Release Train Engineer будет отвечать за 10-недельный календарь ART, а Quality и Regulatory будут владеть картой доказательств, связывающей каждый контроль с фичами, enablers, тестами и датами проверок. - Product Management упорядочивает ART Backlog, System Architect направляет архитектурный задел, а Скрам-мастера коучат команды создавать доказательства в каждой двухнедельной итерации. - Мы сохраним только те события, которые дают трассируемое доказательство или решение, при готовности к разрешению выше 95% и стоимости координации ниже 10% бюджета поставки в $18 млн.

ART из восьми команд зависит от четырех специалистов по безопасности и данным, каждый из которых доступен на 30-50% времени, а также использует платформу развертывания отдельной продуктовой команды. Как вы представите эти два вида поддержки на PI Planning?

Я представлю дефицитных специалистов как Shared Services в ART, а платформу развертывания сохраню отдельным продуктом со своим бэклогом и сервисной границей. - Представители Shared Services участвуют в нужных командных сессиях PI Planning, публикуют емкость по итерациям и размещают датированные зависимости от специалистов на ART planning board вместо вымышленной команды с полной занятостью. - Product Management упорядочивает Features в ART Backlog, Product Owners упорядочивают Team Backlogs, а product manager платформы упорядочивает платформенный спрос по опубликованным уровням сервиса и технической стратегии. - RTE фасилитирует прозрачность емкости и зависимостей, но запросы к платформе остаются в платформенном бэклоге; модель пересматривается, если перегруз специалистов превышает 10% или lead time платформенного запроса превышает 10 рабочих дней.

Десять feature-команд из 92 человек работают над единым глобальным маркетплейсом, выпускают изменения еженедельно, используют двухнедельные Спринты и должны за 12 месяцев вдвое сократить 46-дневный путь от идеи до рынка при бюджете $16 млн. Вы выберете LeSS Huge или Essential SAFe?

Я выберу LeSS Huge, если руководство готово принять один продукт, одного общего Product Owner и feature-команды, организованные вокруг клиентской ценности. - Вместе с общим Product Owner я определю две клиентские Requirement Areas по пять команд в каждой, сохранив каждую область в диапазоне LeSS Huge от четырех до восьми команд и единый Product Backlog. - Area Product Owners будут специализироваться на refinement своих областей, не подменяя общего Product Owner, а Scrum Masters будут коучить переход к feature-командам и Overall Retrospective. - Я ограничу первые два квартала реорганизации и коучинга суммой $600 000 и продолжу, только если межобластные передачи сократятся на 40%, а 85-й процентиль пути от идеи до рынка станет ниже 30 дней.

Девять команд из 84 человек объединяют разработку оборудования, прошивки и облака, интегрируются каждые 12 недель, работают двухнедельными командными итерациями и имеют бюджет $25 млн на 18 месяцев. Какую модель координации вы выберете?

Я выберу один ART по Essential SAFe с 12-недельным Planning Interval, потому что синхронная интеграция и фиксированные сроки поставки оборудования определяют потребность в координации. - Release Train Engineer будет вести календарь событий ART и planning board, Product Management будет владеть Features, а System Architect будет отвечать за интерфейсные решения и архитектурный задел. - ART будет проводить System Demo после каждой двухнедельной итерации, а отдельный четырехнедельный обзор вех будет отслеживать даты поставщиков и оборудования; команды продолжат самостоятельно планировать работу итераций. - Модель пройдет проверку после двух PI, только если не менее 80% датированных вех будут достигнуты в согласованные окна, возраст интерфейсных зависимостей останется ниже 14 дней, а накладные расходы ART не превысят $1,5 млн в год.

Девять Scrum-команд поставляют три независимо выпускаемых SaaS-продукта в рамках одной стратегии, но общие зависимости от identity и данных создают 18 нерешенных межпродуктовых решений в месяц. Руководство предлагает Nexus, хотя единого Product Backlog и интегрированного Инкремента нет. Что вы примените?

Я протестирую минимальную схему координации Scrum@Scale вместо Nexus, потому что этим командам нужна сеть между продуктами, а не один Nexus для единого интегрированного Инкремента. - Scrum of Scrums будет дважды в неделю разбирать возраст зависимостей и препятствия, а Scrum of Scrums Master будет фасилитировать эскалацию, не назначая работу девяти командам. - Executive MetaScrum объединит трех Product Owners и стейкхолдеров с правами решений для упорядочивания общего спроса на identity и данные, при этом каждый Product Owner сохранит бэклог независимо выпускаемого продукта. - Я сохраню восьминедельный пилот, только если число нерешенных решений упадет с 18 до менее шести в месяц, а координация останется ниже 60 человеко-часов ежемесячно; стоимостью будут два дополнительных форума решений и явные масштабированные роли.

Три ART с 24 командами и внешний поставщик сигнализации должны каждые шесть месяцев поставлять единое интегрированное решение для управления железной дорогой, причем ни один ART не может самостоятельно проверить клиентский результат. Когда Solution Train действительно оправдан?

Я обосную Solution Train, только если интегрированное решение требует постоянной координации нескольких ART и поставщиков, которую нельзя вместить в один ART. - Доказательства должны показывать единую границу решения, общий Solution Intent, межпоездные Capabilities, интерфейсные вехи и интеграционные решения с экономическим влиянием на все три ART. - Если работу можно перестроить в один ART или разделить стабильными интерфейсами, я выберу эти более дешевые варианты; большой бюджет или число команд сами по себе недостаточны. - После выполнения критериев Solution Management, Solution Architect и Solution Train Engineer принимают свои отдельные зоны ответственности, а дополнительный уровень пересматривается через два инкремента по задержке интеграции и стоимости координации.

Восемь команд из 76 человек в двух часовых поясах начинают 10-недельный Planning Interval, работают двухнедельными итерациями и должны за шесть месяцев достичь клиентского результата на $6 млн. Как вы спроектируете PI Planning?

Я проведу двухдневный PI Planning с единым результатом, защищенными командными сессиями и немедленным разбором межкомандных ограничений. - Release Train Engineer владеет повесткой и чеклистом готовности, Product Management приносит видение и упорядоченные фичи, а Business Owners дают бизнес-контекст и полномочия для решений. - Каждая команда создает план на основе емкости и черновые PI Objectives, затем ART формирует planning board, распределяет программные риски по ROAM и обновляет планы после management review and problem-solving. - Планирование завершается только при участии 100% команд, наличии владельца у каждой критической зависимости, отсутствии бесхозных рисков и финальном confidence vote не ниже 3 из 5 от каждой команды.

Шесть команд из 54 человек планируют восьминедельный PI двухнедельными итерациями, имеют 30 фич-кандидатов и должны достичь четырех измеримых продуктовых результатов в рамках полугодовой дорожной карты на $5 млн. Как вы сформируете полезные PI Objectives?

Я помогу командам сформулировать PI Objectives как измеримые бизнес- или технические результаты, а не как повторение списка фич. - Product Management владеет упорядоченным ART Backlog, каждая команда владеет своими PI Objectives и фиксирует committed и uncommitted objectives в общем документе целей. - Business Owners назначают planned business value после обсуждения результатов, а Release Train Engineer помогает добиться согласованности, не формулируя и не оценивая цели за них. - Артефакт готов, когда все 30 фич связаны максимум с четырьмя темами результатов, у каждой цели есть мера и ни одна команда не планирует больше 85% емкости.

Девять команд из 86 человек работают двухнедельными итерациями внутри 10-недельного PI, резервируют от 5% до 30% на поддержку и имеют релиз на $9 млн через пять месяцев. Как сделать планирование емкости сопоставимым без стандартизации velocity?

Я стандартизирую допущения о емкости и категории риска, но не story points или velocity команд. - Каждая команда владеет таблицей емкости на пять итераций, используя доступные человеко-дни, плановый отпуск, долю поддержки и исторический диапазон незапланированной работы. - Product Management использует эти таблицы для последовательности фич, Release Train Engineer показывает совокупную емкость, а Скрам-мастера проверяют скрытую перегрузку в командных сессиях. - Планирование завершается, когда каждая команда использует не более 85% доступной емкости, резервы поддержки опираются на последние три PI и ни одна фича не требует конвертации velocity между командами.

Семь команд из 64 человек имеют 48 плановых зависимостей между двухнедельными итерациями и горизонт релиза в пять месяцев, а текущий возраст зависимостей равен 18 дням. Как вы создадите и будете использовать доску зависимостей PI?

Я превращу ART planning board в прогноз дат фич и межкомандных зависимостей, а не в декоративную стену после PI Planning. - Во время планирования поставляющая и принимающая команды совместно владеют карточкой каждой зависимости с нужной итерацией, условием приемки, контактами и ссылкой на соответствующую фичу. - Release Train Engineer отвечает за чистоту доски и еженедельно рассматривает возраст в ART Sync, команды обновляют статусы, а Product Management решает вопросы последовательности. - Доска полезна, когда у всех 48 зависимостей есть владельцы, ни одна критическая связь не пропускает нужную дату, а 85-й процентиль возраста снижается с 18 до менее 10 дней к концу PI.

Восемь команд из 80 человек завершают двухдневный PI Planning для 10-недельного интервала, но первый confidence vote в среднем равен 2,8 из 5, а дорожная карта предполагает $7 млн на шесть месяцев. Что должно произойти до закрытия планирования?

Я не закрою планирование, выявлю причины низких голосов и скорректирую план до повторного confidence vote. - Release Train Engineer владеет анонимным журналом опасений, просит каждого проголосовавшего ниже 3 назвать ограничение и направляет вопросы scope в Product Management, а вопросы емкости обратно командам. - После management review and problem-solving команды обновляют PI Objectives, зависимости и риски; Business Owners уточняют приоритеты, не подталкивая оценки вверх. - PI Planning завершается, только когда средняя оценка каждой команды не ниже 3, у всех существенных опасений есть владелец, а снятый scope виден в финальной planning board и наборе целей.

Десять команд из 100 человек работают двухнедельными итерациями, имеют 35 активных зависимостей, встречаются в ритме 10-недельного PI и планируют поставку на девять месяцев. Как вы спроектируете ART Sync?

Я проведу еженедельный 45-минутный ART Sync, объединяющий перспективы Coach Sync и PO Sync вокруг потока, scope и препятствий. - Release Train Engineer владеет ориентированной на решения повесткой, которую питают planning board, отчет о возрасте зависимостей, статус PI Objectives и главные препятствия ART. - Scrum Masters и Team Coaches приносят данные потока и препятствий, Product Owners и Product Management приносят решения по scope и приоритетам; RTE фасилитирует, но не определяет порядок бэклога. - Событие остается еженедельным, пока решения закрываются за три рабочих дня, возраст критических зависимостей ниже 10 дней, а последующая работа занимает менее 100 человеко-часов на PI.

Семь команд из 68 человек создают интегрированный сервис двухнедельными итерациями, планируют каждые 10 недель и имеют релиз на $10 млн через восемь месяцев. Как вы спроектируете System Demo?

В конце каждой итерации я буду показывать интегрированный Инкремент из среды, близкой к production, а не отдельные слайды команд. - System Team владеет средой демонстрации и координирует интеграционную готовность, команды остаются ответственными за работающие срезы, а Release Train Engineer отвечает за 60-минутный план фасилитации. - Product Management связывает прогресс с PI Objectives и заносит обратную связь стейкхолдеров в ART Backlog, а System Architect фиксирует архитектурные выводы, не превращая demo в гейт. - Demo успешно, когда все семь команд участвуют в одном интегрированном потоке, не менее 90% запланированных срезов запускаются вживую, а принятая обратная связь получает владельца за два рабочих дня.

Девять команд из 90 человек завершают 10-недельный PI после пяти двухнедельных итераций, имеют медианный lead time фич в 24 дня и должны за 12 месяцев достичь 16 дней. Как вы проведете Inspect and Adapt?

Я проведу полное событие Inspect and Adapt: PI System Demo, количественный и качественный обзор, затем сфокусированный problem-solving workshop. - Release Train Engineer владеет протоколом события, Business Owners дают actual business value, а Product Management связывает поставленные результаты со следующими решениями по ART Backlog. - Команды используют данные потока и артефакт анализа первопричины для выбора одной системной проблемы, затем создают элементы бэклога улучшений с владельцами вместо широкого списка действий. - Событие завершается максимум с тремя профинансированными улучшениями со сроком в следующем PI, а lead time фич должен двигаться с 24 к 16 дням без сравнения velocity команд.

Шесть команд из 58 человек распределены по пяти часовым поясам, используют двухнедельные итерации и 10-недельный PI, а годовой бюджет координации равен $400 000. Как сделать распределенный PI Planning инклюзивным и доступным по стоимости?

Я сохраню единый результат двухдневного PI Planning, разделив живую работу на два четырехчасовых окна пересечения и локальные фасилитируемые сессии. - Release Train Engineer владеет картой часовых поясов, пакетом готовности, записанным контекстом, planning board в Miro и журналом решений, опубликованными за 48 часов. - Локальные Скрам-мастера фасилитируют командные сессии, Product Management и Business Owners присутствуют в обоих окнах решений, а асинхронные вопросы получают ответ за четыре часа. - Схема проходит проверку, когда все шесть команд завершают цели и зависимости, участие выше 90%, никто не работает вне 07:00-20:00 местного времени, а годовая стоимость ниже $400 000.

Восемь команд из 75 человек используют двухнедельные итерации, 10-недельный PI и шестимесячную дорожную карту на $8 млн, но руководство хочет увидеть единый календарь событий ART до финансирования. Какой ритм вы предложите?

Я предложу минимальный вложенный ритм: еженедельный ART Sync, System Demo в каждой итерации, PI Planning в начале интервала и Inspect and Adapt в конце. - Release Train Engineer владеет шестимесячной картой событий с целью, обязательными ролями, входным артефактом, выходным решением и бюджетом человеко-часов для каждого события ART. - Product Management владеет решениями по бэклогу и содержанию, Business Owners оценивают PI Objectives, System Team поддерживает интеграцию, а Скрам-мастера коучат участие команд. - Финансирование начинается, когда накладные расходы событий ниже 8% емкости ART, у каждого события есть измеримый выход, а дублирующие статусные встречи удалены в первом PI.

Вопросы на собеседовании: Скрам-мастер

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Старший скрам-мастер.

Смотреть пример резюме: Скрам-мастер →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

scalingiteration

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

Продуктовые и инженерные руководители нанесут на карту путь каждого продукта от спроса до выпущенной ценности, включая клиентов, ритм релизов, границы систем, передачи и повторяющиеся зависимости.
Если все 10 команд должны совместно выпускать одно интегрированное решение, я протестирую один ART; если три продукта выпускаются независимо, я сохраню отдельные продуктовые группы и задам для платформы явные сервисные правила и правила зависимостей.
Я зафиксирую решение после двухнедельной сессии картирования и пересмотрю его через два цикла планирования по возрасту зависимостей, частоте интегрированной поставки и стоимости координации с лимитом 8% емкости.

Зачем это спрашивают: Интервьюер проверяет, определяет ли кандидат потоки ценности разработки до выбора SAFe и не выводит необходимость одного ART только из общей технологии.

agileroadmapbacklog

Я выберу LeSS, потому что один продукт, один Product Owner, один Product Backlog и шесть feature-команд соответствуют его рабочей модели.

Вместе с Product Owner я буду вести схему внедрения LeSS, где определены граница продукта, реорганизация команд, единый ритм Спринта, Overall Product Backlog Refinement, Sprint Review и Overall Retrospective.
Я заложу четыре недели на коучинг перехода к многокомандной feature-модели и уберу отдельные программные роли, а Product Owner сохранит ответственность за упорядочивание единого Product Backlog.
Мы продолжим через три месяца, только если не менее 70% элементов бэклога будут завершаться одной командой, а 85-й процентиль lead time фич будет двигаться к 25 дням.

Зачем это спрашивают: Сильный ответ учитывает организационные предпосылки LeSS и не добавляет программную иерархию в контекст одного продукта.

agilereleasesscaling

Я введу Nexus, потому что основное ограничение состоит в создании единого интегрированного Инкремента пятью Scrum Teams в каждом Спринте.

Я создам рабочее соглашение Nexus под ответственностью Nexus Integration Team, охватывающее межкомандный refinement, Nexus Sprint Backlog, Nexus Daily Scrum, интегрированное тестирование и единый Nexus Sprint Review.
Nexus Integration Team, включающая Product Owner, Scrum Master и подходящих участников, отвечает за создание ценного интегрированного Инкремента; она не становится отдельной командой поставки и не раздает задачи.
Я ограничу настройку 180 человеко-часами и завершу интервенцию после шести Спринтов, когда интеграционных дефектов будет меньше 10 в квартал, а готовый интегрированный Инкремент будет появляться каждый Спринт.

Зачем это спрашивают: Интервьюер проверяет точное понимание ответственности в Nexus и умение связать стоимость фреймворка с результатом интеграции.

agiledeploymentdependencies

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

Вместе с четырьмя Product Owners я буду отвечать за одностраничную политику координации с ежемесячным обзором продуктовой группы, асинхронным журналом зависимостей и эскалацией только элементов старше пяти рабочих дней.
Каждая команда сохраняет собственные Scrum-ответственности и Product Backlog, а сменяющийся Scrum Master фасилитирует 45-минутный ежемесячный обзор стоимостью менее 12 человеко-часов в месяц.
Мы вернемся к Nexus, LeSS или ART, только если общих зависимостей станет больше восьми в месяц, понадобятся интегрированные релизы или возраст зависимостей будет выше 10 дней два месяца подряд.

Зачем это спрашивают: Вопрос проверяет, может ли кандидат отказаться от карго-культа фреймворков, когда реальной связанности соответствует дешевая координация.

iteration

Я использую ART по Essential SAFe и встрою compliance-работу в Definition of Done и ART Backlog вместо параллельного водопадного трека.

Release Train Engineer будет отвечать за 10-недельный календарь ART, а Quality и Regulatory будут владеть картой доказательств, связывающей каждый контроль с фичами, enablers, тестами и датами проверок.
Product Management упорядочивает ART Backlog, System Architect направляет архитектурный задел, а Скрам-мастера коучат команды создавать доказательства в каждой двухнедельной итерации.
Мы сохраним только те события, которые дают трассируемое доказательство или решение, при готовности к разрешению выше 95% и стоимости координации ниже 10% бюджета поставки в $18 млн.

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

deployment

Я представлю дефицитных специалистов как Shared Services в ART, а платформу развертывания сохраню отдельным продуктом со своим бэклогом и сервисной границей.

Представители Shared Services участвуют в нужных командных сессиях PI Planning, публикуют емкость по итерациям и размещают датированные зависимости от специалистов на ART planning board вместо вымышленной команды с полной занятостью.
Product Management упорядочивает Features в ART Backlog, Product Owners упорядочивают Team Backlogs, а product manager платформы упорядочивает платформенный спрос по опубликованным уровням сервиса и технической стратегии.
RTE фасилитирует прозрачность емкости и зависимостей, но запросы к платформе остаются в платформенном бэклоге; модель пересматривается, если перегруз специалистов превышает 10% или lead time платформенного запроса превышает 10 рабочих дней.

Зачем это спрашивают: Сильный ответ отличает частично доступные Shared Services, поддерживающие ART, от платформенной команды, которая владеет внутренним продуктом и бэклогом.

agiledeployment

Я выберу LeSS Huge, если руководство готово принять один продукт, одного общего Product Owner и feature-команды, организованные вокруг клиентской ценности.

Вместе с общим Product Owner я определю две клиентские Requirement Areas по пять команд в каждой, сохранив каждую область в диапазоне LeSS Huge от четырех до восьми команд и единый Product Backlog.
Area Product Owners будут специализироваться на refinement своих областей, не подменяя общего Product Owner, а Scrum Masters будут коучить переход к feature-командам и Overall Retrospective.
Я ограничу первые два квартала реорганизации и коучинга суммой $600 000 и продолжу, только если межобластные передачи сократятся на 40%, а 85-й процентиль пути от идеи до рынка станет ниже 30 дней.

Зачем это спрашивают: Интервьюер проверяет правильное применение Requirement Areas в LeSS Huge и готовность явно зафиксировать организационные предпосылки.

iteration

Я выберу один ART по Essential SAFe с 12-недельным Planning Interval, потому что синхронная интеграция и фиксированные сроки поставки оборудования определяют потребность в координации.

Release Train Engineer будет вести календарь событий ART и planning board, Product Management будет владеть Features, а System Architect будет отвечать за интерфейсные решения и архитектурный задел.
ART будет проводить System Demo после каждой двухнедельной итерации, а отдельный четырехнедельный обзор вех будет отслеживать даты поставщиков и оборудования; команды продолжат самостоятельно планировать работу итераций.
Модель пройдет проверку после двух PI, только если не менее 80% датированных вех будут достигнуты в согласованные окна, возраст интерфейсных зависимостей останется ниже 14 дней, а накладные расходы ART не превысят $1,5 млн в год.

Зачем это спрашивают: Ответ должен связать SAFe с экономикой интеграции, требовать System Demo в каждой итерации и считать четырехнедельную проверку обзором вех с долей вовремя достигнутых вех, а не предсказуемостью ART по SAFe.

agiledependenciescloud

Я протестирую минимальную схему координации Scrum@Scale вместо Nexus, потому что этим командам нужна сеть между продуктами, а не один Nexus для единого интегрированного Инкремента.

Scrum of Scrums будет дважды в неделю разбирать возраст зависимостей и препятствия, а Scrum of Scrums Master будет фасилитировать эскалацию, не назначая работу девяти командам.
Executive MetaScrum объединит трех Product Owners и стейкхолдеров с правами решений для упорядочивания общего спроса на identity и данные, при этом каждый Product Owner сохранит бэклог независимо выпускаемого продукта.
Я сохраню восьминедельный пилот, только если число нерешенных решений упадет с 18 до менее шести в месяц, а координация останется ниже 60 человеко-часов ежемесячно; стоимостью будут два дополнительных форума решений и явные масштабированные роли.

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

validation

Я обосную Solution Train, только если интегрированное решение требует постоянной координации нескольких ART и поставщиков, которую нельзя вместить в один ART.

Доказательства должны показывать единую границу решения, общий Solution Intent, межпоездные Capabilities, интерфейсные вехи и интеграционные решения с экономическим влиянием на все три ART.
Если работу можно перестроить в один ART или разделить стабильными интерфейсами, я выберу эти более дешевые варианты; большой бюджет или число команд сами по себе недостаточны.
После выполнения критериев Solution Management, Solution Architect и Solution Train Engineer принимают свои отдельные зоны ответственности, а дополнительный уровень пересматривается через два инкремента по задержке интеграции и стоимости координации.

Зачем это спрашивают: Senior-ответ создает Solution Train для действительно крупного интегрированного решения, а не как автоматический уровень над одним ART.

designiteration

Я проведу двухдневный PI Planning с единым результатом, защищенными командными сессиями и немедленным разбором межкомандных ограничений.

Release Train Engineer владеет повесткой и чеклистом готовности, Product Management приносит видение и упорядоченные фичи, а Business Owners дают бизнес-контекст и полномочия для решений.
Каждая команда создает план на основе емкости и черновые PI Objectives, затем ART формирует planning board, распределяет программные риски по ROAM и обновляет планы после management review and problem-solving.
Планирование завершается только при участии 100% команд, наличии владельца у каждой критической зависимости, отсутствии бесхозных рисков и финальном confidence vote не ниже 3 из 5 от каждой команды.

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

roadmapiterationroadmapping

Я помогу командам сформулировать PI Objectives как измеримые бизнес- или технические результаты, а не как повторение списка фич.

Product Management владеет упорядоченным ART Backlog, каждая команда владеет своими PI Objectives и фиксирует committed и uncommitted objectives в общем документе целей.
Business Owners назначают planned business value после обсуждения результатов, а Release Train Engineer помогает добиться согласованности, не формулируя и не оценивая цели за них.
Артефакт готов, когда все 30 фич связаны максимум с четырьмя темами результатов, у каждой цели есть мера и ни одна команда не планирует больше 85% емкости.

Зачем это спрашивают: Сильный ответ различает, кто формулирует, приоритизирует и оценивает PI Objectives, и сохраняет их измеримость.

releasescapacity-planningcapacity

Я стандартизирую допущения о емкости и категории риска, но не story points или velocity команд.

Каждая команда владеет таблицей емкости на пять итераций, используя доступные человеко-дни, плановый отпуск, долю поддержки и исторический диапазон незапланированной работы.
Product Management использует эти таблицы для последовательности фич, Release Train Engineer показывает совокупную емкость, а Скрам-мастера проверяют скрытую перегрузку в командных сессиях.
Планирование завершается, когда каждая команда использует не более 85% доступной емкости, резервы поддержки опираются на последние три PI и ни одна фича не требует конвертации velocity между командами.

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

dependenciesreleasesiteration

Я превращу ART planning board в прогноз дат фич и межкомандных зависимостей, а не в декоративную стену после PI Planning.

Во время планирования поставляющая и принимающая команды совместно владеют карточкой каждой зависимости с нужной итерацией, условием приемки, контактами и ссылкой на соответствующую фичу.
Release Train Engineer отвечает за чистоту доски и еженедельно рассматривает возраст в ART Sync, команды обновляют статусы, а Product Management решает вопросы последовательности.
Доска полезна, когда у всех 48 зависимостей есть владельцы, ни одна критическая связь не пропускает нужную дату, а 85-й процентиль возраста снижается с 18 до менее 10 дней к концу PI.

Зачем это спрашивают: Вопрос оценивает наличие двустороннего владения, рабочего ритма и измеримой цели потока у доски зависимостей.

roadmaproadmapping

Я не закрою планирование, выявлю причины низких голосов и скорректирую план до повторного confidence vote.

Release Train Engineer владеет анонимным журналом опасений, просит каждого проголосовавшего ниже 3 назвать ограничение и направляет вопросы scope в Product Management, а вопросы емкости обратно командам.
После management review and problem-solving команды обновляют PI Objectives, зависимости и риски; Business Owners уточняют приоритеты, не подталкивая оценки вверх.
PI Planning завершается, только когда средняя оценка каждой команды не ниже 3, у всех существенных опасений есть владелец, а снятый scope виден в финальной planning board и наборе целей.

Зачем это спрашивают: Интервьюер ожидает, что confidence vote используется как контроль планирования, а не ритуал настроения или формальное одобрение.

designdependenciesiteration

Я проведу еженедельный 45-минутный ART Sync, объединяющий перспективы Coach Sync и PO Sync вокруг потока, scope и препятствий.

Release Train Engineer владеет ориентированной на решения повесткой, которую питают planning board, отчет о возрасте зависимостей, статус PI Objectives и главные препятствия ART.
Scrum Masters и Team Coaches приносят данные потока и препятствий, Product Owners и Product Management приносят решения по scope и приоритетам; RTE фасилитирует, но не определяет порядок бэклога.
Событие остается еженедельным, пока решения закрываются за три рабочих дня, возраст критических зависимостей ниже 10 дней, а последующая работа занимает менее 100 человеко-часов на PI.

Зачем это спрашивают: Сильный ответ различает две перспективы внутри ART Sync и сохраняет зоны ответственности Product Management и команд.

system-designdesigniteration

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

System Team владеет средой демонстрации и координирует интеграционную готовность, команды остаются ответственными за работающие срезы, а Release Train Engineer отвечает за 60-минутный план фасилитации.
Product Management связывает прогресс с PI Objectives и заносит обратную связь стейкхолдеров в ART Backlog, а System Architect фиксирует архитектурные выводы, не превращая demo в гейт.
Demo успешно, когда все семь команд участвуют в одном интегрированном потоке, не менее 90% запланированных срезов запускаются вживую, а принятая обратная связь получает владельца за два рабочих дня.

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

iteration

Я проведу полное событие Inspect and Adapt: PI System Demo, количественный и качественный обзор, затем сфокусированный problem-solving workshop.

Release Train Engineer владеет протоколом события, Business Owners дают actual business value, а Product Management связывает поставленные результаты со следующими решениями по ART Backlog.
Команды используют данные потока и артефакт анализа первопричины для выбора одной системной проблемы, затем создают элементы бэклога улучшений с владельцами вместо широкого списка действий.
Событие завершается максимум с тремя профинансированными улучшениями со сроком в следующем PI, а lead time фич должен двигаться с 24 к 16 дням без сравнения velocity команд.

Зачем это спрашивают: Ответ должен показать все компоненты Inspect and Adapt и превратить доказательства в небольшой бэклог улучшений с владельцами.

distributediteration

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

Release Train Engineer владеет картой часовых поясов, пакетом готовности, записанным контекстом, planning board в Miro и журналом решений, опубликованными за 48 часов.
Локальные Скрам-мастера фасилитируют командные сессии, Product Management и Business Owners присутствуют в обоих окнах решений, а асинхронные вопросы получают ответ за четыре часа.
Схема проходит проверку, когда все шесть команд завершают цели и зависимости, участие выше 90%, никто не работает вне 07:00-20:00 местного времени, а годовая стоимость ниже $400 000.

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

roadmapiterationroadmapping

Я предложу минимальный вложенный ритм: еженедельный ART Sync, System Demo в каждой итерации, PI Planning в начале интервала и Inspect and Adapt в конце.

Release Train Engineer владеет шестимесячной картой событий с целью, обязательными ролями, входным артефактом, выходным решением и бюджетом человеко-часов для каждого события ART.
Product Management владеет решениями по бэклогу и содержанию, Business Owners оценивают PI Objectives, System Team поддерживает интеграцию, а Скрам-мастера коучат участие команд.
Финансирование начинается, когда накладные расходы событий ниже 8% емкости ART, у каждого события есть измеримый выход, а дублирующие статусные встречи удалены в первом PI.

Зачем это спрашивают: Интервьюер ожидает интегрированный ритм SAFe с явной стоимостью и зонами ответственности, а не календарь церемоний.

Закрытые вопросы

21
Восемь команд из 74 человек используют двухнедельные итерации, выпускают релизы ежемесячно и показывают медианный цикл фич в 38 дней в продуктовой группе с годовым бюджетом $11 млн. Какой межкомандный дашборд потока вы создадите на следующие два квартала?
releasesiterationcross-team
22
Шесть команд из 57 человек выпускают изменения еженедельно, планируют двухнедельными Спринтами, а объем незавершенной работы продуктовой группы вырос с 45 до 78 элементов за шесть недель при неизменном throughput 18 элементов в неделю. Как вы используете cumulative flow diagram?
agiledeploymentthroughput
23
Десять команд из 102 человек ежемесячно рассматривают инвестиции, имеют 27 инициатив на годовой бюджет $12 млн и могут одновременно поддерживать только восемь активных инициатив. Как вы внедрите Portfolio Kanban?
agileportfolio
24
Семь команд одного ART планируют двухнедельными итерациями, имеют 14 межкомандных зависимостей и нуждаются в шестимесячном прогнозе дорожной карты на $9 млн в Jira Advanced Plans. Как вы настроите план и управление им?
configdependenciesiteration
25
Восемь команд из 80 человек завершают 10-недельный PI двухнедельными итерациями, имея planned business value 160 и actual business value 128 по своим PI Objectives. Как вы будете сообщать о предсказуемости следующие четыре PI?
iteration
26
ART из девяти команд завершает PI Planning с 26 программными рисками, девятью рисками без состояния ROAM и просроченными действиями из прошлого PI. Какую рабочую политику вы установите для программных рисков?
program-management
27
Шесть команд из 56 человек планируют поквартально, имеют 42 предложенные PI Objectives против четырех OKR компании и управляют годовой дорожной картой на $8 млн. Как вы согласуете работу, не превращая OKR в дерево задач?
roadmapresilienceroadmapping
28
Десять команд из 98 человек выбирают работу на каждый 10-недельный PI, имеют 18 фич, конкурирующих за бюджет $9 млн, и могут профинансировать только 11 в этом интервале. Как вы примените WSJF без ложной точности?
29
Пять команд из 46 человек поставляют в среднем 12 сопоставимых по размеру фич в месяц, планируют каждые две недели и нуждаются в вероятностном прогнозе для 70 фич на следующие 16 недель. Как вы его построите?
probability
30
Восемь команд из 76 человек ежемесячно рассматривают портфель, тратят 62% емкости на фичи и 8% на техническое здоровье, а в 12-месячном плане на $14 млн flow time фич вырос с 30 до 44 дней. Как вы экономически перебалансируете работу?
portfoliocapacitycapacity-planning
31
Вы поддерживаете семь команд из 65 человек и каждые две недели менторите пять Скрам-мастеров на протяжении шести месяцев, а возраст командных препятствий варьируется от 4 до 18 дней. Как вы организуете менторство?
agilementoring
32
В девяти командах из 86 человек работают восемь Скрам-мастеров, команды используют двухнедельные Спринты, а на Community of Practice можно потратить 90 минут ежемесячно и $40 000 в год. Что вы создадите?
agile
33
Четыре Скрам-мастера поддерживают шесть команд из 58 человек на двухнедельных Спринтах, а у вас есть 12 недель, чтобы повысить долю завершенных действий ретроспектив с 35% до 70%. Как вы заключите коучинговый контракт?
agile
34
Восемь команд из 78 человек работают двухнедельными Спринтами, а руководство хочет видеть квартальные доказательства зрелости на протяжении девяти месяцев до продления коучингового бюджета $300 000. Как вы покажете доказательства без ранжирования команд?
agile
35
Шесть команд из 60 человек проводят ежеквартальную 90-минутную ретроспективу продуктовой группы, но обычно говорят лишь 12 человек, а межкомандные действия закрываются на 40%. Какую Liberating Structure вы примените следующие два квартала?
agilecross-team
36
Семь Скрам-мастеров поддерживают семь команд из 68 человек, встречаются раз в две недели и имеют три месяца, чтобы улучшить коучинговые ответы на повторяющиеся изменения Sprint Goal без внешнего курса за $20 000. Как вы примените Troika Consulting?
agile
37
Пять команд из 47 человек работают двухнедельными Спринтами, отвечают на ежемесячный опрос безопасности лишь на 48% и имеют шесть месяцев, чтобы улучшить открытое высказывание мнений до расширения продукта на $5 млн. Как повысить психологическую безопасность, не раскрывая людей?
agile
38
Шесть Скрам-мастеров поддерживают восемь команд из 76 человек на двухнедельных Спринтах, а три новых Скрам-мастера в течение четырехмесячного онбординга тратят 30% времени на решения по бэклогу и назначению задач. Как вы объясните границы ответственности?
agileonboardingbacklog
39
Четыре Скрам-мастера поддерживают четыре команды из 38 человек двухнедельными Спринтами, а на программу взаимного наблюдения есть 12 недель и учебный бюджет $15 000. Как не дать наблюдению превратиться в оценку эффективности?
agileprogram-managementperformance
40
Девять Скрам-мастеров поддерживают 10 команд из 96 человек, встречаются ежемесячно и имеют два квартала, чтобы сократить возраст бэклога Community of Practice со 110 до 45 дней при бюджете $60 000. Как вы примените Ecocycle Planning?
agilebacklog
41
Восемь компонентных команд из 82 человек работают двухнедельными итерациями, а 72% продуктовых элементов проходят минимум через три команды, создавая lead time фич в 51 день на девятимесячной дорожной карте $13 млн. Как вы примените Team Topologies?
roadmapcomponentsiteration
42
Шесть stream-aligned команд из 61 человека выпускают изменения еженедельно, каждая тратит 18% емкости на дублирование CI и observability, а продуктовая группа может инвестировать $2 млн за 12 месяцев в платформенную команду. Какую границу вы определите?
deploymentobservabilitycapacity
43
Семь продуктовых команд из 70 человек используют двухнедельные итерации, ждут знаний по облачной безопасности 16 дней и имеют 12 месяцев и $1,5 млн на миграцию. Создадите ли вы enabling team?
migrationsiteration
44
Пять команд из 49 человек выпускают релизы ежемесячно, но шесть редких специалистов поддерживают алгоритм ценообразования для всех команд, а компания имеет $4 млн и 18 месяцев на его расширение. Какой паттерн Team Topologies подходит?
pricingalgorithmsreleases
45
Девять команд из 90 человек владеют 31 сервисом, выпускают изменения каждые две недели, а 28% изменений требуют трех и более передач на согласование в годовом портфеле $15 млн. Как вы проясните границы владения?
portfoliodeploymentownership
46
Восемь команд из 77 человек еженедельно встречаются на ART Sync, имеют 44 организационных препятствия с медианным возрастом 21 день и должны за два квартала достичь 10 дней при бюджете улучшений $500 000. Какую систему вы создадите?
system-design
47
Шесть команд из 55 человек планируют ежемесячно, ждут архитектурных решений медианные 17 дней и имеют дорожную карту $9 млн на 12 месяцев с двухнедельными итерациями поставки. Как вы сократите задержку решений?
roadmaparchitecturelatency
48
Десять команд из 104 человек поставляют регулируемую банковскую платформу 10-недельными PI и двухнедельными итерациями, располагая $30 млн и 18 месяцами. Как вы спроектируете governance без встреч согласования в каждом Спринте?
agilegovernancedesign
49
Семь команд из 69 человек используют двухнедельные итерации, имеют enablement-бюджет $1,2 млн и нуждаются в 12-месячной дорожной карте перехода от проектных передач к продуктовому владению без одномоментной реорганизации. Что вы предложите?
roadmapiterationownership
50
Восемь команд из 84 человек планируют каждые 10 недель, имеют 58% работы, пересекающей границы команд, и медианную задержку решений 12 дней, а горизонт продуктовой группы составляет $16 млн и 12 месяцев. Как вы объедините изменения топологии, системы препятствий и governance?
governancelatency
51
У шести команд остаются 18 открытых зависимостей, интеграционное тестирование начнется через 15 рабочих дней, а burn-up релиза показывает лишь 62% готового прогнозного объема. Какое решение вы будете продвигать сейчас?
scope-managementreleasesdependencies
52
В пяти командах девять межкомандных зависимостей не решены уже 12 дней, два тимлида спорят о владении, а клиентский релиз должен состояться через 10 рабочих дней. Что вы сделаете в ближайшие 24 часа?
releasesdependenciesownership
53
На шестой неделе 10-недельного PI для шести команд 7 из 12 PI Objectives стали красными из-за задержки API поставщика на 4 недели, но Business Owners всё ещё ожидают исходный план. Какое решение вы фасилитируете?
procurementapi
54
Четырём командам нужен общий сервис аутентификации для запуска через 6 недель, но архитектурный задел опаздывает на 2 спринта, а оценки интеграции теперь превышают оставшееся окно на 30%. Что вы будете продвигать?
agilelaunchesauth
55
В первый день PI Planning восемь команд представляют черновые планы с 11 межкомандными конфликтами, загрузкой общих специалистов на 140% и двумя решениями по последовательности фич, которые не удалось принять в командных сессиях. Как вы проведете management review and problem-solving перед вторым днем?
cross-team
56
Стратегический клиент переносит контрактный срок на 3 недели раньше, 5 команд уже загружены плановой работой на 88%, а опоздание грозит штрафом в $2 млн. Как вы отреагируете?
capacity-planningcapacityestimation
57
Первая интегрированная демонстрация релиза пяти команд провалила 11 из 20 клиентских сценариев, до срока осталось 4 недели, а 27 дефектов пересекают границы команд. Что вы сделаете дальше?
releasesdefects
58
Десять команд взяли 26 PI Objectives, но данные после планирования показывают загрузку 130%, а 40% ключевых специалистов распределены между командами. Какое решение вы продвинете до начала исполнения?
capacity-planningcapacity
59
В релизе шести команд за 72 часа до запуска обнаружена зависимость от production-сертификата из другого подразделения, без которого 3 из 7 сервисов не стартуют. Что вы сделаете?
dependenciesreleases
60
Программа из семи команд пропустила 3 квартальных релиза подряд на 2-5 недель, а крупнейший клиент грозит уйти через 60 дней. Какое вмешательство вы начнёте первым?
program-managementreleases
61
CEO просит твёрдую дату поставки нового продукта на 12 месяцев вперёд после всего 2 недель discovery, а диапазон неопределённости шести команд составляет 40-90%. Что вы сделаете?
62
Портфель назначает 14 стратегических инициатив восьми командам на квартал, но анализ мощности показывает спрос 145%, а подтверждённые клиентские результаты есть только у трёх инициатив. Что вы фасилитируете?
portfoliocapacityvalidation
63
В шести командах два потока создания ценности претендуют на первый приоритет общей платформенной команды, у которой есть лишь 60% запрошенной мощности, а финансовый комитет соберётся через 48 часов. Что вы сделаете?
capacity-planningcapacity
64
VP публикует ежемесячный рейтинг девяти команд по velocity, и три нижние команды уже завышают оценки примерно на 35%. Как вы отреагируете?
delivery-metricsestimation
65
Руководство планирует привязать 20% годовых бонусов семи команд к росту story points, а политика запускается через 3 недели. Что вы сделаете?
launches
66
В середине фиксированного годового плана шести команд клиентские данные показывают, что 4 из 9 профинансированных функций имеют adoption ниже 5%, но руководители требуют выпустить все 9 к концу года. Что вы фасилитируете?
decision-making
67
За три недели до совета директоров вероятность поставить названный scope релиза к его дате падает с 80% до 45% при текущих допущениях, а от релиза зависит $6 млн ожидаемой выручки. Как вы сообщите о риске?
risk-managementscope-managementreleases
68
В портфеле восьми команд директор просит убрать 6 красных рисков с дашборда перед встречей с инвесторами через 2 дня, хотя у четырёх нет владельца смягчения. Что вы сделаете?
portfoliorisk-management
69
ART из шести команд зависит от трех специалистов по базам данных в Shared Services, доступных на 40% емкости, двое специалистов уйдут после этого PI, а их экспертиза нужна девяти Features. Как вы спланируете емкость и передачу знаний?
capacity-planningdatabasecapacity
70
Новое регулирование потребует около 25% мощности восьми команд, но портфельное руководство отказывается менять 17 квартальных обязательств со сроком через 9 недель. Что вы фасилитируете?
portfolioestimationcapacity
71
ART из восьми команд проводит все церемонии SAFe, но достигает только 41% PI Objectives, а срок принятия решений вырос с 4 до 11 дней за два PI. Что вы измените первым?
72
Шесть команд выпускают релизы ежемесячно, развертывание занимает девять дней, ручная интеграция и согласования создают 70% задержки, а восстановление после неудачного релиза в среднем занимает шесть часов. Как применить CALMR для выбора первого узкого места Continuous Delivery Pipeline?
deploymentci-cdtracking
73
Шесть компонентных команд передают работу через 4 очереди, медианный сквозной lead time равен 47 дням, из которых 31 день занимает ожидание. Какое вмешательство вы фасилитируете?
componentse2edata-structures
74
Еженедельный 90-минутный Scrum of Scrums для десяти команд превратился в статусный круг, а 13 зависимостей старше двух недель. Что вы сделаете на следующей неделе?
agiledependencies
75
Все семь команд сообщают об успешности sprint goal выше 90%, но системный lead time удвоился до 36 дней, а доля интегрированных дефектов у клиента достигла 12%. На что вы повлияете?
agilesystem-designdefects
76
Пять команд одного ART сообщают о predictability 95%, но аудит показывает, что они удаляют незавершенный scope за один день до каждого review и задним числом переклассифицируют 18% целей. Что вы сделаете?
scope-management
77
Business Owners ставят всем целям оценку 10 после того, как четыре команды достигли только 6 из 11 ожидаемых результатов, и отчёт PI выглядит идеальным. Что вы сделаете?
78
В ART из девяти команд System Team требует передавать ей ветки в последней итерации, поэтому интегрированный Инкремент появляется только раз в 10 недель, а открытыми остаются 31 интеграционный дефект. Как вы измените роль System Team?
system-designiterationdefects
79
Lean Portfolio Management просит scorecard SAFe Measure and Grow для ART из восьми команд, а PMO предлагает сделать главным показателем сумму story points. Что вы включите вместо нее?
portfolioaggregation
80
Портфельный Epic стоимостью $4 млн имеет исполнительного спонсора, но опирается только на непроверенные допущения о клиентах и выручке, а руководство хочет подключить все 10 команд в следующем квартале. Что вы фасилитируете до полного финансирования?
portfoliosponsor
81
После 6 месяцев agile-трансформации восьми команд lead time остался 52 дня, вовлечённость упала на 9 пунктов, а лидеры говорят, что команды сопротивляются изменениям. Что вы сделаете сначала?
agileengagement
82
Три директора отменяют ретроспективы шести команд после двух спринтов, утверждая, что 6 часов на команду не дали видимой ценности, а повторяющиеся препятствия выросли с 4 до 11. Как вы ответите?
agile
83
Подразделение из 600 человек обязали внедрить SAFe, обучили 30 агентов изменений, еще не определили потоки ценности разработки и хотят запустить первый ART через 12 недель. Как вы примените LACE и SAFe Implementation Roadmap?
launchesreleasesroadmap
84
В восьми командах три Scrum Master решают большинство препятствий сами, двое работают в основном как трекеры проектов, удовлетворённость фасилитацией находится в диапазоне 38-91%, а 14 программных препятствий просрочены. Что вы сделаете за 60 дней?
agileprogram-management
85
ART из восьми команд использует каждую Innovation and Planning Iteration для завершения интеграции, регрессионного тестирования и 38 перенесенных дефектов, не оставляя времени на обучение или инновации. Как вы восстановите ее назначение?
regressiondefectsiteration
86
Пять команд распределены по семи часовым поясам, но 80% межкомандных решений принимаются на одной встрече в 18:00 по Европе, исключающей 14 из 38 человек. Что вы сделаете?
cross-team
87
На PI Planning шести команд из четырёх стран одна локация занимает 72% общего времени речи, а другие локации поднимают 9 критичных рисков только после голосования уверенности. Что вы измените?
88
Четыре менеджера среднего звена ежедневно напрямую назначают задачи пяти командам, незапланированная работа достигла 33%, а собственные sprint goals команд провалены 4 спринта подряд. Что вы сделаете?
agile
89
После двух провальных реорганизаций за 18 месяцев семь команд отказываются от нового пилота потока ценности, а лишь 19% верят, что руководство выполнит обязательства. Как вы продолжите?
90
Пилот трансформации трёх команд сократил lead time на 28%, но пять команд вне пилота сообщают об 11 нерешённых ограничениях, которых пилот избежал, а спонсор хочет запуск в следующий понедельник. Что вы сделаете?
releasessponsor
91
Сбой длительностью 96 минут затронул семь команд, привёл к потере транзакций на $1,8 млн, а первый черновик разбора обвиняет развёртывание одной команды. Как вы фасилитируете обучение?
transactionsdeployment
92
За 90 дней в шести командах произошло четыре похожих инцидента, а 17 из 24 действий ретроспектив просрочены. Что вы сделаете?
agileincidents
93
Портфель стоимостью $40 млн финансирует три потока ценности через годовые проектные бюджеты, приоритеты меняются каждый квартал, а Finance хочет внедрить Lean Budgets. Как установить guardrails и participatory budgeting, не смещая инвестиционные полномочия?
guardrailsbudgetportfolio
94
Критичная уязвимость нулевого дня затрагивает 24 сервиса восьми команд, эксплуатация подтверждена в отрасли, а Security требует смягчения за 48 часов. Что вы сделаете?
risk-management
95
За 30 дней до аудита выясняется, что пять из девяти команд не могут связать 38 production-изменений с согласованиями, хотя само ПО соответствует требованиям. Что вы сделаете?
96
Директор просит шесть команд исключить заблокированные дни из отчётов lead time, чтобы обещанное улучшение на 20% появилось до заседания совета через 4 дня. Что вы сделаете?
promises
97
Agile-инструмент десяти команд недоступен 48 часов во время PI, а 63 активные зависимости и 120 рабочих элементов недоступны. Что вы сделаете?
agiledependencies
98
Единственный поставщик пропустил три интеграционные вехи на 12 дней, заблокировал четыре команды и оставил вероятность 55% поставить названный scope запуска стоимостью $4 млн к его дате при текущих допущениях. Что вы фасилитируете?
milestonesprocurementplanning
99
Принудительная миграция десяти команд на новый инструмент планирования начинается через 2 недели, но пилот потерял 14% связей зависимостей и удвоил время обновления с 4 до 8 минут. Что вы сделаете?
dependenciesmigrations
100
За 18 дней до релиза восьми команд нужны критичные security-исправления в девяти сервисах, поставщик опаздывает на 7 дней, шесть PI Objectives красные, клиентский срок стоимостью $3 млн под угрозой, а уверенность равна 2,6 из 5. Что вы сделаете в первые 24 часа?
procurementreleasesestimation