Бережливая разработка программ

Термин бережливый (lean) изначально использовали для обозначения процес­са управления производством, а затем в Массачусетском технологическом инсти­туте в середине 1980-х годов стали употреблять для процесса проектирования изделий. Джон Крафчик, ныне генеральный директор Hyundai Motor America, стал первым американским инженером, нанятым компанией Toyota для работы на ее калифорнийском сборочном заводе New United Motor Manufacturing, основанном как совместное предприятие с General Motors. В 1986 году Крафчик поступил в школу менеджмента MIT Sloan, где получил магистерскую степень. За год до этого была опубликовала книга «Японская автомобильная индустрия», в кото­рой сообщалось, что Toyota, используя методы, развивавшиеся еще с конца 40-х годов, тратила на выпуск автомобилей примерно вдвое меньше человеко-часов, чем компании из «большой тройки» американского автопрома. При этом у Toyota были гораздо более быстрая оборачиваемость складских запасов и более высокое качество. Не отставала от Toyota и Nissan. Крафчик при содействии ди­ректора по исследованиям Международной автомобильной программы МТИ Джеймса Вомака начал исследование с целью сравнения автомобильных заво­дов во всем мире. В 1988 году в статьях Sloan Management Review были даны обобщения управленческой философии Toyota и представлены данные, демон­стрирующие японское превосходство. В то же время Крафчик предложил термин «бережливый» в противовес «буферной» системе массового производства Ford.

Методы Toyota позволяли радикально умень­шить объем промежуточных и конечных запа­сов, предоставляя рабочим сборочной линии возможность управления большим количе­ством машин и вменяя им в обязанность слеже­ние за качеством. Ключевым моментом было то, что в Toyota обратили вспять поток инфор­мационных сигналов (на то время в форме кар­точек «Канбан»), управляющих производствен­ными операциями. В результате этой переме­ны фабрики Toyota получили возможность вы­пускать малые партии комплектующих точно в срок (Just-In-Time, JIT) для конечной сборки и поставки дилерам. При этом устранялась большая часть промежуточных и конеч­ных запасов, создаваемых «на всякий случай». Главный принцип заключался в том, чтобы непрерывно «тянуть» материалы и комплектующие через производ­ственную систему по мере необходимости, а не «толкать» и складировать со­гласно строгим производственным планам. Термины «бережливый» и JIT позд­нее были популяризованы в международном бестселлере «The Machine That Changed the World», авторы которого термином lean обозначали любые практи­ческие методы эффективного управления, позволявшие минимизировать поте­ри, в том числе при проектировании изделий. Излагались методы, благодаря ко­торым японские производители достигали на треть более коротких сроков по­ставки и вдвое меньших затрат времени на проектирование по сравнению с аме­риканскими и европейскими. Более подробное исследование на эту тему было проведено в Гарвардской школе бизнеса Кимом Кларком и Такахиро Фудзимото, опубликовавшими работу «Product Development Performance».

Некоторые общие черты между японским менеджментом и разработкой ПО для персональных компьютеров начали становиться очевидными уже в середине 1990-х — например, в книге «Microsoft Secrets» Кузумано и Ричард Селби упомя­нули применявшийся в Microsoft принцип ежедневных сборок, когда инженеры должны были каждый день приостанавливать работу для исправления ошибок (в книге это было названо «процессом синхронизации и стабилизации»). Авторы от­метили сходство с философией JIT у Toyota, когда рабочие должны были оста­навливать сборочные линии при обнаружении проблем для их немедленного устранения. В книге еще не использовался термин lean для разработки ПО — в то время речь шла в основном о распространенных практиках JIT-инженерии и контроле качества, а также о меньшей бюрократизации и численности персона­ла в Microsoft по сравнению с другими корпорациями, такими как IBM. Чтобы глуб­же погрузиться в автомобильную индустрию, Кузумано с аспирантом Кентаро Но­беокой провел еще одно исследование, изложенное в книге «Thinking beyond Lean». Вдохновением для нее послужила работа Джеймса Вомака и Дэниела Джонса «Lean Thinking» 1996 года, в которой делалась попытка обобщить lean-методы и их применения. В книге речь шла о более новых подходах к проектиро­ванию изделий, упор делался на систематическое повторное использование про­дуктовых платформ и основных комплектующих, а также на другие методы, на­пример, короткие, перекрывающиеся стадии (параллельное проектирование), позволяющие ускорить инженерный этап. Однако о разработке ПО упоминалось лишь вкратце.

