Стивен Деннинг - Эпоха Agile

Возможно, вы скажете, что разделение работы на микрочасти имеет смысл, лишь когда речь идет о персональных устройствах вроде iPhone. Правомерен ли такой подход в отношении серьезного промышленного проекта, например для создания истребителя нового поколения? Да, правомерен, и тому уже есть подтверждение. Так, шведский производитель воздушных судов Saab разработал истребитель Gripen именно на основе Agile-практик [42]. Каждые полгода Saab объявляет о новом выпуске операционной системы истребителя. Она делает его быстрее, дешевле, легче, эффективнее, мощнее, улучшает электронику и обеспечивает более продвинутые системы наведения. Ведущие эксперты по вопросам обороны назвали Gripen «лучшим малозаметным истребителем в мире» [43].

Авторитетная международная издательская группа IHS Jane’s, специализирующаяся на военной тематике, провела исследование, сравнив операционные издержки детища Saab с издержками истребителей F-16 и F-35 (Lockheed Martin), F/A-18 Super Hornet (Boeing), Rafale (Dassault) и Typhoon (Eurofighter). И пришла к выводу, что Gripen имел «наименьшие операционные расходы среди всех изученных истребителей». При этом рассматривались такие факторы, как расход топлива, предполетная подготовка и ремонт, а также регулярное аэродромное техобслуживание совместно с сопутствующими затратами на персонал» [44].

Программное обеспечение играет все более значимую роль в разработке и эволюции Gripen. «Головная боль, с которой сталкиваются производители истребителей, – пишет Билл Свитман в Aviation Week and Space Technology, – заключается в том, что каким бы грамотным ни был ваш проект, разработка и создание этих самолетов ведет к огромным расходам. Кроме того, их жизненный цикл от проектирования до утилизации намного превосходит рамки политического или технологического горизонта». Gripen был разработан с учетом этих особенностей: «Продолжительный срок службы требует гибкости как в отношении боевых миссий, так и на протяжении жизненного цикла» [45].

Тот же феномен наблюдается в мире автомобилей. На протяжении первого века существования автомобилей человек покупал машину без всякой возможности модифицировать впоследствии свое приобретение, например увеличив его мощность или повысив функциональность. Теперь ситуация изменилась. В частности, Tesla может дополнить новыми функциями – автоматическим торможением при вероятном столкновении, частичной системой автопилота и автоматизированной системой парковки – уже проданные автомобили, загрузив в них новое ПО. Подобные возможности предлагаются и другими производителями автомобилей класса люкс вроде Audi или Mercedes-Benz. Разница лишь в том, что Tesla Model S разработана с возможностью постоянного апгрейда «на лету».

«Model S, по сути, представляет собой очень сложный компьютер на колесах, – рассказывает CEO компании Илон Маск. – Tesla разрабатывает как ПО, так и аппаратное обеспечение. Мы относимся к апгрейду автомобиля так же, как к обновлению телефона или ноутбука» [46].

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

В этой связи полезно вспомнить, что Agile-менеджмент начал ассоциироваться с программным обеспечением лишь с 2001 года. Исторические же его корни лежат в сфере производства – в quality movement в Японии, в частности в Toyota Production System. Компания начала с того, что стала экспериментировать с маленькими промышленными сериями и обнаружила, что работа короткими циклами, определяемыми спросом, оказалась более эффективной, чем массовое производство [47].

Такая модель распространилась в Японии в 1970-х годах и в 1980-х добралась до США. Обнаружилось, что при правильном ее применении длительность производственного цикла с учетом мелких партий можно сократить в 10–100 раз, а объем запасов – более чем на 90 %, что высвобождало огромные суммы денег. К «вторичным» эффектам относились повышение качества, ускорение обучения и снижение себестоимости продукта.

Итерационный подход, распространенный затем на другие производственные сферы, описан в статье Хиротаки Такеучи и Икуджиро Нонаки The New New Product Development Game, опубликованной в Harvard Business Review в 1986 году. Авторы писали:

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

Этот целостный подход обладает шестью характеристиками: встроенной нестабильностью, самоорганизующимися проектными командами, параллельными фазами разработки, мультиобучением, неявным контролем и передачей знаний внутри организации. Шесть элементов складываются, словно пазл, в быстрый, гибкий процесс разработки нового продукта. Не менее важен тот факт, что новый подход может инициировать перемены. Это инструмент создания креативных идей и процессов, ориентированных на рынок, внутри существующей организации [48].

В качестве примеров в статье приводятся Fuji-Xerox, Honda и Canon, разрабатывающие аппаратное, а отнюдь не программное обеспечение.

В 1990 году итерационный микрокомандный подход распространился шире. В классической книге «Машина, которая изменила мир» [49]он получил название «бережливое производство» [50]. Однако, зародившись в сфере аппаратного обеспечения, систематическое использование микрокоманд и итерационных подходов получило подлинное признание именно в сфере разработки ПО после публикации Agile-манифеста в 2001 году.

Какие именно практики входят в Закон микрокоманды? Зависит от того, с какой стороны посмотреть. В течение первого десятилетия после публикации Agile-манифеста его приверженцы яростно спорили друг с другом, пытаясь определить «настоящие Agile-практики». Одни называли Scrum. Другие твердо верили, что это Канбан, третьи – что это Lean (бережливое производство). В конце концов стало понятно, что правильный ответ звучит иначе. Закон микрокоманды подразумевает образ мышления, а не конкретный набор инструментов и процессов, которые можно перечислить в практическом руководстве. Если вы относитесь к Agile как к последнему, вы не стоите на правильном пути. Нельзя прийти в магазин и «купить немного Agile-менеджмента».

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

За последние годы члены SD Learning Consortium обменивались визитами, чтобы понять условия, необходимые для успешного внедрения Agile [51]. В каждом успешном кейсе мы обнаружили, что компания начинала с общих принципов и использовала опыт предшественников, а затем разрабатывала набор практик в соответствии с собственными потребностями (а порой и брендами) и корпоративной культурой. Хотя универсального рецепта успеха не существует, мы заметили поразительное сходство некоторых управленческих практик. Далее описаны главные характеристики.