Как масштабировать Agile?

В любой организации, предлагающей рынку какой-либо продукт, обычно ведется три вида деятельности: новация (разработка концепции) продукта, собственно разработка (изготовление), доставка до конечного потребителя или сопровождение продукта. Как правило, эти работы выполняются отдельными командами сотрудников. При построении эффективной разработки программного обеспечения многие команды сегодня активно придерживаются философии Agile, но компаниям одной команды разработчиков обычно недостаточно, кроме того нужно не только разрабатывать ПО, но и выполнять другие работы в рамках перечисленных видов деятельности. Поэтому неизбежно требуется проводить масштабирование Agile-команд до корпоративного уровня. Но тут возникают три препятствия: бюджетирование, архитектура продукта и организационная структура. Известно несколько подходов к такому масштабированию : Nexus, RAGE, DAD, LeSS, APM, SoS и SAFe (см. врезку). Как обойти каждое из названных препятствий на этом пути, разберем на примере SAFe [1–3] — наиболее популярного сегодня фреймворка.

Бюджетирование

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

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

В классической организации обычно имеются подразделение, принимающее решения, и исполнительный аппарат, а в гибкой для принятия решений предлагается использовать несколько доступных всем сущностей: «стратегические темы», «мечта» (или «видение») и «ключевые даты». Стратегические темы — это способы ведения бизнеса, технологии или решения, на которых компания концентрируется в данный момент времени. Мечта — картинка «идеального» для выпускаемого продукта мира, в который компания вовлекает своего клиента. Ключевые даты — события на рынке, внутри компании либо
договоренности с партнерами, к моменту наступления которых нужно создать максимальную (насколько это возможно) дополнительную бизнес-ценность.Вся эта информация доступна на всех уровнях гибкой организации: на уровне портфеля, где принимаются решения о ценности тех или иных крупных инициатив; на уровне программы, где принимаются решения о том, какая функциональность систем или продуктов создается в первую очередь; на уровне команд, где принимаются решения о том, какой конкретный функционал следует разработать в соответствии с наиболее важными потребностями бизнеса. Важно, что на каждом из уровней решения принимаются независимо и один уровень не может диктовать приоритеты другому. В терминах Scrum [4, 5] на каждом уровне существует свой список задач (backlog), который обрабатывается своим владельцем продукта (product owner, PO) и своей командой разработки.

Для гарантированного  получения  результата при гибкой разработке обязательно используются циклы обратной связи, а сама разработка ведется инкрементально, итерациями. Поскольку одновременно работает много команд, уже недостаточно ставить задачи на одну итерацию (спринт) — нужно планировать три-четыре спринта вперед, для того чтобы эффективно синхронизировать работу команд и оптимально использовать время на коммуникации. При разработке крайне важно использовать непрерывную сборку (continuous integration, CI) и непрерывную доставку (continuous delivery, CD), поскольку горизонт планирования может в точности не совпадать с датами, когда нужно доставлять новую функциональность клиентам. Применение CI/CD обеспечивает возможность асинхронного выпуска продуктов по отношению к циклам планирования. Здесь нужно заметить, что под планированием понимается ориентировочный список целей, сформулированных в бизнес-терминах, который функционирует поверх списков задач на спринты (sprint backlog), если команда использует методологию Scrum.

Команды каждого уровня сами решают, стоит ли проверять те или иные бизнес-гипотезы и реализовывать тот или иной функционал в продукте. Это особенно важно на уровне крупных инициатив, поскольку влияет на множество людей внутри и вне организации. Крупные инициативы в Agile-разработке принято называть «эпиками» (от англ. epic — «эпический», «эпохальный», «грандиозный»). Все эпики проходят процедуру рассмотрения — оценку целесообразности и жизнеспособности идеи. По сути, проект в классической организации соответствует эпику в гибкой, однако есть существенное отличие: если проект утвержден, ответственный за него уже не может допустить невыполнение данного проекта полностью, от начала до конца. С эпиком дела обстоят иначе: каждый эпик является некой бизнес-гипотезой, которая сулит компании дополнительную ценность, но при этом все хорошо понимают, что на этапе начала работы над эпиком нельзя точно сказать, как именно будет выглядеть разрабатываемый функционал. Если ценность бизнес-гипотезы достаточно высока, то разработка начинается и при этом не обязательно сдать 100% функционала, который был предположен на этапе одобрения. Вполне нормальна ситуация, когда принимается решение об остановке работ по эпику в середине пути, поскольку либо уже был достигнут необходимый уровень возврата инвестиций, либо на практике получено подтверждение несостоятельности гипотезы.