Популяризация термина lean и появление ассоциации со скорой (agile) разра­боткой программных продуктов произошли благодаря более поздним исследова­ниям, в частности книге «Lean Software Development» Мэри и Тома Поппендик (2003 год). Как и предыдущие исследователи, авторы сделали акцент на устране­нии потерь и уменьшении бюрократии при разработке, обучении за счет корот­ких циклов и частых сборок, отсрочке принятия решений и быстрых итерациях, а также на принципе «вытягивания», когда модификации продукта обуславлива­лись отзывами, в отличие от «выталкивания», когда разработка идет согласно техническому заданию и жестко заданным планам.

Все авторы, использующие термин lean для разработки ПО, подчеркивают разли­чия между старыми, более трудоемкими и забюрократизированными «выталкива­ющими» процессами, которые раньше ассоциировались с мэйнфреймами, и но­выми гибкими итеративными или инкрементальными методами. Очевидно, что есть немало общего между бережливым производством в стиле Toyota и скорой разработкой в стиле Microsoft (до того как команды разработчиков Windows стали чрезмерно большими в конце 1990-х – начале 2000-х), даже если рассматривать отдельные практики.

Раннее использование термина lean, без сомнения, исходило из популярности японских методов менеджмента, но упор всегда делался на избавление от по­терь времени и лишних кадровых ресурсов; на ценность изделия с точки зрения заказчика, продукта и предприятия; а также на преимущества более гибкого, ите­ративного, малозатратного процесса разработки. Аналогичные акценты замет­ны и в методах XP и Scrum, называемых итеративными, инкрементальными или скорыми и реализующих ряд методов разработки ПО.

Бережливая разработка ПО

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

На самом деле идея применения бережливых принципов к разработке ПО суще­ствует почти столько же, сколько и сам термин lean. В 1990-х Роберт Шаретт пользовался термином «бережливая разработка» для обозначения стратегии управления рисками, динамически обеспечивающей стабильность организации за счет повышения ее устойчивости, толерантности к изменениям и быстроты перестройки. В 2002 году Шаретт опубликовал статью Challenging the Fundamental Notions of Software Development, за десять лет не утратившую своей актуальности. В ней он дает краткое изложение основных тезисов данного руко­водства: «Как уже давно было отмечено, единственное назначение бизнеса — со­здавать заказчика и обслуживать его. Поэтому суть бережливой разработки не в процессе разработки как таковой, а в том, как с помощью ИТ приносить пользу заказчикам. Таким образом, бережливая разработка — это не методология про­граммной инженерии в обычном понимании, это система практических методов, принципов и философии построения программных систем для использования заказчиком».

Авторы книги «Lean Software Development» также выделили семь принципов бе­режливой разработки:

- оптимизация целого;

- устранение потерь;

- забота о качестве;

- постоянное обучение;

- быстрая доставка;

- вовлечение всех участников;

- непрерывное совершенствование.

Эти принципы лежат в основе любого обсуждения того, какие практики разработ­ки продуктов взять на вооружение в зависимости от конкретной организации.

Оптимизация целого

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

Устранение потерь

