agile safe что это

Принципы SAFe — простые в использовании карточки

Принципы SAFe: принципы Agile-манифеста и Lean-подход для крупных организаций

Перевод статьи Ian Spence SAFe Principles: Easy To Use Cards выполнен с разрешения автора. Оригинальные фотографии заменены на сделанные во время SAFe Agilists Russia Meetup.

Принципы SAFe® являются очень мощными, однако, понять их и прочувствовать поначалу бывает достаточно сложно.

Чтобы облегчить эту задачу, мы сделали набор карточек, комплексно описывающих 9 принципов SAFe®. Карточки призваны помочь топ-менеджерам, руководителям и членам команд понять эти принципы и оценить их актуальность. Это важно на любом этапе внедрения SAFe®. Карточки можно также использовать для проверки состояния команд, которые уже проводят или только планируют внедрение SAFe.

Что такое принципы SAFe?

SAFe полностью поддерживает 12 принципов Agile-манифеста и в дополнение к нему декларирует собственный подход к Lean и 9 Lean-Agile принципов:

Несмотря на их исключительную ценность, мы всегда считали эти принципы слишком заумными и непригодными к использованию. В отличие от Agile-манифеста с его 12 поддерживающими принципами, доступно объяснить кому-либо принципы SAFe без серьезных тренингов и обсуждений практически невозможно. Не помогают даже исчерпывающие описания на сайте Scaled Agile Framework, поскольку мало кто готов прочесть 10 перегруженных информацией статей с единственной целью — понять принципы, лежащие в их основе.

Вот если бы собрать все в один простой PDF, которым можно легко поделиться, в формате, который: 1) понятен каждому и 2) позволяет легко их доставать, разбирать и обсуждать.

Такие цели мы ставили, когда делали наш набор карточек с принципами SAFe.

Как выглядят Карточки?

Это простые двусторонние игральные карты.

На лицевой стороне коротко описан сам принцип, в формате, который:

Так выглядят карточки для первого и последнего из 9 принципов:

Мы считаем, что они не требуют дополнительного описания, и читателю будет легко согласиться или не согласиться с каждым принципом.

Взгляните на карточки еще раз. Достаточно ли вам этой информации, чтобы принять решение подписаться под ней?

Если вам нужно немного больше, можете перевернуть карточку и увидеть дополнительное описание: «что такое хорошо и что такое плохо». Вот оборотные стороны 2 карт, представленных выше:

Информация на обороте карточки добавляет практики и иллюстрирует важность принципа.
Она включает описание, что значит «хорошо» (напротив довольного человечка) и что — «плохо» (напротив грустного). Они намеренно выглядят мультяшно, чтобы произвести эффект. Ведь никто же на самом деле не ведет себя, как грустнолицый человечек, не так ли?

Как играть с картами

Есть множество способов работать с картами.

Приоритизация и соглашение

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

Дайте группам задание выстроить карты по степени важности и выделить те, с которыми кто-то (или все) не согласны.

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

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

Это упражнение требует 10 минут времени, но вовлекает участников в обсуждение и углубляет понимание принципов, что критически важно перед любым обсуждением механизмов SAFe.

Проверка состояния и анализ расхождений

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

Для этого вам нужно нарисовать простую табличку удовлетворенности с 4 колонками. Или с 5 если вы хотите также добавить ранжирование из предыдущего упражнения.

Колонки будут следующие:

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

В данном случае все группы состояли из опытных RTE (Release Train Engineers), и результаты однозначно показали, что для полноценного внедрения мышления Lean и Agile, к которому они стремятся для своей организации, им есть над чем поработать.

Примечание: возможно, вы захотите добавить ранжирование из первого упражнения.

Другие опции включают:

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

Как получить карты

Все это, конечно, здорово и круто, но без колоды карт совершенно бесполезно.

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

Источник

Фреймворки масштабирования Agile на компанию

Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».

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

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

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

И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.

Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.

Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.

Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.

Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.

Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.

Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).

Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.

При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.

Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.

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

Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.

Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.

Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.

На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…

Источник

SAFe или Scaled Agile Framework

Что такое SAFe?

Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.

Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?

Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.

SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек

Выгода?

В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead

Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.

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

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

В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.

SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).

На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.

Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)

Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.

Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.

Плюсы

Недостатки

Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.

Источник

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

Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «PI Planning — Scaled Agile Framework».

Сессия PI-планирования на 190 участников

Задачи по разработке продукта невозможно заранее предугадать. Передайте планирование и отслеживание тем, кто может оценить конечный результат и влиять на то, каким он будет.
— Michael Kennedy, «Product Development for the Lean Enterprise»

В SAFe нет никакого волшебства… разве что только PI-планирование.
— Авторы SAFe

Один из принципов Agile-манифеста говорит, что «непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Это несложно осуществить, если у вас одна небольшая команда. А как быть в масштабах огромной компании, когда команд много и необходима их синхронная работа? Для этого в Scaled Agile Framework (SAFe) используется инструмент PI-планирование (PI Planning) — это практика прямого общения всех команд, представителей бизнеса и других заинтересованных лиц, которые как бы объединяются в одну большую команду — Agile Release Train (ART).

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

Для подобных мероприятий по планированию, исследованиям и обучению предусмотрена специальная IP-итерация (Innovation and Planning iteration), чтобы не занимать время команд на других итерациях внутри PI. Сессия длится от 1,5 до 2 дней. Результатом является согласованный набор целей программы на следующий PI.

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

Обзор

PI-планирование важно проводить регулярно, ведь оно задает ритм работы всего ART. Это неотъемлемая часть SAFe: если вы не проводите PI-планирование, вы не применяете SAFe.

Сессия PI-планирования на 250 участников

PI-планирование предоставляет бизнесу множество преимуществ:

Основными результатами PI-планирования являются:

Подготовка

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

Успешное мероприятие готовится по следующим направлениям:

Организация

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

Ниже примеры вопросов, которые помогают определить эту готовность.

Содержание

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

Инфраструктура

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

Ниже приведены моменты, которые следует учесть.

Повестка

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

Стандартная повестка 2-дневной сессии PI-планирования

День 1

Бизнес-контекст

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

Концепция продукта

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

Архитектура и практики разработки

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

Контекст планирования

Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.

Ведущий объясняет цели и план сессии PI-планирования на 100 человек

Работа команд — 1

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

Команды выявляют взаимозависимости на сессии PI-планирования на 100 человек

Рецензирование черновиков планов

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

Владелец продукта презентует собранный ее командой план на сессии PI-планирования на 100 человек

Рецензирование руководством и решение проблем

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

День 2

Изменение планов

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

Работа команд — 2

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

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

Презентация итоговых планов

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

Риски программы

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

Риски программы на сессии PI-планирования на 100 человек

Голосование

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

Правила голосования на сессии PI-планирования на 100 человек

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

Голосование на репетиции с участием Скрам-мастеров и владельцев продуктов команд перед сессией PI-планирования на 100 человек

Переделка планов, если нужно

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

Ретроспектива

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

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

Результаты

Успешное PI-планирование позволяет получить три основных артефакта.

Доска программы одного ART

Практика

В этом видео наша практика PI-планирования:

Источник