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

Вольный перевод статьи Applying SAFe to Hardware Development — Scaled Agile Framework®.

Бизнес-гибкость в создании инновационных высококачественных продуктов подразумевает использование Lean и Agile-практик. Применение Agile-подходов давно не ограничивается только разработкой программного обеспечения (ПО), поэтому распространение этих подходов на сферу производства аппаратных средств и оборудования выглядит вполне логичным. Несмотря на то, что производители аппаратного обеспечения (АО) относительно недавно увидели перспективу в использовании Agile-подходов, можно сказать, что ценности Lean-Agile и принципы SAFe® достаточно универсальны, чтобы быть принятыми во внимание и в этой сфере бизнеса. Инженеры АО могут на их основе создавать и внедрять свои собственные передовые методы.

Не будет открытием утверждение о том, что Agile-трансформация предприятия в конечном итоге повлияет на каждую его часть. Двадцать лет назад предприятия изо всех сил боролись с узкими местами в процессе разработки ПО, стремясь как можно быстрее поставить ценность своим клиентам. Затем разработчики ПО стали использовать Agile-практики и создавать новые технологии, такие как виртуализация, микросервисы и инфраструктура-как-код (Infrastructure As Code), повышая скорость поставки, ускоряя выполнение и мотивируя принятие инновационных решений. Сегодня организации, использующие такие Agile-практики и инновации, поставляют ценность значительно быстрее и с гораздо более высоким качеством. Закономерно, что такие новаторы сейчас доминируют на рынке ПО.

Сейчас в аналогичном положении находятся компании, занимающиеся разработкой аппаратных систем. Однако, им повезло больше, чем первопроходцам Agile-разработки двадцать лет назад, потому что сейчас они могут применять уже опробованные идеи. Многие компании уже начали этот путь (рисунок 1). Так, General Motors вдвое сократила время запуска Hummer EV, благодаря широкому использованию виртуализации и цифрового обучения. Эффект связан с тем, что цифровая инженерия смещает обучение «влево» (shift learning left), интегрируя виртуальные чертежи, модели и симуляции, что позволяет получить обратную связь раньше, чем будут созданы физические модели.

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

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

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

Из принципа SAFe №10 (Организуйтесь вокруг ценности) следует, что поток ценности, поставляемой компанией, проходит сквозь её функциональные колодцы. Используя традиционный подход, мы организуем работы по функциональному признаку. Возьмем, к примеру, новое сопло ракеты, которое состоит из механических конструкций (Hardware, HW — АО), специально разработанной электрической схемы со встроенным ПО (Firmware, FW — прошивки) и программной логики для регулировки сопла и управления им (Software, SW — ПО). При традиционном подходе каждая из этих составляющих разрабатывается независимо, в соответствии с подробными спецификациями и общим графиком. Верификация и валидация происходит только в конце, когда все компоненты интегрированы, что делает любые корректировки весьма дорогостоящими.

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

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

Пример: Российский производитель программно-аппаратных комплексов для автоматизации ритейла

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

Со временем организация команд может изменяться. Ранние стадии разработки продукта часто требуют большего количества инноваций, более тесного взаимодействия, более частой обратной связи (пример №1 на рисунке 2). Разработка на более поздних стадиях может требовать меньше творчества и быть сосредоточена на доработке отдельных частей программно-аппаратного продукта (примеры №2 и №3 на рисунке 2).

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

Предполагайте изменчивость и сохраняйте опции

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

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

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

Братья Райт были, пожалуй, первой инновационной командой, применившей дизайн, основанный на наборах опций. Они тестировали повторяющиеся прототипы подсистем (крылья, руль направления, руль высоты), которые они часто интегрировали с воздушными змеями, планерами и, в конечном итоге, с летательным аппаратом. Ранние интеграции подтвердили их решения и предоставили быструю обратную связь для внесения изменений. Окончательные проектные решения они принимали только после получения достаточных знаний и достаточного уменьшения конуса неопределенности (рисунок 3). Более подробную информацию можно найти в статье о принципе SAFe №3 (Предполагайте изменчивость, сохраняйте опции).

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

Собирайте инкрементально, интегрируйте часто

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

На рисунке 5 традиционный подход сравнивается с непрерывным. Для получения новых знаний и данных о будущем решении SpaceX стремится запускать следующую версию ракеты каждые 2-3 месяца. Обучение — это цель, даже если тесты окажутся неудачными (см. твит Маска на рисунке 5). Вместо того чтобы сосредотачиваться на оттачивании каждого компонента (а также узла и сборки), SpaceX сосредотачивается на создании инфраструктуры для быстрого тестирования следующей версии всего решения. Транзакционные издержки на создание и запуск следующей ракеты меньше, чем затраты на отсроченное обучение. Послушайте, что главный администратор НАСА (NASA, National Aeronautics and Space Administration, Национальное управление по аэронавтике и исследованию космического пространства) Джим Брайденстайн, говорит о том, чему научилась NASA благодаря работе со SpaceX.

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

При разработке больших систем процесс разработку продукта позволяют контролировать точки интеграции, создавая знания из неопределенности (принцип SAFe №4). В результате интеграции инкрементов всех команд всех поездов, обучается система в целом. Все команды и все поезда работают в общем темпе, что позволяет иметь естественные точки интеграции для всей системы.

Проектируйте для изменения

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

Хотя проектирование с учетом будущих изменений и не ново, плохое понимание экономики может помешать принятию правильных проектных решений. Например, части специализированных интегральных схем (ASIC, Application-Specific Integrated Circuit) часто выбирают из-за их более низкой удельной стоимости и энергопотребления. Но их функциональность фиксирована; любое изменение требует изготовления и установки новой детали. С другой стороны, ПЛИС (программируемые логические интегральные схемы – FPGA, Field-Programmable Gate Array) и системы на кристалле (SOC, System-on-a-Chip) могут быть быстро и экономично модифицированы как в среде разработки, так и в среде эксплуатации. Физические соединения часто используют пайку или сварку для снижения затрат на сборку. Безусловно, разъемные соединения, такие как крепежи и соединители, увеличивают стоимость, но зато делают возможными и более доступными будущие изменения. Для создания обширных подсистем, не требующих сборки, также используется аддитивное производство. На протяжении всего жизненного цикла продукта расчет экономических показателей должен включать в себя общие затраты на изменения и ценность развивающихся систем в среде эксплуатации и разработки.

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

Выполняйте работу небольшими партиями

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

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

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

Использование для формирования историй четких формулировок и использование таких практик, как DoR (Definition of Ready, критерии готовности начинать работу) и DoD (Definition of Done, критерии завершенности работы), дает командам, занимающимся разработкой АО, заметные преимущества перед теми командами, кто этому не уделяет должного внимания. Это особенно верно для кросс-функциональных команд, работающих в относительно новой для них бизнес-области, не имея в ней достаточного опыта. DoD определяет соглашение команды о том, когда работа считается завершенной, и помогает повысить уровень встроенного качества.

DoD, например, может включать надлежащее документирование результирующих данных и восстановление оборудования до состояния, пригодного для повторного использования. DoR используется Agile-сообществом реже и поэтому не является частью фреймворка SAFe. Однако, его использование тоже полезно при разработке АО, которая часто зависит от внешних элементов, таких как доступность оборудования или наличие выделенных специализированных ролей (например, только инженер по технике безопасности может одобрить подачу питания), заказанные материалы и многое другое. DoR сообщает, что требуется, чтобы реализовать планируемую историю.

Разработка аппаратного обеспечения тоже требует непрерывной интеграции

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

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

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

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.