В терминах бережливой разработки потери — это все, что не приносит прямой пользы заказчику и не добавляет знаний о том, как более эффективно приносить эту пользу. Среди основных видов потерь при разработке ПО: ненужные функ­ции, потеря знаний, недовыполненная работа, передача ответственности и мно­гозадачность, а также затраты времени на поиск и устранение дефектов, отнима­ющие до 40–50% времени разработки. Корни многих видов потерь лежат в боль­шом объеме работы, недоделанной при последовательной организации работ, а также в границах между разными функциями и задержках и потерях знаний, когда эти границы приходится пересекать. Если следить за всем потоком созда­ния ценности (value stream), то причины потерь выявляются и устраняются проще, как и в случае с «вытягивающей» системой JIT-производства.

Забота о качестве

Процесс синхронизации и стабилизации в Microsoft выглядел как резкий отход от преобладающего в то время принципа, согласно которому интеграция малых программных модулей в единую систему проводилась только в конце цикла раз­работки. Но на самом деле непрерывная интеграция малых модулей в более крупные системы уже давно считалась оптимальным методом, хотя и не очень широко применялась. Еще в 1970 году Харлан Миллс из IBM предложил подход, который он назвал «программированием сверху вниз», — процесс, когда модули интегрируются в общую систему по мере написания, а не в конце разработки. В своей книге 1988 года Software Productivity он заметил: «Главный критерий, по ко­торому я сужу, использовалось ли программирование сверху вниз, — это отсут­ствие трудностей интеграции».

Постоянное обучение

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

Первый — это рассмотрение многих вариантов затратных решений: изменение фундаментальной архитектуры, выбор языка и идеологии пользовательского ин­терфейса и т. д. Предлагается откладывать критически важные решения до по­следнего момента, а затем действовать с учетом накопленных знаний. Когда рас­сматриваются многие варианты, всегда найдется подходящая альтернатива и можно выбрать вариант, лучше всего оптимизирующий систему в целом. Часто этот подход называют принципом приоритета обучения (learn first).

Второй — создать сначала минимальный функционал, а затем часто его обнов­лять, используя реальный опыт работы заказчика с продуктом. Такой процесс непрерывного обучения позволит свести к минимуму затраты на разработку функций, не имеющих ценности для заказчика.

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

Быстрая доставка

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

Когда ПО выпускается быстро, то неуместно рассматривать разработку как про­ект. Гораздо лучше принять модель поточной системы, в которой ПО проектиру­ется, разрабатывается и выпускается непрерывным потоком небольших измене­ний. В этом фундаментальное отличие от разработки ПО как проекта, который необходимо выполнить в срок по заранее намеченному плану, или от последова­тельности релизов, выходящих ежегодно или раз в полгода.

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

Вовлечение всех участников

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

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

Непрерывное совершенствование

В статье «Decoding the DNA of the Toyota Production System», опубликованной в 1999 году, Стивен Спиэр и Кент Бауэн указывают, что в Toyota все рабочие си­стемы постоянно совершенствуются по научно обоснованному методу, под руко­водством наставника и на самом низком возможном уровне. Согласно lean-фило­софии, конкретные практические методы, как бы они с виду хорошо ни действова­ли в других ситуациях, редко являются оптимальным решением каждой конкрет­ной актуальной проблемы. Поэтому в соответствии с принципами lean можно ре­комендовать организациям, начинающим с методологий вроде XP и/или Scrum, рассматривать их как начальную платформу, которая со временем будет адапти­роваться и совершенствоваться командами, выполняющими работу для заказчиков.

Скорая разработка ПО

Чтобы поместить бережливую разработку в контекст, полезно указать на общие черты с agile-разработкой и отличия от нее. Распространенный сегодня термин agile в 1990-х годах использовался для обозначения гибких систем производства. В феврале 2001 года его применили к разработке ПО, когда группа единомыш­ленников подготовила «Манифест скорой разработки ПО», в котором провозгла­шается, что при разработке ПО необходимо ставить людей и их взаимодействие выше процессов и инструментов; работоспособное ПО — выше полной докумен­тации; взаимодействие с заказчиком — выше переговоров по контракту; реак­цию на изменения — выше следования плану. Эти предписания противопостав­лялись распространенным в то время практикам разработки ПО, и они опреде­ленно согласуются с lean-принципами. Однако последние предоставляют более полное руководство по выбору практических методов разработки, подходящих для конкретных ситуаций, причем речь не только о разработке ПО.

