SAFe Innovation & Planning vs. Sprint Planning

Sep 22 2020

В моей компании мы переходим на SAFe, и мне трудно понять различия. Я сертифицирован по Scrum (CSM / CSPO), но мало знаю о SAFe, и я не вижу большой разницы между частью планирования в SAFe Innovation & Planning и Scrum Sprint Planning. Какая разница? Пытался поискать в Google, но похоже, что они такие же, однако в нашей команде мы проводим как I&P с оценкой пользовательских историй, так и еще много чего, но также планируем спринт, где мы также (повторно) оцениваем US. У меня такое чувство, что мы делаем что-то не так.

Ответы

4 ThomasOwens Sep 22 2020 at 19:51

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

Итерация инноваций и планирования SAFe не имеет соответствующего события в Scrum. Итерация инноваций и планирования выполняется один раз для каждого этапа программы. В Scrum каждый спринт (итерация) предназначен для создания потенциально готового к выпуску продукта. Тем не менее, итерация инноваций и планирования является буферным периодом для улучшения инструментов и инфраструктуры, непрерывного обучения и перекрестного обучения или повышения квалификации, формальной проверки и валидации, тестирования приемлемости пользователей, других действий, связанных с выпуском, и планирования приращения программы. У него другой тип работы, чем у других итераций.

2 TiagoCardoso Oct 02 2020 at 05:19

Перед тем, как перейти к масштабируемой гибкой структуре (SAFe, LeSS или любой другой), все участники процесса должны на 110% понять, почему это происходит.

Ключ к масштабированию процесса - это, как уже говорили другие, выполнение того же процесса, что и обычная команда, но на этот раз на другом уровне. Я работал с программами с более чем 300 инженерами, поэтому в данном случае масштабируемый фреймворк просто необходим. Как команда из 7 инженеров будет планировать, уточнять и согласовывать с заказчиком, что может быть доставлено в течение следующих 2 недель, «то же самое» происходит, когда у вас есть 700 инженеров ... но «то же самое» в данном случае .. ну не совсем то же самое.

Вернемся к исходному вопросу: «Я не вижу большой разницы между частью планирования в SAFe Innovation & Planning и планированием Scrum Sprint».

Существует ряд артефактов, возникающих в результате планирования PI, которые не характерны для планирования Scrum Sprint. Ваш опыт может отличаться, но я заметил несколько ключевых аспектов, которые являются основополагающими для правильного планирования PI:

Активное участие заинтересованных сторон бизнеса

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

Визуализация межкомандных зависимостей

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

Очень важно проводить такие сеансы со всеми в одних и тех же физических местах, хотя в случаях Covid19 это не так. Так выглядит обычная доска физических зависимостей (эта доска всегда доступна для всех, и команды выбирают элементы из бэклога и назначают их соответствующим образом, выделяя зависимости и риски):

Вотум доверия

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


Вот как выглядит план PI-планирования:


Более подробную информацию о PI Planning в SAFe можно найти в https://www.scaledagileframework.com/pi-planning/

1 Mashimo Oct 01 2020 at 14:20

Инновации и планирование в SAFe - это, по сути, деятельность, состоящая из двух частей: первая - это классическое упражнение по проверке и адаптации, очень похожее на ретроспективу Scrum. Вторая часть - это упражнение по планированию, когда следующее приращение программы (PI) подтверждается всеми командами .

Разница с планированием спринта заключается в том, что в Scrum оно относится к одной отдельной команде и одной единственной итерации. SAFe вместо этого рассматривает, как масштабировать Agile с несколькими командами .

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

Прорыв этой команды может быть классическим планированием Scrum Sprint (SAFe не зависит от методологии команды), но умноженным для всех итераций . Нет необходимости иметь отдельное планирование спринта после планирования PI.

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

Речь идет о многих командах. Если проект разделен между менее чем пятью командами, нет смысла использовать SAFe. Координация может быть достигнута с помощью, например, Scrum of Scrums.