SAFe для разработки аппаратного обеспечения

Переход к Agile подходам в разработке аппаратного обеспечения

Гибкость бизнеса требует, чтобы все, кто участвует в доставке продукта, использовали Lean и Agile практики для создания инновационных, высококачественных продуктов. В настоящее время Agile подходы используются не только при разработке программного обеспечения – их можно и нужно применять и при создании аппаратного обеспечения и оборудования. Несмотря на то, что сами разработчики аппаратного обеспечения часто являются новичками в мире Agile, можно с уверенностью утверждать, что существующие ценности и принципы Lean-Agile, на которых основан SAFe, универсальны. Они могут направлять работу инженеров по аппаратному обеспечению при создании и внедрении собственных передовых методов работы.

Agile трансформация в конечном итоге затронет все части предприятия. Двадцать лет назад компании сталкивались с трудностями в доставке ценности своим клиентам из-за узких мест в разработке программного обеспечения (ПО). Специалисты ПО начали применять Agile практики и создали новые технологии, такие как виртуализация, микросервисы и «инфраструктура как код». Гибкие подходы позволили организациям ускорить процесс выполнения работ и стимулировали разработку инноваций. Сегодня организации, использующие эти Agile практики и инновации в разработке, доставляют ценность значительно быстрее и качественнее. Компании, которые были этими ранними новаторами, теперь доминируют на рынке программного обеспечения.

Организации, создающие аппаратные системы, в настоящее время находятся в той же ситуации, с которой когда-то столкнулись разработчики ПО. Однако, в отличии от упомянутых разработчиков ПО, сейчас предприятия могут воспользоваться наработками предыдущих двух десятилетий. Многие компании уже вступили на этот путь (рис. 1). Благодаря широкому использованию виртуализации и обучения с использованием цифрового пространства, компания General Motors сократила время, необходимое для запуска автомобиля Hummer EV, в два раза [1]. Это связано с тем, что цифровое проектирование смещает обучение влево за счёт интеграции виртуальных чертежей, моделей и симуляций для получения обратной связи перед созданием физических деталей.

SpaceX использует аддитивное производство во всех частях своей системы, от ракетных двигателей до шлемов [2]. Аддитивное производство позволяет печатать физические детали на месте, на основе данных системы автоматизированного проектирования (САПР). Это существенно быстрее, чем при традиционных процессах производства и сборки. Apple, Google и Amazon также разрабатывают свой дизайн оборудования для удовлетворения потребностей бизнеса [3].

Рисунок 1. Новаторы в области аппаратного обеспечения идут по тому же пути, что и новаторы в области программного обеспечения

Как использовать SAFe в разработке аппаратного обеспечения?

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

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

Принцип SAFe #10 «Организоваться вокруг ценности» описывает, что ценность в организации проходит через её функциональные силосы. Традиционно работа таких силосов строится вокруг функциональных навыков. Пример: новое ракетное сопло имеет механическую структуру, которая является аппаратным обеспечением (hardware, HW), но содержит электрическую схему, которая содержит встроенный микрокод (firmware, FW), и ещё включает в себя более высокоуровневую логику управления соплом, которая является программным обеспечением (software, SW). При традиционном подходе каждый из этих элементов разрабатывался бы независимо, в соответствии с подробными спецификациями и фиксированным графиком. В таком сценарии проверка и валидация проводились бы только в конце разработки, когда все компоненты интегрированы в единое целое. В результате — любая корректировка становится крайне дорогостоящей.

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

Рисунок 2. Три примера организации команд при разработке аппаратного обеспечения и оборудования

1. Кросс-функциональные Agile команды работают в высокоинновационной среде, часто проводят эксперименты и тесто сотрудничают по всем доменам знаний. Инновации в подавлении шумов, электрике и логике управления быстро интегрируются и проверяются.
2. Некоторые инновационные среды не требуют тесного сотрудничества внутри одной команды, и домены могут работать более независимо. Тем не менее, чтобы обеспечить согласованность и со-направленность работ, обе команды входят в один Релизный Поезд (Agile Release Train, ART) и используют SAFe практики для управления зависимостями и частой интеграции.
3. Какие-то среды являются более предсказуемыми. В этом случае команды могут работать независимо над компонентами своей системы, со-направляя свою работу с общей дорожной картой, определяющей критические точки интеграции. Эти команды могут входить или могут не входить в один Поезд (ART).

