- PVSM.RU - https://www.pvsm.ru -
Напомним, что Scaled Agile Framework [1] содержит несколько уровней иерархии от управления командной до управления портфелем предприятия. И одним из уровней является управление цепочками добавленной стоимости. Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные или критически важные системы. Однако некоторые его элементы будут вполне полезны и не очень крупным предприятиям.
Для того чтобы оставаться конкурентоспособным, современному предприятию проходится проводить серьезные преобразования, одно из ключевых направлений которых — цифровизация, или цифровая трансформация. Это емкое понятие подразумевает не просто автоматизацию или внедрение инноваций на основе ИТ, а нечто большее: серьезное изменение как бизнес-процессов, так и бизнес-моделей — основ деятельности предприятия, зарабатывания им денег и создания ценности для клиентов. Зачастую кардинально меняются предлагаемые заказчикам продукты и услуги. В основе всего этого лежат информационные технологии.
Яркий пример тому — автомобильная отрасль. По признанию экспертов компании Ford, больше половины внедренных за последние пять-семь лет инноваций связаны с использованием передовых информационных технологий не только в конструкторских бюро и производственных цехах, но и в самих автомобилях. Так, бортовые компьютеры уже стали стандартом де-факто и появляются даже в новых моделях отечественных брендов. Все чаще встречаются машины, укомплектованные системами автоматической парковки, а то и полностью управляемые компьютерными системами. Если дело так пойдет и дальше, лет через 20-30 профессия водителя станет столь же редкой, как, например, профессия кучера, возможно, владение машиной станет таим же хобби и роскошью как владение живым скакуном.
Для многих предприятий, вставших на путь цифровой трансформации, разработка программного обеспечения постепенно перестает быть непрофильным видом деятельности, своего рода падчерицей, а становится одним из ключевых направлений развития. К примеру, в 2010 -2011гг. представители ИТ банков часто утверждали, что они не разработчики ПО и управление разработкой и качеством не их задача, а задача подрядчиков. Это теперь все же, прямой бизнес банков, ритейла, связистов и представителей других отраслей, чтобы он не превращался в тяжкое бремя, необходимо вести разработку ПО быстро (не отставая от конкурентов), качественно (не переделывая много раз и не разгребая горы рекламаций от разочарованных клиентов) и рачительно (эффективно с финансово-экономической точки зрения). Как раз это и есть цель Scaled Agile Framework (SAFe) [2] — открытой, доступной в онлайне базы знаний, содержащих проверенные рекомендации и шаблоны для внедрения бережливых (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 различают четыре уровня управления разработкой: уровень портфелей, цепочек добавленной стоимости, программ и команд (см. рис. 1).
Рис. 1. Уровни SAFe.
Источник: Scaled Agile, Inc.
Спрос на этот уровень имеется со стороны крупных организаций, создающих масштабные и зачастую критически важные системы. На этом уровне определяются функции, свойства и особенности поведения нового продукта, а также контекст, в котором его предстоит развертывать, использовать, поддерживать, продвигать, комплектовать и продавать. Кроме того, формулируются правила принятия решений по экономическим аспектам разработки.
Уровень цепочек добавленной стоимости появился в четвертой версии SAFe, где он не является обязательным. Организации, создающие системы, для разработки которых достаточно нескольких сотен специалистов, могут использовать «усеченный», трехуровневый вариант SAFe, описанный в SAFe версии 3.0.
Аналогично уровню программ, данный уровень строится вокруг инкрементов (приращений) программ. Инкременты — это, по сути, циклы Деминга (планирование — исполнение — контроль — воздействие, Plan-Do-Check-Action, PDCA), для которых обеспечивается сквозная синхронизация ART-коллективов в цепочках добавленной стоимости, что позволяет организовать эффективное и планомерное взаимодействие множества команд и подрядчиков.
Рис. 2. Уровень цепочек добавленной стоимости.
Источник: Scaled Agile, Inc.
Ключевые роли на этом уровне — менеджеры решений (Solution Management), архитекторы и инженеры решений (Solution Architect/Engineering), а также инженер цепочки добавленной стоимости (Value Stream Engineer, VSE).
Краеугольный камень решения — его замысел. Именно замысел определяет поведение создаваемого изделия и связанных с ним решений, а также является единым «источником правды» и хранилищем всех требований, в том числе истории их уточнений.
Главный структурный компонент уровня цепочек добавленной стоимости — это решение, ведь над его созданием трудится вся цепочка. Решения должны функционировать не просто в соответствии с замыслами, а в своих контекстах — в том окружении, в котором им предстоит «жить» после развертывания. Эти продукты должны отвечать всем требованиям заказчиков, а кроме того, обладать заданными свойствами, быть способными поддержать те бизнес-инициативы, ради которых их создают, и таким образом реализовать свое предназначение.
Управление более масштабными инициативами осуществляется на основе набора менее крупных, но важных инициатив, реализация которых обеспечивает достижение глобальной цели. В процессе анализа этот набор преобразуется в набор свойств решений. Управление ими осуществляется посредством системы Kanban (по сути, «точно в срок»), встроенной в цепочки добавленной стоимости. Kanban помогает удостовериться, что до помещения свойств в бэклог, где их поставят в очередь на реализацию, они уже прошли стадию оценки и анализа, и помогает обеспечить эффективную и продуктивную работу участвующих в анализе этих свойств.
Еще одна функция уровня цепочек добавленной стоимости — координация ART-коллективов, совместно работающих над созданием единого решения. Этот процесс основывается на выстраивании определенной ритмичности инкрементов программ путем синхронизации итераций Agile-разработки. Таким образом обеспечивается взаимодействие не только ART-коллективов, но и подрядчиков. В начале каждого инкремента производится общее планирование на ближайший период, его осуществляют сами коллективы в ходе «планерок PI». Чтобы разработать план, единый для всех цепочек создания добавленной стоимости и учитывающий взаимозависимости между цепочками, перед началом инкрементов и по их окончании и проводятся эти встречи. Они важны для синхронизации, но затратны по вовлечению участников, собирают каждого входящего в коллектив ART, поэтому рекомендуется встречу проводить раз в 10 недель – через 5 спринтов, если их длина 2 недели. По завершении каждого инкремента решение демонстрируется заказчикам и другим заинтересованным лицам. Затем в рамках рабочей встречи анализируется эффективность всей цепочки добавленной стоимости и определяются пути улучшения существующего процесса, что вполне в духе концепции бережливого производства.
Заметим, что наличие некоторых элементов уровня цепочек добавленной стоимости обусловлено особенностями создания крупных, сложных решений и, как следствие, необходимостью организации работы больших коллективов разработчиков. Однако некоторые элементы будут вполне полезны при использовании трехуровневого варианта SAFe. В частности, это касается замысла решения, управления экономическими аспектами разработки, а также взаимодействия с подрядчиками.
Автор: Hewlett Packard Enterprise
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-produktom/117634
Ссылки в тексте:
[1] Scaled Agile Framework: https://megamozg.ru/company/hpe/blog/25298/
[2] Scaled Agile Framework (SAFe): http://www.scaledagileframework.com/
[3] Источник: https://megamozg.ru/post/25460/
Нажмите здесь для печати.