Текст книги "Масштабированный скрам. Как организовать гибкую разработку в крупной компании"

Попробуйте… обеспечить многократное переиспользование информации и знаний с помощью наставничества, шаблонов проектирования, вики и других инструментов.

Шаблоны проектирования как в области программного, так и аппаратного обеспечения также позволяют эффективно задействовать наработанные знания – так что разрабатывайте и распространяйте такие шаблоны.

Командные комнаты и визуальное управление

В бережливой разработке рекомендуется использовать командные комнаты – достаточно большие помещения без внутренних перегородок, где трудится вся кросс-функциональная команда вместе с ее главным инженером[34]34
  В книге «Человеческий фактор» [DL99] авторы рекомендовали отдельные кабинеты для программистов, но для индивидуальной работы (вне команды). Позже авторы пересмотрели этот совет и теперь рекомендуют использовать «оперативные пункты»: «Я все больше прихожу к мысли, что проект, который не требует „оперативного пункта“, вообще не стоит того, чтобы за него браться» [DeMarco08]. Почему? Исследования показывают, что нахождение команды в одной комнате коррелирует с более высокой производительностью [TCKO00].


[Закрыть]. Стены комнаты покрыты большими дисплеями (магнитно-маркерными досками) с информацией о проекте и разработке, которые обеспечивают визуальное управление. Работа лицом к лицу в общей командной комнате – это противоположность тому, когда люди работают в отдельных кабинетах или кубиклах, создающих физические барьеры для коммуникации между членами команды (рис. 3.10).

Попробуйте… использовать командные комнаты для бережливой разработки.

Ведущий инженер-предприниматель с бизнес-контролем над продуктом

В большинстве крупных компаний существуют группы управления продуктами, которые определяют бизнес-цели и выбор функционала и обычно состоят из маркетологов и представителей других неинженерных специальностей. Toyota поступает иначе. В компании разработку продукта всегда возглавляет ведущий инженер с высочайшим уровнем технической компетентности, самыми современными знаниями и пониманием бизнеса, который также отвечает за коммерческую успешность нового продукта. Другими словами, в Toyota все аспекты управления разработкой продукта возложены на главного инженера, который прекрасно разбирается в рынке, управлении продуктами, в бизнес-модели (прибыльности и т. п.) и, разумеется, в технических вопросах[35]35
  Мы видели успешных менеджеров по продуктам, которые не были инженерами, однако все они обладали превосходными навыками управления продуктовой разработкой, а также глубоким знанием рынка, продукта и клиентов.


[Закрыть].

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

Параллельное проектирование на базе альтернатив

Вам доводилось встречать такой подход к разработке?

1. Выбрать один вариант решения или дизайна (один пользовательский интерфейс, одну архитектуру и т. д.).

2. Разработать его.

3. Осуществить поставку.

Попробуйте… параллельно разрабатывать несколько альтернативных вариантов продукта.

Параллельное проектирование на базе альтернатив (Set-Based Concurrent Engineering/SBCE) – это совершенно другой подход, который используется в Toyota. Например, вместо того чтобы проектировать один вариант системы охлаждения силами одной команды, несколько команд параллельно изучают ряд альтернативных вариантов (и то же самое делается для других компонентов). По мере исследования вариантов некоторые из них отбрасываются, некоторые комбинируются, в результате чего исходный набор вариантов постепенно уменьшается, пока не остается один наиболее перспективный. Таким образом, Toyota превосходит конкурентов в обучении путем увеличения числа альтернатив и комбинаций.

В разработке ПО шагом в этом направлении является исследование как минимум двух альтернатив для нетривиальных элементов архитектуры. Например, несколько лет назад мы работали с группой, которой нужно было создать обработчик для протокола печати JDF. Вместо того чтобы сразу организовать процесс одной командой (и с одной большой доской), мы разбили группу на две подкоманды и использовали две большие доски на противоположных стенах командной комнаты. На каждой доске подкоманды рисовали диаграммы UML[36]36
  UML (унифицированный язык моделирования) – графический язык для составления диаграмм.