XP

Первый ставший популярным agile-процесс — это экстремальное программирование (XP), ос­новы которого подробно изложены в книге «Extreme Programming Explained» Кента Бека (2000 год). Основу XP образуют технические практики, самая примечательная из которых — разработка через тестирование (test-driven development). Его реализация требует частого использования системы тестирования моду­лей, благодаря чему дефекты распознаются практически сразу после их появления в кодо­вой базе. Этот подход доказал свою эффектив­ность как первый шаг к избавлению кода от ошибок. Со временем методы усовершенство­вались — время исполнения системы тестирования свели к минимуму, а мас­штабы тестов ограничили так, чтобы они не выходили за разумные пределы.

Со временем концепция разработки через тестирование расширилась — в нее включили автоматизированное формирование спецификаций, подготовив почву для автоматического регрессионного тестирования. Реализация соответствую­щих систем сильно зависит от предметной области, поэтому появились новые инструментарии и методики, помогающие в решении этой задачи: Framework for Integrated Testing (Fit) и FitNesse, разработка через приемочное тестирование (acceptance-test driven development), разработка, основанная на функционирова­нии (behavior-driven development), спецификация на основе примеров (specification by example). Сегодня наиболее распространенным инструментом, используемым для выполнения lean-принципа заботы о качестве, являются кар­касы систем автоматизированного тестирования.

Scrum

Следующим agile-процессом, получившим распространение, стал Scrum, описан­ный в книге 2001 года «Agile Software Development with SCRUM» Кена Швабера и Майка Бидла. На протяжении следующих лет Scrum стал популярен как метод, заменяющий традиционное управление проектами на итерации разработки дли­ной один месяц (а позднее — две недели), поэтому Scrum — отличный способ ввести в разработку ПО lean-концепцию поточного процесса. Ввиду широкой по­пулярности Scrum его часто приравнивают к agile-разработке, однако этот метод не претендует на звание полноценной методологии — нет технических практик, как в XP, и в целом Scrum ограничивается лишь этапом разработки ПО в потоке создания ценности. Тем не менее ранние agile-процессы доказали, что инкре­ментальный выпуск ПО можно применять во многих предметных областях и что за счет строгого выполнения принципов разработки через тестирование можно значительно улучшить качество программ.

Роли

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

Lean-методика рассматривает разработку ПО как один из этапов единого потока создания ценности продукта, а разработчиков — как участников более крупной команды создания продукта. При этом все участники такой команды несут ответ­ственность за успех. В бережливой разработке нет ролей владельца продукта или заказчика. Команды бережливой разработки могут возглавляться, например, главным инженером (в Toyota), менеджером по программам (в Microsoft) или ку­ратором по продуктам (в 3M) — роль такого руководителя напоминает роль предпринимателя, возглавляющего начинающую компанию. Даже если кажется, что есть сходство с ролью заказчика или владельца продукта, то на практике есть большие различия. Главный инженер несет общую ответственность за гото­вый продукт, в том числе за его рыночный успех, и вовлекает всех участников мультидисциплинарной команды в подготовку этого успеха. Нет промежуточного руководителя, который бы отдельно приоритизировал деятельность команды разработки ПО.

«Канбан»

В книге «Scrumban: Essays on Kanban Systems for Lean Software Development» Кори Ладас (2009 год) описал, как пользоваться системой «Канбан» для отслежи­вания прогресса разработки ПО и ограничения объема выполняемой работы. В 2010 году вышла книга Дэвида Андерсона «Kanban», в которой объясняется, как применять «Канбан» для организации эффективной поточной системы разработ­ки ПО.

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