Архитектура

Ключевое отличие гибкой разработки крупных систем заключается в том, что разговор идет не об архитектуре продукта или решения, а об архитектурных намерениях, формулируемых членами команд разработчиков. При классическом подходе эти решения принимаются исключительно выделенным архитектором или командой архитекторов. В манифесте гибкой разработки программного обеспечения Agile Manifesto (agilemanifesto.org/iso/ru/manifesto.html) четко сказано, что лучшие архитектурные решения создаются членами самоорганизующихся команд. Этот принцип обязательно должен использоваться и при масштабировании Agile-разработки. Архитектор выполняет функции «задающего начальное направление» и обеспечивает синхронизацию идей, которые разрабатывают команды (рис. 1). Таким образом, с одной стороны, его оценка не доминирует, а с другой, он играет роль фасилитатора (то есть коммуникатора), обеспечивающего эффективное взаимодействие команд в части архитектуры. Еще одна задача архитектора — обеспечивать соблюдение командами архитектурных намерений или договоренностей, которые они уже определили.

Рис. 1. Основные принципы построения архитектуры при использовании SAFe

Архитектурные намерения планируются так называемыми горизонтами: текущие намерения, среднесрочная перспектива и будущие. При этом чем больше разрабатываемое решение, тем крупнее будут горизонты. Здесь стоит ввести еще один термин, поскольку, кроме функционала, разрабатываемого для конечного пользователя, обычно имеется еще множество технических архитектурных задач, необходимых для работы этого функционала, — так называемые «энейблеры» (enablers — движущие, или разрешающие, задачи). При планировании архитектурных горизонтов энейблеры примерно расставляются внутри списков задач в соответствии с тем, как будет реализовываться функционал для конечного пользователя. А дальше, в процессе работы, можно отслеживать, какое количество энейблеров было использовано для реализации того или иного функционала. Такой механизм позволяет избежать ненужных инвестиций в технологическую платформу. Все это носит название «управление архитектурным руслом» (managing the architectural runway).

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

Монополия на инновации в традиционных организациях, при которой возможность создавать инновации закреплена за конкретным человеком или группой людей, играет против компании. В гибкой организации обеспечиваются условия, при которых каждый член команды может предложить новые подходы, новые решения либо изменения существующих процессов. Для этого в графике работы команд закладывается время на создание инноваций. Например, после того как команда отработает три или четыре итерации над продуктом, она получает целую итерацию на то, чтобы стабилизировать разработанный функционал и поработать над инновациями. С точки зрения управления процессом разработки последняя итерация также используется для проведения планирования, когда проходит «конференция разработчиков», направленная на планирование инкремента продукта (PI Planning) или системы.

Работу над архитектурой нельзя рассматривать как единовременную задачу — архитектурная разработка должна представлять собой постоянный поток работ, для управления которым в Agile обычно используется  методология  Канбан [5].

Организационная структура

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

В гибкой организации на каждом уровне решения принимаются максимально независимо, такие уровни можно назвать «уровнями каскадирования», поскольку они не являются, строго говоря, вертикальной иерархией. Самый глобальный уровень принятия решений называется «Портфель», за ним следуют уровни «Программ» и «Команд». Требования, которыми управляют на каждом из этих уровней, соответственно называются «Эпики» (подразумевающие под собой крупные инициативы), «Фичи» (иногда «Темы», под которыми часто понимается принятие решений на уровне отдельных систем или продуктов) и «Пользовательские истории» (или «Истории», где рассматриваются конкретный функционал или свойства продуктов).

Представители каких ролей нужны на каждом из этих уровней? В Scrum требуется наличие трех ролей: Scrum-мастер, владелец продукта и разработчик. Когда несколько команд объединяются в «Программу» (при разработке, например, одной бизнес-системы), то на этом уровне «команды команд» должны присутствовать владелец продукта и Scrum-мастер, но появляется также архитектор — коммуникатор, помогающий командам совместно работать в части архитектуры (рис. 2). Нельзя забывать об общих сервисах, которые всегда присутствуют в крупной организации и которые, к сожалению, нереально включить в состав кросс-функциональных команд разработки. Это, например, дизайнеры, специалисты, обеспечивающие сборку системы и ее интеграцию, а также специфическое тестирование. В зависимости от типа разрабатываемого продукта эти сервисы могут отличаться. Самый глобальный уровень «Портфель», аналогично «Программе», должен включать в себя людей, управляющих продуктом, и тех, кто помогает обеспечивать эффективное производство и согласование архитектуры.

Рис. 2. Принцип масштабирования с использованием ролей Scrum

Теперь попробуем собрать эту структуру воедино (рис. 3). На уровне эпиков существует команда управляющих портфелем — обычно это представители бизнеса и эксперты, работающие на других уровнях и отвечающие за продукт уровня всей компании. Именно они принимают решение о том, стоит ли запускать в работу тот или иной эпик. Здесь нужно напомнить, что существует уровень «Фич», на котором также присутствуют люди, участвующие в оценке ценности тех или иных инициатив. Таким образом, управляющие портфелем и владельцы бизнеса обеспечивают изначальное решение о ценности инициатив. Дальше существует архитектурный каскад, когда на уровне всей компании команда архитекторов обсуждает вместе с управляющими портфелем предварительные архитектурные решения, но дальше их задача заключается в фасилитации архитектурных решений, исходящих от команд разработки. Следующий каскад — продуктовый. На уровне эпиков он замыкается на владельцев эпиков, которые помогают как с точки зрения требований к самому продукту, так и с точки зрения организации эффективной работы команд. Дальше имеются управляющие продуктами на уровне систем и владельцы продуктов на уровне команд, а  также  мастера производства на уровне систем (в SAFe — это RTE, Release Train Engineers) и Scrum-мастера команд.

Рис. 3. Упрощенное представление каскадирования ролей в SAFe

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

Управление

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

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

Кроме принципов, можно отметить важные управленческие практики. Решения о бюджетировании принимаются не на основе результатов защиты проектов, а на основе «стратегических направлений развития» организации, с учетом «мечты» и «ключевых дат», причем в режиме реального времени и через управление «потоками создания ценности». Должен быть предусмотрен процесс одобрения инициатив, при котором каждая инициатива (эпик) рассматривается как гипотеза, которую надо проверить на практике и которая будет выполнена в объеме, определяемом в процессе ее реализации. Управление работой команд осуществляется по Scrum и Канбан, оценка объемов производится в условных единицах (storypoints), а управление задачами осуществляется через бэклоги, обрабатываемые самоорганизующимися командами. Представители бизнеса не имеют права редактировать сформулированные цели, но могут  судить  о бизнес-ценности каждой из них, влияя на приоритеты задач команд, что по завершении инкремента программы (три-четыре спринта) позволяет оценить размер созданной бизнес-ценности.

***

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

Литература

1. 11th annual State-of-Agile report, 17 p. VersionOne. URL: https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile-report-2 (дата обращения: 05.12.2017).
2. Андрей Косыгин. Agile и DevOps на службе крупного бизнеса // Открытые системы.СУБД. — 2016. — № 2. — С. 28–29. URL: www.osp.ru/os/2016/02/13049287 (дата обращения: 05.12.2017).
3. Scaled Agile Framework. URL: http://www.scaledagileframework.com (дата обращения: 05.12.2017).
4. Майк Кон. Scrum: гибкая разработка ПО/ Пер. с англ. — М.: ООО «И.Д. Вильямс», 2011. — 576 с.: ил.
5. Майкл Кузумано, Мэри Поппендик. Бережливая разработка программ // Открытые системы.СУБД. — 2012. — № 8. — С. 32–37. URL: https://www.osp.ru/os/2012/08/13019237/ (дата обращения: 05.12.2017).

Алексей Ионов (alexey@ionovpartners.com) — управляющий партнер, компания «Ионов и Партнеры», Дмитрий Волков (vlk@keldysh.ru) — сотрудник ИПМ им. М.В. Келдыша РАН, (Москва).