[Закрыть]. Примерно каждые 45 минут они подходили к доскам друг друга, обменивались идеями и фиксировали их в диаграммах. В конце дня мы собрались всей группой, посмотрели на обе предполагаемые архитектуры (схематично изображенные на больших досках) и решили, какая из них наиболее перспективна. После этого группа приступила к ее реализации, черпая вдохновение в идеях, набросанных на доске.

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

■ двух-трех вариантов пользовательского интерфейса;

■ двух вариантов компонента, критичного для производительности системы и т. д.

Могут ли уроки бережливого производства быть использованы в разработке новых продуктов?

Разработка новых продуктов и НИОКР в целом кардинально отличаются от производства с его предсказуемостью и повторяемостью. Ошибочное предположение об их сходстве – одна из причин, объясняющих, почему производственные практики «экономии за счет масштаба», восходящие к началу 1900-х гг., по сути не к месту, используются в области исследований и разработки – например, в виде каскадной разработки с передачей больших объемов требований между этапами.

Тем не менее некоторые принципы и идеи, применяемые в бережливом производстве (включая короткие циклы, мелкие размеры партий, практику «остановись и исправь», визуальное управление и теорию массового обслуживания), можно и нужно применять в бережливой разработке продуктов. Почему? Дело в том, что современное бережливое производство существенно отличается от традиционного и, более того, во многом базируется на принципах (таких, как мелкие партии, обработка очередей, ограниченное время циклов), позаимствованных из теории массового обслуживания и других дисциплин, созданных для описания изменчивого поведения систем, которые скорее напоминают разработку нового продукта, чем традиционное производство.

Удивительно, но мы видели компании, где производственные инженеры произвели революцию и внедрили бережливый подход, перейдя от «экономии за счет масштаба» к гибко регулируемому потоку на основе небольших партий. Но эти уроки (которые как нельзя лучше подходят для разработки новых продуктов) были проигнорированы менеджерами по НИОКР, которые продолжали управлять исследованиями и разработкой устаревшими методами из области традиционного производства.

Несмотря на все вышесказанное, мы хотим предостеречь: разработка новых продуктов – это не производство и любое сходство между ними весьма условно. В отличие от производства, разработка новых продуктов сопряжена (как и открытие всего нового) с высокой степенью неопределенности, вариативности и непредсказуемости. Но это не только нормально, но и желательно; без этого невозможно создать ничего нового. Таким образом, бережливая разработка продуктов включает уникальные практики, которые могут быть дополнены и улучшены с помощью практик гибкой разработки и скрама.

Кейс: анализ канбан-системы

Как и в разделе «Системное мышление», мы сочли полезным дополнить содержание данной главы конкретным примером. Это детальное тематическое исследование не несет важной новой информации, поэтому вы можете его пропустить.

Мы проанализируем конкретную практику, известную как канбан-система, чтобы улучшить ваши навыки в распознавании бережливых и небережливых практик. Канабн-систему часто относят к бережливым практикам, как и все, что связано с лексиконом Toyota, но, как мы увидим дальше, это не так.

Одна из ошибок при внедрении бережливого подхода – полагать, что любая практика с японским названием является априори бережливой.

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

Несколько лет назад в разработке программного обеспечения стала продвигаться практика под названием «канбан-система» – метод визуального управления с использованием доски и ограниченного количества карточек с запросами на конкретные работы [Anderson07]. Обратите внимание, что это вовсе не то же самое, что концепция визуального управления канбан в вытягивающих системах.

Управление очередями – это не бережливый подход

Вот краткое описание анализируемой практики:

«Лимит для канбан-системы – 20 карточек [на стене], сгруппированных согласно разным этапам процесса, таким как системный анализ, разработка, тестирование, сборка/слияние, развертывание» [Anderson07].

