В чем состоит цель enterprise фреймворков safe less
Мы запускаем серию ознакомительных статей про SAFe для менеджеров проектов. В них мы расскажем о преимуществах, структуре и ролях Scaled Agile Framework, а также о том, где проектные менеджеры могут найти себе применение в данном подходе. Первая часть посвящена обзору подхода с точки зрения классического проектного управления.
Повестка
В целом мероприятие соответствует стандартной повестке, которая показана ниже. Далее мы рассмотрим каждый блок мероприятия подробнее.
Стандартная повестка 2-дневной сессии PI-планирования
Организация
Важно убедиться, что у программы есть стратегия, которая будет понятна участникам мероприятия, включая заинтересованных лиц и представителей от бизнеса, что работа команд соответствует этой стратегии, что в ART есть люди на всех ключевых ролях.
Ниже примеры вопросов, которые помогают определить эту готовность.
- Объем работы и контекст планирования: «Понятны ли рамки планирования: продукта, системы, технологической области? Знаем ли мы, какие команды нужны для совместного планирования?»
- Согласованность бизнеса: «Согласованы ли приоритеты между представителями от бизнеса?»
- Agile-команды: «Есть ли у нас Agile-команды? Все ли команды укомплектованы разработчиками и тестировщиками? Везде ли определены Скрам-мастер и владелец продукта?»
Что делать менеджерам проектов дальше?
Цифровизация, ускорение запуска инноваций, продолжающийся рост роли Интернета привели к тому, что уровень неопределённости бизнеса в целом и проектов в частности вырос. И предпосылок для замедления этого роста не наблюдается. Технологии, потребности, конкурентное окружение и прочие факторы меняются не только постоянно, но и с высокой скоростью. Со временем всё меньше организаций будут предпочитать классическое проектное управление гибким подходам в качестве инструмента развития своего бизнеса. А в большинстве Agile-методологий нет роли менеджера проекта. Увы, но это так.
Если организация хочет сохранить ценных, опытных и компетентных менеджеров проектов и использовать их потенциал в своём бизнесе, ей придётся приспособить их для исполнения новых функций. А менеджерам проектов, чтобы остаться в игре, придётся освоить новые роли и навыки. Какие, мы расскажем во второй части нашей статьи.
Что такое 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 и более человек
Командный уровень
На уровне команд SAFe придерживается базовых принципов гибкой разработки, описанных в Agile-манифесте и поддерживает итеративно-инкрементальную разработку по фреймворку Scrum или методу Kanban. Команды итеративно разрабатывают элементы продукта двухнедельными итерациями (спринтами) и проводят демонстрации результатов своей работы и ретроспективу.
Единица управления на данном уровне – команда, реализующая пользовательские истории из бэклога. Роли на данном уровне такие же, как и в классическом Scrum: Владелец продукта, Scrum-мастер, член команды разработки.
День 2
Изменение планов
На следующий день мероприятие начинается с того, что руководство описывает все изменения в планируемом объеме работ и ресурсах.
Работа команд — 2
Команды продолжают планирование на основе результатов предыдущего дня, внося необходимые изменения. Они финализирует свои цели на PI, а представители от бизнеса оценивают бизнес-ценность этих целей.
Результаты планирования одной из команд на сессии PI-планирования на 100 человек
Презентация итоговых планов
Все команды кратко презентуют свои планы. В конце выступления каждой команды озвучиваются риски и блокеры, однако обсуждать и искать решения в этот столь короткий промежуток времени командам не разрешается. Если план принимается заказчиками, то команда вывешивает флипчарты со своими целями на PI и рисками на самое видное место, чтобы все могли видеть в реальном режиме времени формирование совокупных целей программы.
Риски программы
Во время планирования команды обнаруживают критические риски и блокеры на уровне всей программы, которые могут повлиять на возможность решения командами своих задач. Эти вопросы рассматриваются всеми участниками. Все риски, один за другим, четко, честно и открыто классифицируются по следующим группам:
- Resolved — команда согласилась, что проблема больше не актуальна;
- Owned — вопрос не может быть решен на мероприятии, но кто-то согласился продвигать разрешение этого вопроса далее;
- Accepted — некоторые риски являются фактами или потенциальными событиями, которые просто должны быть всеми поняты и учтены в дальнейшей работе;
- Mitigated — команда может определить план по устранению последствий данного риска или блокера.
Риски программы на сессии PI-планирования на 100 человек
Голосование
После того, как были рассмотрены риски программы, команды голосуют за реалистичность и готовность взять на себя ответственность за достижения этих целей программы на PI. Все члены команд поднимают руку, показывая от одного до пяти пальцев.
Правила голосования на сессии PI-планирования на 100 человек
Если по всем командам в среднем подняты три или четыре пальца, то руководство может принять такие обязательства. Если же в среднем меньше трех пальцев, то в план вносятся необходимые изменения и все планы перерабатываются. Каждый, кто поднимает два или меньше пальцев, должен высказать свои опасения. Это позволяет или идентифицировать новый риск, требующий перепланирования, или просто донести до всех важную информацию.
Голосование на репетиции с участием Скрам-мастеров и владельцев продуктов команд перед сессией PI-планирования на 100 человек
Переделка планов, если нужно
При необходимости команды перерабатывают свои планы до тех пор, пока уровень доверия им не окажется достаточным. Это первый момент за всю сессию PI-планирования, когда временные ограничения уходят на второй план — важнее согласованность планов и готовность команд взять на себя ответственность за их исполнение.
Ретроспектива
В завершение RTE проводит короткую ретроспективную сессию, чтобы определить, что получилось хорошо, что не очень и что можно сделать лучше на следующей сессии PI-планирования.
После этого можно обсудить дальнейшие шаги, занести цели и пользовательские истории в IT-инструменты управления Agile-проектами, запланировать предстоящие ключевые активности и мероприятия… и даже прибраться в помещении!
Часть 1: Место проектов в SAFe
SAFe – один из наиболее популярных в мире подходов для организации работы гибкой компании. Его преимущество перед другими методами состоит в следующем:
- возможность охватить портфельный, программный уровни, а также уровень крупных комплексных продуктов и решений;
- подробно описанная ролевая структура, включающая менеджерские и технические роли на всех уровнях организации бизнеса;
- подробная база знаний, разноуровневые тренинги, большое профессиональное сообщество;
- высокий уровень структурирования и описания процессов, что упрощает внедрение подхода;
- описанный процесс бюджетирования;
- поддержка процесса разработки компонентными командами.
В минимальном виде SAFe выглядит как уровни Team + Program. Уровни Portfolio и Large Solution опциональны в зависимости от потребностей организации. В этой статье мы не будем рассматривать уровень Large Solution и сконцентрируемся на трёх основных.
Инфраструктура
Подготовить место проведения и техническую инфраструктуру мероприятия с большим количеством участников не так просто, особенно если есть удаленные участники.
Ниже приведены моменты, которые следует учесть.
- Пространство: в помещении должно быть достаточно просторно для всех участников, включая места для перерывов при необходимости.
- Техническая поддержка: заранее определите людей, которые будут помогать вам с настройкой, тестированием и решением проблем с технической инфраструктурой на мероприятии.
- Каналы связи: распределенные сессии планирования требуют наличия основных и резервных каналов трансляции аудио, видео и презентаций.
Плюсы
- Значительно количество весьма неплохих инструментов (WSJF, Kanban, Gemba, etc)
- Формализируются и прописываются шаги для SDLC начиная от написания кода (предписывается TDD) заканчивая выполнения статического сканирования и CI/CD и feature toggle. Хороша каждая из практик или нет — другой вопрос, но по крайней мере есть план и все ему следуют.
- Процесс можно понять, объяснить и внедрить.
- Каждый человек в рамках этого процесса, получает достаточно строго определенную функцию.
- Повышается прозрачность компании для тех, кто в ней работает.
Nexus
В 2015 году Кен Швабер выпускает фреймворк Nexus, который основан на фреймворке Scrum с некоторыми доработками.
Nexus is a framework for developing and sustaining scaled product delivery initiatives.
Во фреймворке Nexus, так как автором является один из основателей Scrum, определение Владельца Продукта перекочевало из Scrum Guide 2020 с некоторыми особенностями фреймворка.
The Product Owner is accountable for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus.
В Nexus несколько Scrum команд (от 3 до 9 команд) работают с одним Бэклогом продукта и управляет им один Владелец Продукта. И как мы видим, в Nexus, Владелец продукта всё тот Product Owner из Scrum.
Обучение в LeSS
Не осталось никаких сомнений, насколько критично обучение в LeSS. Затраты на координацию превращаются в инвестиции в обучение. Традиционно LeSS поддерживает это через обмен опытом, что и в каком случае сработало.
Уровень Портфеля
Цель портфельного уровня – согласование стратегии компании с реализацией портфеля за счёт организации процессов вокруг потоков создания ценности. Этот уровень появляется, если у организации несколько потоков создания ценности.
Портфель в SAFe состоит из Потоков создания ценности. Это могут быть продукты или направления деятельности организации. На этом уровне определяется стратегия инвестирования, бюджеты и показатели эффективности. Также на этом уровне реализуется функция принятия решения самого высокого уровня – портфельное управление (Lean Portfolio Management). И хотя глядя на схему может показаться, что Менеджер портфеля это некая отдельная роль, но это не так. На самом деле это группа функций, исполняемая людьми, которые могут также исполнять другие высокоуровневые роли в организации.
Корпоративный архитектор (Enterprise Architect) принимает решения относительно архитектуры всех систем в компании и их взаимодействия, для их гармоничного взаимодействия внутри организации.
Стратегическое решение
Какой путь выбрать? Решение сильно зависит от того, как лица, принимающие решения, осознают ситуацию в организации.
SAFe предполагает прямое решение через сжигание осознанной проблемы — новый улучшенный программный процесс, объясненный знакомыми терминами. Его проще понять классическому операционному менеджменту. Он расчесывает тот же координационный зуд, что и вся отрасль тяжеловесного проектного и программного управления, но добавляя при этом методы Lean/Agile.
LeSS же предлагает радикальное долгосрочное решение. Простота LeSS делает его многосторонним. Организации самых различных типов могут использовать его в течение долгого времени. Тем не менее, из-за этой многогранности, лицам, принимающим решения, включая топ-менеджмент, требуется больше понимания и смелости, чтобы выбрать этот путь.
Во многих больших компаниях топ-менеджмент на самом деле жаждет радикальных перемен. Например, они создают внутренние стартапы для создания новой культуры, ориентированной на рынок. LeSS — это путь для масштабирования этой эволюции.
Выгода?
В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался 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 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.
Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.
SAFe и проблема Nokia Mobile Phones
Новая модель телефона Nokia ориентировалась на ограниченный срок службы, а также были сжатые сроки ее выпуска. Огромный бэклог (план) включал детализированные старые и новые фичи по многочисленным компонентам. Каждый компонент требовал реализации фич по всем частям системы, как например новый целостный дизайн пользовательского интерфейса.
В качестве решения примерно в июне 2009 года в Nokia Mobile Phones было проведено первое внедрение SAFe-процесса c поездами релизов (release train), совместными планированиями и 4-уровневой иерархией в бэклоге продукта. Это была первая версия знаменитой общей картины SAFe (прим. пер. — SAFe big picture), которую снабдили 170 слайдами, кропотливо проработанными Дином и руководством Nokia. С тех пор SAFe вобрал в себя широкий набор Agile-практик и избавился от устаревшего «душка» Nokia. Однако, ключевая ценность все еще представлена в нем явным образом:
Исполнение Программы
– SAFe
Если посмотреть на рынок, кажется, что это было решением проблемы, осознанной многими организациями.
Ядро SAFe — новый очень детализированный процессный слой поверх Scrum, нацеленный на координацию бардака и обеспечение предсказуемости. Часто новый процесс позволяет отказаться от устаревших глупостей и сделать шаг навстречу Agile-ценностям. Например, запуск всеобщего планирования может придать энергии и улучшить коммуникации. SAFe устраняет проекты и стимулирует контроль незавершенной работы (прим. пер. — Work In Progress).
Авторам трудно вообразить, что старая погрязшая в неприятностях организация смогла бы внедрить SAFe как есть «по книжке». Компетенции людей ограничивают возможности. В большой организации обязательно будут отличия между различными внедрениями SAFe. И со временем порядок вещей в каждой из реализаций процесса SAFe обязательно будет меняться. Это лишь вопрос времени: когда и как долго новый подход все еще будут называть SAFe.
Детализированный процесс похож на истории очень хороших продаж. Все начинается с текущих обстоятельств, а потом обязательно вылезает что-нибудь новенькое
Обучение в SAFe
Во-первых, организации, как культурные и обучающиеся системы, обычно оптимизированы под одно фокусное направление — оптимизационную цель. В SAFe таким фокусным направлением является исполнение программы, и описанный в SAFe процесс определяет, каким образом будет происходить достижение этой оптимизационной цели. Но такой процесс не порождает обучение на уровне организации. И когда появятся успехи по основной оптимизационной цели, существует опасность, что дальнейшие инвестиции в обучение организации будут отложены.
Во-вторых, новые роли, определяемые процессом, требуют новых Lean и Agile- принципов работы. Для лиц принимающих решения — это новое обязательство на увеличение инвестиций в обучение. Сеть консультантов SAFe поддерживает этот шаг тренингами и консультациями. Но актуальные практики, используемые в SAFe, не уникальны, поэтому вопрос лишь в том, насколько хороших консультантов вы привлекаете и сколько инвестируете в обучение.
Далее…
В следующих заметках блога мы более детально исследуем, к примеру, различные варианты масштабирования Scrum, а также сравним организационные слои SAFe и клиенто-ориентированные команды LeSS. Мы опишем: 1) лидерство и власть; 2) организационную структуру и иерархию; 3) поток ценности; 4) обучение, адаптацию и непрерывное улучшение.
Это третья часть цикла из 4-х статей про Менеджера продукта и Владельца продукта, которая поможет вам понять, откуда взялся весь продуктовый менеджмент.
С популярностью Agile-подходов в обиходе менеджмента компаний начали использовать термин Владелец Продукта. Хотя для многих до сих пор остается загадкой, чем эта новая роль отличается от Менеджера Продукта. А еще больше путаницы добавляет тот факт, что и Product Manager и Product Owner стали сокращенно называть «продакт».
В этом цикле статей попробуем найти ответы на следующие вопросы:
- А Product Manager и Product Owner — это разные роли?
- А кто кому подчиняется?
- А у кого больше полномочий и зона ответственности?
В этой статье не рассматриваем особенности фреймворков масштабирования и области их применения, а смотрим только на то, как меняется наполнение определения Владелец продукта.
Содержание
Не менее важно правильно донести концепцию и бизнес-контекст, поэтому на сессии должны присутствовать все необходимые заинтересованные лица. Для этого PI-планирование включает следующие активности:
- Обзор текущего бизнес-контекста от топ-менеджмента.
- Обзор продуктовой концепции, который готовят продуктовые менеджеры на основе топ-10 приоритетных фич из бэклога программы.
- Обзор архитектурной концепции обычно представляет технический директор или архитектор, чтобы рассказать о технологических новинках для поддержки реализации фич, а также о нефункциональных требованиях.
Практика
В этом видео наша практика PI-планирования:
PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
Nokia использовала фреймворки масштабирования Agile: LeSS и SAFe. Какую проблему они решали и как?
Перевод статьи Ари Тикка и Рана Нюмана LeSS SAFe comparison выполнен с разрешения авторов.
Как Large-Scale Scrum (LeSS), так и Scaled Agile Framework (SAFe) имеют публичные истории применения в компании Nokia. Однако, не многие знают, что Nokia представляла собой две большие слабо связанные компании. LeSS использовался и преимущественно используется в Nokia Networks (сейчас называется так же), в то время как SAFe в основном использовался в подразделениях Nokia Mobile Phones (сейчас по большей части принадлежат Microsoft или закрыты).
Обе части Nokia постепенно начали сталкиваться с одной и той же проблемой, которую позже пытались решить масштабированием Agile: узкоспециализированные подразделения и необходимость координации. Крупные организации по всему миру сталкиваются с этой же проблемой. История Nokia позволяет понять и сравнить, что же эти подходы предлагают.
Наш анализ компании Nokia может показаться грубым, но на это есть причина. Мы хотим ясно донести свою точку зрения. Координационный Хаос — это серьезный и опасный шаблон (прим. пер. — перевод видеоролика). Его реальное влияние будет описано ниже.
В больших организациях культура и организационная структура ограничивают то, что дозволено делать людям. Мы сочувствуем тем, кто делает все возможное внутри такой системы.
Программный уровень
Уровень программы является ключевым как со стороны бизнеса, так и с точки зрения координации. На этом уровне все ресурсы, команды, заинтересованные лица кооперируются вокруг одной важной цели, чаще всего представляющую собой поток создания ценности (Value Stream) или продукт. Синхронизируют свою работу команды при помощи совместных сессий планирования (Program Increment Planning) в начале каждого квартала и демонстрации интегрированного инкремента продукта (System Demos) каждые 2 недели и ретроспективы (Inspect & Adapt) в конце каждого квартала.
Соответственно, все роли и процессы ориентированы на поставку ценных элементов функциональности. Метафорой этого процесса является “Поезд” (Agile Release Train).
ART – это долгоживущая группа команд, заинтересованных лиц и других участников, объединённых общей целью, создающая в едином ритме общее решение или его часть. Длина итераций и частота общего планирования внутри поезда фиксирована.
Управляет «Поездом», соответственно, «Машинист» (Release Train Engineer). Он коучит весь «экипаж» поезда для повышения эффективности работы, взаимодействует с заинтересованными сторонами, фасилитирует общие собрания поезда поставки. Он не начальник, он лидер этого поезда. Release Train Engineer больше всего похож на Scrum-мастера, но отвечающего не за одну, а за много команд и их взаимодействие между собой. В терминах PMI «Машинист» соответствует Менеджеру программы по уровню ответственности и исполняемым функциям (The PM role in a lean and agile world).
У поезда также есть главные «пассажиры» – Представители бизнеса (Business Owners). Это основные заинтересованные лица, которые отвечают за финансовые показатели Поезда. Business Owners – это руководители, которые будут получать выгоду от создаваемого решения, пользоваться им или продавать его.
Управляет продуктом и владеет бэклогом поезда команда Продуктового менеджмента (Product Management). В неё входят Владельцы продуктов отдельных команд, а также Продуктовые менеджеры. Они выявляют потребности клиентов, формируют дорожную карту и приоритезируют элементы функциональности. Говоря простыми словами, Представители бизнеса ставят цели, а команда Продуктового менеджмента стараются их достичь силами команд.
Также на программном уровне есть роль Системного архитектора (System Architect). Архитектор определяет архитектуру будущего решения, направляет работу команды с технической стороны системы, взаимодействия подсистем и нефункциональных требований к системе.
Обзор
PI-планирование важно проводить регулярно, ведь оно задает ритм работы всего ART. Это неотъемлемая часть SAFe: если вы не проводите PI-планирование, вы не применяете SAFe.
Сессия PI-планирования на 250 участников
PI-планирование предоставляет бизнесу множество преимуществ:
- Внутри ART налаживается деловое общение, ведь многие из тех, кому нужно делать совместные проекты, впервые знакомятся вживую.
- Обеспечивается высокая эффективность коммуникации между всеми членами команд и заинтересованными лицами. Проще говоря, если собрать много людей вместе и дать им цель, то это приводит к необычайной энергетике общения. Проверено на нашем опыте! (прим. переводчика)
- Бизнес-заказчики и разработчики наконец-то слышат друг друга и начинают действовать слаженно в соответствии с целями бизнеса.
- Команды начинают видеть «картинку в целом», выявляются зависимости, что подталкивает команды к координации между собой и другими ART.
- Команды выбирают только необходимый минимум требований к архитектуре и пользовательскому интерфейсу. Это позволит уложиться в запланированные сроки и «не наворачивать» избыточный функционал.
- Объем работ планируется с учетом емкости команд, за счет чего устраняется избыток незавершенной работы.
- Форсируется принятие решений.
Основными результатами PI-планирования являются:
- Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. Каждая цель оценена с точки зрения значимости для бизнеса. Цели всех команд объединены в набор целей всей программы на PI.
- Доска программы, на которой показаны новые фичи, ожидаемые сроки их реализации и любые другие вехи, с которыми связаны цели команд.
- Общее согласие с реалистичностью и готовность взять на себя ответственность за достижения этих целей.
Подготовка
PI-планирование — важное событие, которое требует подготовки, координации и коммуникации. Участники мероприятия: продуктовые менеджеры, Agile-команды, архитекторы и инженеры, системные команды, заинтересованные лица — все они должны быть заранее оповещены и прийти на мероприятие хорошо подготовленными.
Успешное мероприятие готовится по следующим направлениям:
- Организация: согласованность бизнеса и разработки по стратегии, готовность команд и всего ART.
- Содержание: подготовленность менеджмента и разработчиков.
- Инфраструктура: место проведения и логистика мероприятия.
«Проекты» в SAFe
Как можно заметить из схемы, роли проектного менеджера в SAFe нет, как и отдельного уровня проектов. Все бизнес инициативы связанные с созданием ценности реализуются в рамках «Поездов», уже существующих или созданных под инициативу.
Как же тогда в организациях, практикующих SAFe, реализуются инициативы по автоматизации, внедрению новых систем, затрагивающих всю организацию и многие «Поезда»? Для таких случаев в SAFe существует понятие Эпика (Epic). И он больше всего похож на классический проект.
Если возникает такая необходимость, Владелец эпика (Epic Owner) определяет описание Эпика и его Минимальный Жизнеспособный Продукт (Minimum Viable Product). Затем он взаимодействует напрямую с заинтересованными сторонами и «Машинистами» соответствующих «Поездов» для реализации Эпика.
Главное отличие от классического проекта в том, что разработка Эпика ведётся итеративно-инкрементально, а фокус функций Владельца Эпика смещается с управления командой на координацию взаимодействия с командами разных «Поездов». Реализация Эпика, как и у классического проекта, ограничена во времени. В отличие от потока создания ценности, развитие которого, как правило не останавливается.
Особенность эпика, вероятно повлиявшая на название (от англ. — «эпически, грандиозный»), в его масштабе. Это по-настоящему колоссальная инициатива, «прошивающая» большую часть организации. А потому Владельцем эпика чаще всего выступает кто-то близкий к C-уровню менеджмента в организации. Простому менеджеру проекта Эпик доверят вряд ли.
Скрытая проблема — обучение
При специализации и внешнем контроле инженеров на местах Nokia все меньше нуждалась в обучении большинства из них. Специалисты знали, что нужно делать, а руководители проектов их координировали, что позволило продвинутым рекрутерам легко ориентироваться в таких узких ролях. Эта практика позволила думать, что большее обучение не требуется, и укрепила метафору «организации как машины» в головах руководителей. Подобное мышление руководства оптимизирует ресурсы и издержки, причем локально и краткосрочно. Обучение воспринимается издержками, особенно за рамками своей специализации.
Давайте ограничимся Scrum-командой (команда + владелец продукта + Scrum-мастер). Взаимообучение происходит внутри команды с помощью инспекции и адаптации к рынку. В этом случае обучение создает ценность. Вот, что вам следовало бы масштабировать.
И LeSS, и SAFe базируются на Scrum на уровне команд. Каждый из фреймворков имеет собственный набор бережливых (Lean) и гибких (Agile) практик для поддержки масштабирования. Ключевое отличие в том, как предлагаемые процесс и организационная структура стимулируют обучение, поскольку Организации обучаются подобно лошадям.
LeSS в Nokia Networks
Nokia Networks производит невероятно сложные продукты с длительным сроком службы. Для некоторых продуктов требовалось обеспечить 20-летний срок обслуживания. И по-прежнему разработка в основном координировалась внутри программ с тяжеловесными релизами, часто длящимися годами.
Эволюция LeSS не может быть приписана единственной корпорации. LeSS в Nokia Networks начался примерно в 2005 году. Сейчас (прим. пер. — в 2015 году), через приблизительно десять лет, в Nokia Networks продолжают функционировать подразделения калибра LeSS Huge.
Так какую же проблему осознали в Nokia Networks? Недостаток продуктивности и гибкости в разработке продуктов. Более тщательный анализ выявил смертельный штопор, в который свалилась компания: фрагментация организации, загроможденный поток работ, растерянные руководители и ограниченное обучение. Это ключевые причины Координационного Хаоса (прим. пер. — перевод видеоролика). LeSS разрывает этот замкнутый круг. Авторы формулируют ценностное предложение LeSS так:
Большее через меньшее.
– LeSS
LeSS — фреймворк масштабирования командной работы по Scrum вверх и наружу, без добавления слоев или процессов. Напротив, он радикально упрощает организацию — большее через меньшее. Команда берет на себя заботу о технической координации. Команда владельца продукта работает с рынком и командами. Менеджеры становятся коучами. Никаких вспомогательных слоев не добавляется.
Фича-команда — ключевая концепция в LeSS. Специализация необходима. Она создает ясность и эффективность. Однако, важно, в каком направлении вы развиваете специализацию. LeSS явным образом рекомендует специализироваться в “клиентоцентричности” и продукте, а не компонентах.
Если организация новая и развивающаяся, то LeSS может быть идеальным вариантом, чтобы избежать смертельного штопора.
Никакой магии. Трансформация большой старой организации не происходит в одночасье. У этого процесса много стадий и препятствий. Требуется время, чтобы устранить накопленные организационные и технические проблемы. Внедрение LeSS опирается на инспекцию и адаптацию. Вы начинаете в одном месте, убеждаетесь, что все работает, только затем расширяете область перемен. Долго длящиеся примеры внедрений — наилучший путь для изучения типа ценности, создаваемой в них.
День 1
Бизнес-контекст
Топ-менеджер или владелец бизнеса описывает текущее состояние бизнеса и то, насколько хорошо текущие решения в перспективе будут удовлетворять потребности клиентов.
Концепция продукта
Продуктовые менеджеры презентуют текущую концепцию программы, обычно рассказывая про важнейшие 10 предстоящих к реализации фич, про изменения с предыдущего PI-планирования, а также про любые грядущие вехи.
Архитектура и практики разработки
Системный архитектор представляет архитектурную концепцию. Кроме того, старший менеджер разработки может рассказать про изменения в практиках Agile-разработки, к примеру, автоматизации тестирования и непрерывной интеграции, которые нужно учитывать в течение следующего PI.
Контекст планирования
Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.
Ведущий объясняет цели и план сессии PI-планирования на 100 человек
Работа команд — 1
Команды для каждой итерации оценивают объем работ, которые они смогут выполнить (емкость) и определяют элементы бэклога, которые, скорее всего, необходимы для реализации фич. Каждая команда создает черновики планов, которые видны всем остальным участникам, итерацию за итерацией. В это время они выявляют риски и зависимости, определяют черновик целей команды на PI. Также команда добавляет фичи на доску программы.
Команды выявляют взаимозависимости на сессии PI-планирования на 100 человек
Рецензирование черновиков планов
Рецензирование планов происходит со строгими ограничениями по времени выступления каждой команды. В это время команды представляют основные результаты планирования: черновик целей, потенциальные риски и зависимости. Представители от бизнеса, продуктовые менеджеры, остальные команды и заинтересованные лица задают вопросы и дают обратную связь.
Владелец продукта презентует собранный ее командой план на сессии PI-планирования на 100 человек
Рецензирование руководством и решение проблем
Вероятно, планы необходимо будет доработать с учетом ожидаемого объема работ, ограниченности ресурсов и выявленных зависимостей. Во время этой встречи руководство согласовывает объем работ и устраняет недочеты в планах. RTE ведет встречу с участием всех ключевых заинтересованных лиц до тех пор, пока ими не будут определены достижимые цели.
Scaled Agile Framework®
В 2011 году Дин Лёфингвэлл представил первую версию SAFe 1.0.
SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.
В SAFe дела с Владельцем продукта обстоят куда интересней, но замечу, что SAFe не говорит о том, что это фреймворк масштабирования Scrum. И всё же, в SAFe используется термин Product Owner, поэтому давайте разбираться с самым популярным фреймворком масштабирования Agile-практик.
Во-первых, на уровне команд в SAFe находится не Scrum, а ScrumXP (созданный SAFe-сообществом скрамоподобный процесс). В нем — отличное от оригинала понимание роли Владельца Продукта. Во-вторых, в SAFe имеются еще две роли, которые участвуют в управлении ценностью продукта, — Product Manager и Business Owner. Давайте рассмотрим все пазлы по отдельности для полной картины.
Начнем с определения ScrumXP:
ScrumXP is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe. It combines the power of Scrum project management practices with Extreme Programming (XP) practices.
Как видно из определения, это точно не хорошо нам знакомый Scrum, это процесс в котором работают кросс-функциональные и самоорганизующиеся команды, которые используют практики экстремального программирования и Scrum.
Теперь давайте посмотрим на определение Владельца Продукта (PO — Product Owner):
The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team. The PO has a significant role in maximizing the value produced by the team and ensuring Stories meet the user’s needs and comply with the Definition of Done. This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders.
Важно отметить, что в SAFe Владелец Продукта управляет Бэклогом Команды, а не Бэклогом Продукта. Product Owner в SAFe несет ответственность за определение и создание Историй (краткое описание небольшой части желаемой функциональности, написанное на языке пользователя) и приоритезацией Бэклога Команды. Также Владелец Продукта в SAFe взаимодействует с Менеджментом по продукту, Клиентами, Представителями бизнеса (Business Owners) и другими заинтересованными лицами.
Возможно, мы сможем разглядеть облик Владельца Продукта в других ролях SAFe? Следующим по иерархии идет Менеджера по продукту (PM — Product Manager).
Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle. To do this, they collaborate with a wide range of people to identify and define customer needs, understand the Solution Context, and develop the Program Vision, Roadmap, and Features required to meet these needs. The role scales in relation to the complexity of a solution: some solutions may only need a single Product Manager while others will need a team.
В SAFe ответственность за управление ценностью продукта на всём жизненном цикле возлагается на Менеджера по продукту. Вот тут мы уже можем разглядеть облик Владельца Продукта из Scrum. Также, мы видим, что большая часть зоны ответственности Владельца Продукта из Скрама, осела в роль Менеджера по продукту: исследования клиентов, создания VISION, построение Roadmap и т.д. И тут, давайте честно признаем, что этим должен заниматься Владелец Продукта в Scrum, но об этом не написано в Scrum Guide.
Давайте посмотрим, есть ли что-то от Владельца Продукта у Представитлей бизнеса (BO — Business Owners).
Business Owners Business Owners are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART).
Вот и нашлись недостающие пазлы Владельца Продукта из Скрам, но эти пазлы являются составляющими Владельца Продукта с практической стороны. С точки зрения руководства по Scrum и Nexus, эти составляющие называются одной фразой — максимизация ценности продукта. В LeSS например, есть более детальное, по сравнению со Scrum Guide, описание взаимодействия Владельца Продукта с клиентами, стейкхолдерами, командой и Скрам-мастером, где можете найти практические составляющие роли Владельца Продукта.
Итого, если пытаться найти Владельца Продукта из Scrum в SAFe, то ищите его отражения в трех ролях.
Когда собирал материалы для статьи, то заметил, что в англоязычных статьях на тему сравнения “Product Owner vs Product Manager”, авторы часто ссылаются на определения взятые из SAFe®. И мне кажется, это одна из причин, почему многие считают Владельца Продукта человеком, плотно работающим с командой разработки для обслуживания интересов Менеджеров по продукту и Представителей бизнеса.
На этом мы заканчиваем рассматривать многогранного Владельца продукта. Надеюсь, вам удалось собрать более полную картинку роли Product Owner. В следующей статье будем собирать и сравнивать компетенции и полномочия Product Manager и Product Owner.
Подключайтесь к Telegram-каналу, где делюсь практиками и опытом.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
LeSS (Large-Scale Scrum)
В 2005 году Крэг Ларман и Бас Водди объединились для совместной работы по масштабированию Скрама у крупных клиентов, так появился фреймворк LeSS.
LeSS is Scrum applied to many teams working together on one product.
Роль владельца продукта в LeSS концептуально совпадает с ролью в Scrum по версии руководства по Скрам 2017. В LeSS один Владелец Продукта может охватывать до восьми Scrum команд, которые работают над одним Бэклогом продукта. Владелец Продукта поощряет и помогает командам напрямую работать с реальными пользователями и клиентами для актуализации элементов Бэклога. При этом Владелец Продукта действует как связующее звено, а не как посредник. Фокус внимания Владельца Продукта в LeSS смещается в сторону видения продукта и обеспечения максимальной отдачи от инвестиций в Продукт (ROI — Return on Investment, возврат инвестиций).
The Product Owner focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.
В LeSS делается акцент на прямом взаимодействии команд разработки и клиентами по трем причинам:
- Это предотвращает искажение и потерю информации, которая возникает при наличии передаточных звеньев.
- Это способствует коллаборации разработчиков и клиентов при создании решений, что позволяет лучше решать проблемы пользователей.
- Это повышает мотивацию и эмпатию разработчиков к пользователям.
В том случае, если ваш масштаб более 8 команд в продукте, то в игру вступает LeSS-Huge. В этой ситуации у Владельца Продукта появляется несколько помощников — Area Product Owner (APO — Владелец Области Продукта. Каждый из APO вместе с минимум тремя командами отвечает за развитие определенной клиент-ориентированной области продукта. В общем и целом, Владелец Продукта в LeSS — это хорошо уже нам знакомый Product Owner из Scrum.
Недостатки
- Достаточно длительное время реагирование на несоответствие реальности ожиданиям
- Огромное количество средств и денег тратится на коммуникацию и собрания
- Часто рекомендуемые решения в рамках фреймворка уже устарели
Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.
Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «PI Planning — Scaled Agile Framework».
Сессия PI-планирования на 190 участников
Задачи по разработке продукта невозможно заранее предугадать. Передайте планирование и отслеживание тем, кто может оценить конечный результат и влиять на то, каким он будет.
— Michael Kennedy, «Product Development for the Lean Enterprise»
Один из принципов 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-планирование позволяет получить три основных артефакта.
- Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. По каждой цели представителями от бизнеса определена оценка ее бизнес-ценности.
- Доска программы, на которой видны сроки поставки новых фич, зависимости между командами и зависимости от других ART, а также важные вехи.
Доска программы одного ART
Какую проблему решает «масштабирование Agile»?
В течение долгого времени Nokia росла на 35% каждый год, чем очень сложно управлять. Естественным решением была специализация: компонентные и функциональные команды, специалисты знают, что нужно делать, но решения принимают менеджеры, а команды их исполняют. Так было и в Nokia Networks, и в Nokia Mobile Phones. Обе компании отчаянно возлагали надежды на то, что со всем этим справится программное и проектное управление.
Но со временем становилось только тяжелее. Чем больше организационная структура ориентирована на узкую специализацию, тем больше требуется внешней координации. Этот шаблон Координационного Хаоса (прим. пер. — перевод видеоролика) стал одной из основных причин знаменитой «Горящей Платформы» Nokia Mobile Phones (прим. пер. — «Горящая платформа по имени Nokia» или письмо CEO Nokia).
Читайте также: