Напомним, что Scaled Agile Framework содержит несколько уровней иерархии от управления командной до управления портфелем предприятия. И одним из уровней является управление цепочками добавленной стоимости. Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные или критически важные системы. Однако некоторые его элементы будут вполне полезны и не очень крупным предприятиям.
Для того чтобы оставаться конкурентоспособным, современному предприятию проходится проводить серьезные преобразования, одно из ключевых направлений которых — цифровизация, или цифровая трансформация. Это емкое понятие подразумевает не просто автоматизацию или внедрение инноваций на основе ИТ, а нечто большее: серьезное изменение как бизнес-процессов, так и бизнес-моделей — основ деятельности предприятия, зарабатывания им денег и создания ценности для клиентов. Зачастую кардинально меняются предлагаемые заказчикам продукты и услуги. В основе всего этого лежат информационные технологии.
Яркий пример тому — автомобильная отрасль. По признанию экспертов компании Ford, больше половины внедренных за последние пять-семь лет инноваций связаны с использованием передовых информационных технологий не только в конструкторских бюро и производственных цехах, но и в самих автомобилях. Так, бортовые компьютеры уже стали стандартом де-факто и появляются даже в новых моделях отечественных брендов. Все чаще встречаются машины, укомплектованные системами автоматической парковки, а то и полностью управляемые компьютерными системами. Если дело так пойдет и дальше, лет через 20-30 профессия водителя станет столь же редкой, как, например, профессия кучера, возможно, владение машиной станет таим же хобби и роскошью как владение живым скакуном.
Для многих предприятий, вставших на путь цифровой трансформации, разработка программного обеспечения постепенно перестает быть непрофильным видом деятельности, своего рода падчерицей, а становится одним из ключевых направлений развития. К примеру, в 2010 -2011гг. представители ИТ банков часто утверждали, что они не разработчики ПО и управление разработкой и качеством не их задача, а задача подрядчиков. Это теперь все же, прямой бизнес банков, ритейла, связистов и представителей других отраслей, чтобы он не превращался в тяжкое бремя, необходимо вести разработку ПО быстро (не отставая от конкурентов), качественно (не переделывая много раз и не разгребая горы рекламаций от разочарованных клиентов) и рачительно (эффективно с финансово-экономической точки зрения). Как раз это и есть цель Scaled Agile Framework (SAFe) — открытой, доступной в онлайне базы знаний, содержащих проверенные рекомендации и шаблоны для внедрения бережливых (Lean) и гибких (Agile) методик по созданию крупных программных систем, в том числе масштаба предприятия. Среди известных пользователей SAFe — Intel, Lego, BMC Software, Nordea, Accenture Technology, и HPE Software. В этой базе знаний, с одной стороны, реализуются применительно к разработке ПО и инженерных систем принципы бережливого производства — того самого, что принесло славу автоконцерну Toyota, с другой — развиваются и масштабируются до уровня крупного предприятия Agile-методики, такие как Scrum, XP и Kanban и все это сопровождается трансформацией культуры взаимодействия подразделений компании в рамках подхода DevOps. Координацией развития, а также вопросами сертификации по SAFe занимается компания Scaled Agile, Inc.
SAFe можно применять как на малых и средних предприятиях, так и в очень крупных компаниях, где разработкой программного решения могут заниматься и 500, и 1000 человек, создавая весьма сложные и значительные по масштабу системы. В относительно небольших предприятиях польза от SAFe может достигаться за счет управления всем набором технических решений в соответствии с бизнес-стратегией. Разумеется, необходимо понимать, что масштабирование имеет свою цену, и если у вас, скажем, менее 5 команд разработки, то более простые подходы к масштабированию Enterprise Agile могут быть более успешны. Это, кстати, озвучено в первом принципе фреймворка SAFe – смотрите на свою продукцию с экономической точки зрения.
Что же касается крупных компаний, то, если речь идет о создании по-настоящему сложных продуктов с использованием бережливых и Agile-подходов, альтернативы SAFe у них фактически нет, поскольку другие фреймворки масштабирования или не рассчитаны на организацию работы столь многочисленных коллективов разработчиков или недостаточно документированы. Эти продукты могут содержать и программную, и аппаратную части, в том числе электрику и электронику, оптические, механические, гидравлические и другие компоненты. Для их создания требуются разносторонние знания и усилия сотен, а иногда и тысяч специалистов — не только штатных, но и сотрудников компаний-подрядчиков. Сбои в этих системах или подсистемах, на которые нередко возложены критически важные задачи, могут привести к недопустимым экономическим и социальным последствиям.
Уровни SAFe
В рамках SAFe различают четыре уровня управления разработкой: уровень портфелей, цепочек добавленной стоимости, программ и команд (см. рис. 1).
Рис. 1. Уровни SAFe.
Источник: Scaled Agile, Inc.
- Уровень команд — самый нижний. Эти, как правило, небольшие (не более 9 специалистов, в идеале) Agile-команды трудятся на основе подхода ScrumXP, иили в том числе с использованием.
- На уровне программ, втором по иерархии, формируются виртуальные коллективы, название которых — Agile Release Trains — можно перевести как «поезда, доставляющие Agile-релизы» (далее будем для краткости называть их ART-коллективами). Смысл этой метафоры в том, что, подобно поездам, следующим от станции к станции с различными грузами, эти коллективы должны действовать ритмично, четко соблюдать расписание и двигаться с заранее заданной скоростью согласно намеченному плану, доставляя заказчикам прототипы, модели, программные продукты, оборудование, документацию и пр. Специалисты, входящие в состав этих виртуальных коллективов, вместе планируют свою совместную деятельность, фиксируют принятые обязательства и затем их исполняют. Акцент в планировании сделан не на сроках выпуска продукта или релизах, а на ритмичности и синхронизации взаимодействия всех заинтересованных сторон. Если команды успешно трансформированы в Feature teams, то с минимальными синхронизациями такие команды будут успешно работать в рамках своего спринта. При этом в продуктивную среду релиз может уйти в любой момент, как достигнут, к примеру, важный объем функционала.
- Третий уровень — уровень цепочек добавленной стоимости (Value Stream Level). При создании сложных решений, когда требуется применять как научные знания, так и практические навыки, необходимы усилия множества ART-коллективов и компаний-подрядчиков. Цепочка добавленной стоимости — это, по сути, некий процесс, обеспечивающий создание определенного продукта или изделия в интересах одного из бизнес-направлений. Примерами такой цепочки могут служить кредитный конвейер банка или бизнес-процесс интернет-банкинга. Каждым направлением будет заниматься отдельный ART-коллектив, в составе которого — множество команд разработки. Кстати, именно на этом уровне определяется стратегия развития создаваемых продуктов.
- Наконец, четвертый уровень SAFe — уровень портфелей. Портфель содержит набор цепочек добавленной стоимости, а также ряд элементов для общего управления всем, что касается создания и совершенствования продуктов, услуг и решений в соответствии с бизнес-стратегией предприятия, а также их финансирования.
Уровень цепочек добавленной стоимости
Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные и зачастую критически важные системы. На этом уровне определяются функции, свойства и особенности поведения нового продукта, а также контекст, в котором его предстоит развертывать, использовать, поддерживать, продвигать, комплектовать и продавать. Кроме того, формулируются правила принятия решений по экономическим аспектам разработки.
Уровень цепочек добавленной стоимости появился в четвертой версии SAFe, где он не является обязательным. Организации, создающие системы, для разработки которых достаточно нескольких сотен специалистов, могут использовать «усеченный», трехуровневый вариант SAFe, описанный в SAFe версии 3.0.
Аналогично уровню программ, данный уровень строится вокруг инкрементов (приращений) программ. Инкременты — это, по сути, циклы Деминга (планирование — исполнение — контроль — воздействие, Plan-Do-Check-Action, PDCA), для которых обеспечивается сквозная синхронизация ART-коллективов в цепочках добавленной стоимости, что позволяет организовать эффективное и планомерное взаимодействие множества команд и подрядчиков.
Рис. 2. Уровень цепочек добавленной стоимости.
Источник: Scaled Agile, Inc.
Ключевые роли на этом уровне — менеджеры решений (Solution Management), архитекторы и инженеры решений (Solution Architect/Engineering), а также инженер цепочки добавленной стоимости (Value Stream Engineer, VSE).
- Менеджеры решений представляют интересы заказчиков, контролируют выполнение их требований и реализацию стратегических направлений развития портфеля — бизнес-целей, связывающих портфель SAFe и бизнес-стратегию. Вместе с входящими в ART-коллективы менеджерами продуктов они осуществляют детализацию свойств решений и определяют их функции и возможности. Помимо этого на них возлагается ответственность за ведение бэклога всего решения и каждой команды соответственно, в которых будет отражен план создания решения, и установление приоритетов. Им же поручается выработка правил принятия решений по экономическим аспектам создания систем, которые необходимы для управления процессом принятия решений в ART-коллективах и Agile-командах.
- Архитекторы и инженеры решений — команда, определяющая архитектуру решения в целом и, таким образом, объединяющая ART-коллективы. Они работают в тесной связке с системными архитекторами ART-коллективов и инженерами, помогая им определить архитектурный скелет создаваемых продуктов в соответствие с предполагаемой дорожной картой развития продукта.
- Инженер цепочки добавленной стоимости отвечает за то, чтобы цепочка работала четко, без сбоев и задержек, для чего он должен своевременно выявлять узкие места и устранять их. Кроме того, он помогает организовать совещания участников цепочки, отслеживает точность соблюдения сроков выполнения работ (Kanban) и другие показатели метрик, характеризующих цепочку.
Краеугольный камень решения — его замысел. Именно замысел определяет поведение создаваемого изделия и связанных с ним решений, а также является единым «источником правды» и хранилищем всех требований, в том числе истории их уточнений.
Главный структурный компонент уровня цепочек добавленной стоимости — это решение, ведь над его созданием трудится вся цепочка. Решения должны функционировать не просто в соответствии с замыслами, а в своих контекстах — в том окружении, в котором им предстоит «жить» после развертывания. Эти продукты должны отвечать всем требованиям заказчиков, а кроме того, обладать заданными свойствами, быть способными поддержать те бизнес-инициативы, ради которых их создают, и таким образом реализовать свое предназначение.
Управление более масштабными инициативами осуществляется на основе набора менее крупных, но важных инициатив, реализация которых обеспечивает достижение глобальной цели. В процессе анализа этот набор преобразуется в набор свойств решений. Управление ими осуществляется посредством системы Kanban (по сути, «точно в срок»), встроенной в цепочки добавленной стоимости. Kanban помогает удостовериться, что до помещения свойств в бэклог, где их поставят в очередь на реализацию, они уже прошли стадию оценки и анализа, и помогает обеспечить эффективную и продуктивную работу участвующих в анализе этих свойств.
Еще одна функция уровня цепочек добавленной стоимости — координация ART-коллективов, совместно работающих над созданием единого решения. Этот процесс основывается на выстраивании определенной ритмичности инкрементов программ путем синхронизации итераций Agile-разработки. Таким образом обеспечивается взаимодействие не только ART-коллективов, но и подрядчиков. В начале каждого инкремента производится общее планирование на ближайший период, его осуществляют сами коллективы в ходе «планерок PI». Чтобы разработать план, единый для всех цепочек создания добавленной стоимости и учитывающий взаимозависимости между цепочками, перед началом инкрементов и по их окончании и проводятся эти встречи. Они важны для синхронизации, но затратны по вовлечению участников, собирают каждого входящего в коллектив ART, поэтому рекомендуется встречу проводить раз в 10 недель – через 5 спринтов, если их длина 2 недели. По завершении каждого инкремента решение демонстрируется заказчикам и другим заинтересованным лицам. Затем в рамках рабочей встречи анализируется эффективность всей цепочки добавленной стоимости и определяются пути улучшения существующего процесса, что вполне в духе концепции бережливого производства.
Заметим, что наличие некоторых элементов уровня цепочек добавленной стоимости обусловлено особенностями создания крупных, сложных решений и, как следствие, необходимостью организации работы больших коллективов разработчиков. Однако некоторые элементы будут вполне полезны при использовании трехуровневого варианта SAFe. В частности, это касается замысла решения, управления экономическими аспектами разработки, а также взаимодействия с подрядчиками.
Автор: Hewlett Packard Enterprise