Системы «Канбан» дают организациям хорошую базу для перехода к lean-прин­ципам, поскольку правил и ролей здесь немного, а сами системы требуют вдум­чивого изучения и адаптации. Например, для начала доской «Канбан» можно пользоваться только в среде разработки ПО, но впоследствии можно будет легко добавить новые стадии потока создания ценности, например маркетинг и производственную деятельность. Поэтому «Канбан» — хороший инструмент для команд, участвующих в потоке создания ценности. В системах «Канбан» потоку ценности уделяется особое внимание — поток и узкие места процесса разработ­ки являются главными темами ежедневных собраний. Кроме того, структура и правила доски «Канбан» должны регулярно пересматриваться и совершенство­ваться. Отличное ситуационное исследование по применению системы «Кан­бан» при работе по крупному контракту с правительством приведено в книге Хен­рика Книберга «Lean from the Trenches», вышедшей в 2011 году.

Тенденции

На протяжении последнего десятилетия появлялись все более сложные инстру­менты, сделавшие разработку ПО более защищенной от ошибок и позволившие безопасно непрерывным потоком вносить небольшие новшества в рабочие вер­сии. Эти инструменты вначале были предложены для Web-платформ доставки ПО в виде сервиса.

Непрерывный выпуск

Еще в 2004 году одна крупная Web-компания в конце каждого дня выпускала ра­бочие версии всего ПО, над которым шла работа в течение дня. Топ-менеджер этой компании недавно отметил, что, по его мнению, быстрота — это основа всех lean-принципов: «Если вы выпускаете продукт ежедневно, потери становят­ся видны практически сразу; у вас нет выбора кроме как заботиться о качестве; вы быстро выясняете, что ценят заказчики; все участники на всех уровнях ориен­тируются на выполнение требований заказчика; поскольку проблемы обнаружи­ваются быстро, непрерывное совершенствование является неизбежным; и нако­нец, когда происходят ежедневные внедрения, частичная оптимизация просто недопустима».

В 2011 году Джез Хамбл и Дэвид Фарли в книге «Continuous Delivery» изложили технические практики, необходимые, чтобы непрерывным потоком выпускать го­товое к внедрению ПО безопасно и без дефектов. Эта книга, написанная для кор­поративных департаментов ИТ, перечисляет инструменты, технологии и органи­зационные меры, необходимые, чтобы достичь lean-идеала безопасного ввода ПО в рабочую эксплуатацию немедленно после написания. В ИТ-департамен­тах, последовавших принципам этой книги, выяснили, что для достижения цели еженедельных, ежедневных или даже непрерывных выпусков достаточно пример­но года усердной работы.

Бережливый стартап

Agile-методы обычно предполагают, что действия команды разработки ПО на­правляет заказчик или посредник, однако скорые методики практически не предо­ставляют механизмов, следящих, чтобы требования посредника эффективно ре­шали задачу заказчика. Кроме того, agile-методы обычно не привлекают команду разработки к обеспечению рыночного успеха продукта. В 2011 году Эрик Рис рас­смотрел эти проблемы в книге «Lean Startup», приведя доводы в пользу того, чтобы компании начинали с бизнес-плана, а затем проверяли влияние функций на выполнение прогнозов, на которых план был построен. При таком подходе ко­манда разработки ПО оказывается вовлеченной в создание контуров обратной связи, таких как совместное тестирование (split test, предложение одновременно нескольких версий продукта заказчику), которые помогают определить полез­ность новых особенностей. Таким образом, разработчики ПО участвуют в про­цессе оценки пользы новых функций для заказчиков и на основании их отзывов вносят поправки. Получение откликов о каждой функции позволяет эффективно оценивать действенность различных подходов в компаниях, ориентирующихся на большую аудиторию заказчиков.

Дизайнерское мышление

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

***

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