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

Термин бережливый (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-х), даже если рассматривать отдельные практики. В книге Кузумано от 2010 года перечислены эти сходные элементы, иллюстрирующие принцип «тяните, а не только толкайте» (см. табл. 1).

Раннее использование термина 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-метод — более удачный кандидат для компоновки проектирования, разработки, развертывания и аттестации в единый контур обратной связи, ориентированный на выяснение потребностей заказчика и их выполнение.