Ограниченное количество карточек с запросами на работу на стене ограничивает размер очереди работ; то есть «канбан-система» нацелена на управление очередями. Но, как было сказано выше, управление очередями – это не практика бережливого подхода, а инструмент – вторичный по отношению к таким ключевым составляющим, как менеджеры-учителя с бережливым мышлением, непрерывное улучшение, принцип «пойди и посмотри» и кайдзен. То же самое относится и к доскам визуального управления.

Ограничение размера очереди запросов с помощью количества карточек – полезная, но не новая идея. Этот способ используется в экстремальном программировании [BF00], а также обсуждался в контексте бережливой разработки [Poppendieck03] и [Hirinabe07, Hirinabe08].

Параллельная разработка против последовательной: устранение очередей

Обратите внимание, что в этом конкретном варианте «канбан-системы» карточки на стене распределяются в соответствии с отдельными этапами разработки – поддерживают модель последовательной разработки с микрокаскадными этапами, такими как системный анализ, разработка, тестирование и т. д. Но что в этом такого?

В данном случае управление очередями используется как способ скорректировать (посредством ограничения размера очереди и работы в прогрессе WIP) традиционный последовательный взгляд на разработку, в основе которого лежит убеждение, что отдельные этапы – пусть даже короткие и следующие один за другим, подобно итерациям, – неизбежны и что очереди всегда будут существовать[37]37
  Разумеется, мы не говорим об абсолютном отсутствии этапности. Обычно существует как минимум два этапа – разработка и развертывание.


[Закрыть]. Но насколько это улучшает метод разработки в целом?

Если рассматривать практику «канбан-система» в свете концепций настоящего бережливого подхода, то это пример того, что в Toyota называют точечным кайдзеном – небольшим улучшением в рамках существующей системы или парадигмы. В нашем случае в рамках парадигмы последовательной разработки с неизбежными очередями. Другими словами, управление очередями – это второстепенная тактика из плана Б.

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

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

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

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

Вариативность и большие пакеты работ

Канбан-система также позволяет вводить в очередь пакеты работ разного объема:

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

Насколько это хорошая идея?

В бережливом подходе выравнивание (сглаживание) вариативности входящих элементов и уменьшение размера партий – ключевые принципы организации потока[38]38
  «Одно» большое требование в разработке ПО чаще всего представляет собой скрытый пакет, который можно разбить на элементы небольшого размера и обеспечить выравнивание потока работ.


[Закрыть].

Теория массового обслуживания показывает, что разрешение ввода варьирующихся элементов на входе в систему с несколькими этапами нежелательно, так как согласно закону распределения вариативности [HS08] вариабельность на входе (во входящих запросах) наиболее негативно влияет на среднее время цикла. Эта теория также объясняет, почему большой рабочий пакет – это плохо. Таким образом, налицо еще два слабых места данной практики.

Мощная альтернатива – разбивать входящие запросы на пользовательские истории одинакового небольшого размера, чтобы уменьшить рабочие пакеты и выровнять их объемы. В гибких методах разработки с каденцией (таких, как скрам) это делается по умолчанию благодаря жесткому правилу, что рабочие пакеты должны соответствовать коротким, строго ограниченным по времени циклам (тайм-боксам). Система на основе коротких регулярных тайм-боксов уменьшает вариативность общего характера в размерах входящих элементов, тогда как системы без таких временных ограничений (например, рассматриваемая нами практика «канбан-система»), наоборот, могут способствовать такому разбросу. Обратите внимание, что стратегия выравнивания рабочих пакетов может и должна использоваться независимо от типа используемой вами системы.

Кайдзен и обучение

В рассматриваемом нами примере также ставится в плюс, что канбан-система помогла уменьшить «накладные расходы»:

«Канбан-система избавила нас от управленческих накладных расходов, связанных с запуском каждой итерации как мини-проекта».

Но можно ли назвать это улучшением?

На первый взгляд, уменьшение потерь в виде накладных расходов – это всегда хорошо. Но действительно ли регулярные встречи самоуправляемых команд являются чистыми потерями или же они создают какую-то ценность?

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