То, как команды организованы, может со временем меняться. Разработка изначального продукта часто требует большего количества инноваций и более быстрого цикла обратной связи (пример #1 на рисунке 2). Более поздняя разработка требует меньше творчества и сосредоточена на доработке элементов в соответствии с общим дизайном продукта (примеры #2 и #3 на рисунке 2).

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

Принимать вариативность, сохранять опциональность

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

Сэмюэл Лэнгли и братья Райт были основными конкурентами в борьбе за создание летательного аппарата. Это соперничество является отличным примером для демонстрации двух разных подходов к работе. После того, как Лэнгли успешно продемонстрировал первоначальную версию своего беспилотного «аэродрома» (так Лэнгли тогда называл летательный аппарат), он получил хорошее финансирование. Затем он посвятил годы совершенствованию единственной конструкции, которая, к сожалению, содержала фундаментальные недостатки, которые мешали ей самостоятельно поддерживать полёт.

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

Братья Райт были, пожалуй, первой инновационной командой, применившей подход «Множественный Дизайн» (Set-Based Design). Они испытывали повторяющиеся прототипы подсистем (крылья, вертикальное и горизонтальное оперение), которые они часто интегрировали с их кайтами, планерами и летательным аппаратом. Интеграции подтверждали их решения и предоставляли быструю обратную связь для внесения корректировок. Окончательные решения по дизайну они принимали только после получения достаточного количества знаний и снижения конуса неопределенности (рис. 3).

Рисунок 3. Изучите альтернативные варианты дизайна, чтобы превратить вопросы в знания

По мере того, как команды создают знания, появляющиеся решения необходимо фиксировать и управлять ими. В SAFe организациях команды хранят и управляют этой информацией с помощью Интента Решения (Solution Intent), который является репозиторием системных знаний, включающим спецификации системы. «Быть Agile» означает, что эти спецификации не являются фиксированными – они развиваются на основе обучения. (Рисунок 4) Дорожная карта решения определяет этапы обучения, которые стимулируют проведение исследований и определяют знания, необходимые для создания системы. Каждый шаг в работе (инкремент работы) вносит новый вклад в Интент Решения и перемещает спецификации из переменных в фиксированные.

Рисунок 4. Исследование и обучение являются непрерывными, на их основе спецификации переходят из переменных в фиксированные

Создавать инкрементально, часто интегрировать

В традиционной разработке, основанной на «фазовых воротах» (датах, которые являются фиксированными вехами окончания каждого этапа проекта), успех часто определяется степенью соблюдения фиксированного графика. К сожалению, такой подход вынуждает принимать решения слишком рано и может привести к ощущению «ложно-положительной выполнимости» [4]. В SAFe вехи основаны на объективной оценке реально работающих систем (принцип SAFe #5). Это требует, чтобы все команды, включая команды разработки аппаратного обеспечения, часто интегрировали инкременты своей работы в цельное решение.

На рисунке 5 показана разница между двумя противоположными подходами: традиционным и непрерывным. SpaceX прилагает максимум усилий, чтобы каждые 2-3 месяца запускать следующую версию ракеты. Такой подход позволяет компании непрерывно получать новые знания и данные о будущем решении. Обучение — это цель, даже когда испытания могут выглядеть неудачными (см. твит Илона Маска на рисунке 5). Вместо того, чтобы сосредотачиваться на глубокой оценке каждого компонента (и далее узла и сборки), SpaceX направляет свой фокус на создание инфраструктуры для быстрого тестирования следующей версии решения. Связан такой подход с тем, что по оценкам SpaceX транзакционные издержки на создание и запуск следующей ракеты на самом деле меньше, чем затраты, которые мы несем в связи с отсутствием новых знаний об интегрированном решении (затраты в связи с отложенным обучением, именуемые «holding costs»). Посмотрите интервью [5], в котором главный администратор NASA, Джим Брайденстайн, обсуждает то, что NASA узнало за время работы со SpaceX.

Рисунок 5. Разница между традиционной и непрерывной разработкой

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

Рисунок 6. Как SAFe видит разработку летательного аппарата братьями Райт

Точки интеграции управляют разработкой продукта [4], создавая знания из неопределённости (принцип SAFe #4) при разработке больших систем. Релизные Поезда (ART) интегрируют инкременты работы, которые были выполнены командами Поезда, чтобы вся система обучалась. При таком подходе все команды и Поезда работают в едином ритме, что способствует созданию единых точек интеграции для всей системы.

Дизайн, поддерживающий изменения

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

Рисунок 7. Модульные конструкции обеспечивают частые независимые итерации их дизайнов

Хотя проектирование с поддержкой будущих изменений не является чем-то новым, плохое понимание экономики может помешать принятию правильных решений в области дизайна. Например, именно специализированные интегральные микросхемы (ASIC) часто выбирают из-за более низкой стоимости единицы продукции и их более низкого энергопотребления. Но их функционал фиксирован. Любое изменение потребует изготовления и установки новой детали. С другой стороны, программируемая пользователем логика (FPGA) и системы на кристалле (SOC) могут быть быстро и экономично модифицированы как в среде разработки, так и (!) уже в эксплуатации. Для физических соединений часто используются припои или сварные швы, чтобы снизить затраты на сборку. Непостоянные соединения, такие как крепежные элементы и соединители, увеличивают стоимость, но делают изменения возможными и более доступными. В некоторых случаях в настоящее время эффективнее использовать аддитивное производство для создания масштабных подсистем, вообще не требующих сборки. Экономические показатели обязаны учитывать все будущие затраты на изменения и будущую ценность от развития систем в среде разработки и далее в эксплуатации – в течение всего жизненного цикла продукта.

Выполнение работы малыми партиями

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

Двадцать лет назад сообщество разработчиков программного обеспечения столкнулось с аналогичной проблемой, когда начинало свой путь в Agile. Со временем они создали инновации (например, управление микросервисами и API) и инструменты для непрерывной интеграции и непрерывного развёртывания, которые упростили работу с небольшими партиями. Сегодня большинство разработчиков программного обеспечения могут реализовывать небольшие, вертикально «нарезанные» Истории и создавать работающие продукты в рамках каждой итерации. Сообщество разработчиков аппаратного обеспечения только начинает своё путешествие в Agile, и это путешествие может оказаться непростым. Но со временем производители оборудования разработают свои практики, внеся инновации и изменения в свои средства автоматизированного проектирования (CAD) электрических и механических элементов устройств, которые упростят работу с малыми партиями.

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

Второй способ касается выделения работ по интеграции изменений с более комплексным решением. Например, вместо того, чтобы проектировать всю печатную плату или механическую часть, создайте несколько схем или частей детали. Затем найдите способ объединить их с другими частями системы для получения обратной связи, интегрируя модели, используя макетные платы или соединяя детали, напечатанные на 3D-принтере. Инженерные лаборатории наполнены экспериментами такого рода. Отслеживайте такую работу в беклогах и создавайте упреждающий образ мышления в отношении небольших инженерных изменений и проверок в более широком контексте системы. На рисунке 8 показан пример Канбан доски Историй для команды, которая разрабатывает камеру, которая упоминалась выше.

Рисунок 8. Пример Канбан доски команды разработчиков аппаратного обеспечения

Команды разработки аппаратного обеспечения получают дополнительные преимущества от использования хорошо подготовленных Историй, получая в том числе возможность использовать «Определение Готовности к разработке» (DoR) и «Определение Завершённости/Выполненности» (DoD). Это особенно верно для кросс-функциональных команд, где участники могут работать в относительно новой области, не зная обо всех необходимых практиках управления качеством. «Определение Завершённости» (DoD) описывает предварительно достигнутую договорённость команды о том, как определить, что «работа выполнена», и помогает повысить качество.

«Определение Завершённости» (DoD) по аппаратному обеспечению может включать в себя надлежащее документирование результатов обработки данных и восстановление оборудования до состояния, пригодного для повторного использования. DoR реже используется Agile сообществом и, соответственно, напрямую не встречается в SAFe. Тем не менее, если выполнение работ по разработке аппаратного оборудования часто зависит от внешних факторов, в этом случае применение DoR может быть оправдано. Такими внешними факторами могут быть: доступность оборудования и поддерживающих ролей (например, только инженер по технике безопасности может утверждать включение питания), наличие заказанных материалов и многое другое. DoR сообщает, что конкретно требуется для того, чтобы можно было приступить к работе над ближайшей Историей. Подкаст [6] описывает ценность применения DoR и DoD для динамичных, кросс-функциональных команд Tesla, занимающихся аппаратным обеспечением, при этом итерации у этих команд измеряются часами, а не днями.

Непрерывная Интеграция для Аппаратного Обеспечения

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

Рисунок 9. Непрерывная интеграция аппаратного обеспечения происходит в трех местах

• Виртуальный мир – Разработка аппаратного обеспечения начинается с создания моделей в инструментах проектирования (например, электрических и механических САПР). В настоящее время многие организации начинают с интеграции еще пока виртуальных моделей, чтобы обеспечить анализ и моделирование для получения ранней обратной связи в контексте более крупной системы. Разработчики могут верифицировать с заинтересованными сторонами совместимость моделей дизайнов перед физическим изготовлением физических деталей дизайна.
• Физический мир – Некоторые аспекты дизайна можно проверить только с помощью физических деталей. Многие организации активно используют аддитивное производство и 3D-печать для получения ранней обратной связи. В современном мире эти практики также могут использоваться и для основного производства деталей, когда инновации требуют высокой частоты изменений и небольших объёмов производства [1]. Снижение ограничений на качество и надёжность разрабатываемых деталей также может ускорить проверку дизайна в физическом мире. Детали, разработанные с целью проектирования изделия, часто функционируют в контролируемой среде и быстро заменяются следующей модификацией, в отличие от серийных деталей, которые должны прослужить годы в агрессивной среде.
• Операционный мир (мир эксплуатации) — Системы должны быть спроектированы таким образом, чтобы можно быть легко вносить изменения непосредственно в рабочей среде. Рассмотренные ранее некоторые варианты дизайна (программируемая логика/FPGA вместо специализированных микросхем/ASIC и разъёмы вместо припоя) представляют собой примеры решений, позволяющих менять дизайн в операционном мире. Распределение функциональности системы по элементам дизайна также играет критически важную роль. Поскольку обновление по современным каналам беспроводной связи с высокой пропускной способностью радикально дешевле, больше ограничений, определяющих поведение, переносится на уровень программного обеспечения и программируемые компоненты.

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

Автоматизация действий, необходимых для обеспечения непрерывной интеграции, ускоряет процесс работы в этих средах и обеспечивает более быстрое получение обратной связи по изменениям разработки. Среда непрерывной интеграции также является системой, и разработчики должны вкладывать время и ресурсы в разработку и создание этой системы. Как говорит Илон Маск, «фабрика – это [тоже] продукт».

Узнать больше:

[1] SpaceX Triggers Increased Use Of 3D Printing, 2020 https://www.fabbaloo.com/blog/2020/6/9/spacex-triggers-increased-use-of-3d-printing
[2] Automakers use virtual reality to reduce development time for vehicles like the Hummer EV., 2020. https://www.cnbc.com/2020/11/08/automakers-use-virtual-reality-to-cut-the-development-time-for-vehicles-like-the-hummer-ev.html
[3] Why Tech Giants Like Amazon Are Designing Their Chips — And Who Benefits, 2018. https://www.thestreet.com/opinion/why-tech-giants-are-designing-their-own-chips-14807638
[4] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
[5] Exclusive interview with Elon Musk and Jim Bridenstine about #DM2, SpaceX flies astronauts for the first time, 2020. https://youtu.be/p4ZLysa9Qqg?t=266
[6] Agile at Tesla with Joe Justice. The Agile Wire Podcast, 2021. https://www.theagilewire.com/recordings/agile-at-tesla-with-joe-justice
[7] Inside Elon Musk’s plan to build one starship a week. ARS Technica, 2020. https://arstechnica.com/science/2020/03/insMusk’son-musks-plan-to-build-one-starship-a-week-and-settle-mars

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Applying SAFe for hardware development».

Почитать дополнительно по теме:

Инженерная философия Илона Маска

Новый курс SAFe for Hardware

Scaled Agile, Inc. запустили новый курс SAFe for Hardware, который мы также добавили в наше портфолио. Тренинг помогает лидерам организаций увидеть, как применять принципы и практики Lean-Agile и SAFe к разработке аппаратного обеспечения. Узнать больше о курсе: https://ionovpartners.ru/trainings/safe-for-hardware/