Например, обзоры спринта и ретроспективы спринта в скраме обеспечивают регулярную, формальную и сфокусированную возможность для обучения и кайдзена для всех сторон, участвующих и заинтересованных в разработке продукта. Это не «накладные расходы», а события, задающие определенный ритм непрерывному обучению и улучшению. Регулярные кайдзен-встречи – общепринятая практика в Toyota, которая позволяет улучшать систему не только реактивно, в ответ на появление очевидных проблем, но и проактивно, действуя на опережение.

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

Каденция в обучении и непрерывном улучшении

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

Между тем есть нетривиальные причины, почему каденция (не только в поставке, но и во всем остальном) рассматривается в бережливой разработке как ключевой принцип и почему короткие тайм-боксы – которые задают этот ритм и используются в скраме, экстремальном программировании (XP) и методе разработки динамических систем (DSDM) – оказываются настолько популярными практиками. Да, в основанных на тайм-боксах системах есть свои слабые места, но эти недостатки перевешиваются мощными преимуществами, ведущими к улучшению более глубокой системной динамики. Это касается целого ряда упомянутых выше тонких факторов; в частности, позволяет уменьшить синдром студента, ограничить шлифовку, облегчить переход к параллельной разработке, устранить аналитический паралич, задать четкие рамки расплывчатым задачам, уменьшить вариативность (в пакетах работ и других элементах), создать регулярность в обучении, что стимулирует выход на совершенно новый уровень творческого мышления и улучшения системы.

Ресурсный пул против стабильных команд-долгожителей

В рассматриваемой практике предполагается привлечение людей из ресурсного пула по мере необходимости:

«Наш процесс поддержки ПО основан на плавающем доступе к пулу инженерных ресурсов; у нас нет специальных команд поддержки или сопровождения».

Но Toyota делает упор именно на стабильные долгоживущие команды в противовес ресурсному пулу [LM07]. Кроме того, исследования [Katz82] показывают, что такие команды в сфере исследований и разработки демонстрируют более высокую производительность по сравнению с временными группами людей, набранных из ресурсного пула.

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

Выводы

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

Кейс также проиллюстрировал следующие важные моменты:

■ Устранение очередей с помощью параллельной разработки и системного кайдзена – более мощная альтернатива, чем управление очередями.

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

■ Тайм-боксы с регулярными встречами задают каденцию (ритм) в обучении и кайдзене и значительно повышают их эффективность.

■ Toyota использует стабильные долгоживущие команды.

Заключение

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

Мы пришли к осознанию этого несколько лет назад благодаря нашему сотрудничеству с компанией Xerox, которая разрабатывает большие цифровые машины для высококачественной полноцветной печати со скоростью выше 110 страниц в минуту. Создание одного такого продукта требует много сотен инженеров и исследователей и десятки миллионов строк кода. Большие системы, большие группы. Некоторое время назад компания пригласила Крэга возглавить коучинг по бережливой разработке в области программно-интенсивных встраиваемых систем. Эта инициатива продолжалась несколько лет и позволила нам на практике убедиться в том, что бережливый подход применим к крупномасштабной разработке продуктов – и отлично сочетается со скрамом. Впоследствии Xerox также внедрила практики бережливой разработки в группы, занимавшиеся электромеханическими и оптическими системами. Таким образом, бережливый подход стал общим фреймворком и языком для разных инженерных групп – что наглядно показало свои преимущества.

Бережливый подход – намного больше, чем просто инструменты вроде канбана, визуального менеджмента или управления очередями, и это не только устранение потерь. Как можно увидеть на примере Toyota, это система организации всей жизнедеятельности компании, которая основана на вкладе бережливо мыслящих менеджеров-учителей и опирается на такие столпы, как уважение к людям и непрерывное улучшение. Ее успешное внедрение может занять годы и требовать широкомасштабного обучения и коучинга. Еще раз процитируем слова Фудзио Те, президента Toyota:

«Многие хорошие американские компании уважительно относятся к людям, применяют кайдзен и другие инструменты [бережливого подхода]. Но важно то, чтобы все эти элементы практиковались как система – изо дня в день, очень последовательно».