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

Рекомендуемая литература

■ «Дао Toyota» Джеффри Лайкера (М.: Теории от практиков, 2022) – доскональное, основанное на фактах описание системы Toyota от исследователя, который несколько десятилетий изучал ее подходы и практики.

■ «Заглянуть в мышление Toyota» (Inside the Mind of Toyota) профессора Сатоси Хино. Хино много лет занимался разработкой продуктов, прежде чем заняться наукой, и «потратил более 20 лет на исследование темы, обозначенной в названии этой книги». В книге на основе реальных данных рассматривается эволюция и принципы оригинальной системы бережливого подхода.

■ «Экстремальная Toyota: Парадоксы успеха японского менеджмента» Эми Осоно, Хиротака Такеути и Норихико Симидзу (М.: Альпина Паблишер, 2022) – глубокий и скрупулезный анализ ценностей, противоречий и культуры дао Toyota. В основе этого анализа – шесть лет исследований и 220 интервью, включая глубокое исследование стабильной эффективности деятельности компании. Хиротака Такеути был одним из авторов знаменитой статьи «Разработка новых продуктов: Новые правила игры», опубликованной в Harvard Business Review в 1986 г., где были впервые представлены ключевые идеи скрама.

■ «Бережливая разработка продуктов и процессов» (Lean Product and Process Development) Аллена Уорда и «Система разработки продукции в Toyota: Люди, процессы, технология» Лайкера и Моргана (М.: Альпина Паблишер, 2022) полезны для понимания разработки продуктов с точки зрения бережливого подхода.

■ «Корпоративная культура Toyota: Уроки для других компаний» Джеффри Лайкера и Майкла Хосеуса (М.: Альпина Паблишер, 2020). Хосеус, который работал директором завода и менеджером по персоналу на заводе Toyota в Кентукки, привносит в книгу глубокое инсайдерское понимание того, что является бьющимся сердцем бережливого предприятия.

■ «Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании» д-ра Джеймса Вумека и Дэниела Джонса (М.: Альпина Паблишер, 2022) – увлекательный и прекрасно написанный обзор некоторых принципов бережливого подхода авторами, которые хорошо знают свой предмет. Как уже отмечалось выше, книга построена на отдельных, не сведенных в систему выборочных примерах, что может создать у неосведомленного читателя ложное впечатление, будто ключом бережливого подхода является уменьшение потерь, а не культура менеджеров-учителей, которые помогают выстроить два столпа – уважение к людям и непрерывное улучшение – с помощью принципа «пойди и посмотри» и других поведенческих моделей.

■ «Машина, которая изменила мир» Джеймса Вумека, Дэниела Джонса и Дэниела Руса (Минск: Попурри, 2007). Книга основана на пятилетнем исследовании системы Toyota и бережливого подхода, осуществленном исследователями из Массачусетского технологического института.

■ «Менеджмент в рабочей среде» (Workplace Management) Тайити Оно – небольшая книга от создателя производственной системы Toyota (TPS). В ней автор почти не рассказывает о TPS, но в серии коротких глав излагает свои взгляды на системы управления и бережливый подход.

■ Работы Мэри и Тома Поппендик «Бережливое производство программного обеспечения: От идеи до прибыли» (М.: Вильямс, 2010) и «Реализация бережливой разработки программного обеспечения» (Implementing Lean Software Development) – хорошо написанные книги, в которых проводятся важные параллели между бережливым подходом, системным мышлением и гибкой разработкой.

Глава 4
Теория массового обслуживания

Радость инженера – это найти прямую линию на двойном логарифмическом графике.

Томас Кениг

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

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

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

Lotus 1–2–3? – Некоторые читатели наверняка даже не слышали о программе электронных таблиц Lotus 1–2–3, но когда-то она лидировала на рынке электронных таблиц. Затем Borland и Microsoft вывели на рынок свои продукты с лучшей графикой. Компания Lotus отреагировала на это, запустив свои медленные циклы разработки, и три года спустя ее конкуренты захватили 52 % рынка стоимостью около $500 млн. Lotus и ее программа почили с миром [Meyer93].

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

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

Итак, поговорим о длительности циклов.

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

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

Из каких циклов состоит процесс разработки продуктов? Вот некоторые из них:

● один релиз «от идеи до денег»;

● одна фича «от идеи до готовности»;

● создание потенциально готового к поставке инкремента продукта (как часто вы можете поставлять?);

● интеграция (включая полное тестирование интегрированного продукта);

● компиляция (всего программного продукта);

● от «пилотного продукта» до поставки;

● развертывание для тестирования (на интегрируемом оборудовании);

● анализ и проектирование.

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

Попробуйте… использовать высокоуровневые КПЭ, отражающие длительность циклов.

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

Подумайте: что, если бы вы могли поставлять в два или даже в четыре раза быстрее, чем сейчас, в устойчивом темпе без перегрузки людей? И в то же время какова для вас стоимость задержки?

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

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

Экономическая модель, учитывающая длительность циклов. Как оценить компромисс между более короткими циклами и операционными издержками? Использовать экономическую модель продукта, которая включает такой фактор, как длительность циклов [SR98]. Предположим, что вы могли бы поставить продукт на полгода раньше. Как это отразится на предполагаемой прибыли за весь жизненный цикл продукта, а также на операционных издержках (таких, как затраты на тестирование)? Если это принесет вам $20 млн дополнительной прибыли при увеличении затрат на тестирование на 40 %, то есть на $1,3 млн, эти затраты окупятся с лихвой. Обратной стороной является стоимость задержки. Одно исследование показало, что при задержке вывода продукта на рынок на полгода теряется в среднем 33 % от общей прибыли [Reinertsen83]. Тем не менее многие группы разработки, с которыми мы начинали работать, не рассматривали фактор длительности циклов всерьез и не учитывали его в своих экономических моделях жизненных циклов продуктов.

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

Управление очередями. Существует множество способов уменьшить длительность циклов; бережливый и гибкий подходы – мощный источник таких практик. В этой главе мы рассмотрим один из таких инструментов – управление очередями.

Управление очередями для сокращения длительности циклов

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

бизнес-подразделения, которые приняли этот подход [управление очередями в управлении разработкой и портфелем продуктов], уменьшили среднее время разработки на 30‒50 % [AMNS96].

Очереди в разработке продуктов и управлении портфелем

Примеры очередей в разработке продуктов и управлении портфелем:

● продукты или проекты в портфеле;

● новые фичи одного продукта;

● детальные спецификации требований, ожидающих проектирования;

● проектная документация, ожидающая разработки;

● код, ожидающий тестирования;

● код одного разработчика, ожидающий интеграции с кодом других разработчиков;

● большие компоненты, ожидающие интеграции;

● большие компоненты и системы, ожидающие тестирования.

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

Вдобавок к очередям НЗР есть еще очереди на ограниченные ресурсы или на ресурсы общего пользования, такие как очередь заявок на использование дорогостоящей тестовой лаборатории или оборудования для тестирования.

Очереди – это проблема

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

Очереди НЗР. Очереди НЗР в разработке редко рассматриваются как таковые по ряду причин; возможно, главная из них в том, что они незаметны: набор битов на компьютерном диске. Но эти очереди реально существуют – и, что гораздо важнее, они создают реальные проблемы. Почему?[39]39
  Основанный на данных анализ очередей в разработке продуктов и советы, что с ними делать, смотрите в книгах, указанных в разделе «Рекомендуемая литература».


[Закрыть]

■ Очереди НЗР (как и большинство других очередей) увеличивают среднюю длительность цикла и замедляют поставку ценности, таким образом уменьшая общую прибыль за жизненный цикл продукта.

■ В бережливом подходе очереди НЗР классифицируются как потери, которые нужно устранять или сокращать, потому что:

○ очереди НЗР оказывают вышеуказанное влияние на время цикла;

○ очереди НЗР являются запасами (спецификаций, кода, документации и т. д.), в которые вложены время и деньги, но которые лежат мертвым грузом, не принося отдачи на инвестиции;

○ Как и все запасы, очереди НЗР скрывают дефекты и способствуют их распространению, потому что эти запасы – например, большие объемы неинтегрированного кода – не «потребляются» и не тестируются клиентами, которые находятся ниже по потоку, и, следовательно, скрытые в них дефекты не выявляются и не исправляются;

○ Пример из жизни: одна продуктовая группа, использующая традиционный подход к разработке, почти год работала над «убойной» функциональностью. Но затем руководство проекта решило от нее отказаться, потому что она угрожала сорвать сроки релиза, да и рыночные условия изменились. Перестройка заняла много недель. Как общее правило, очереди НЗР негативно влияют на способность реагировать на изменения и на стоимость этого реагирования, так как: 1) на незавершенную работу были потрачены время и деньги, которые не приносят отдачи; 2) незавершенный элемент может быть тесно переплетен с другой функциональностью, и отказ от него может потребовать значительных дополнительных усилий или 3) работа над новой функциональностью может быть отложена из-за большого объема текущей НЗР.

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

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

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

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

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

План А по управлению очередями состоит в том, чтобы ликвидировать очереди полностью, раз и навсегда, изменив саму систему: ее организацию, инструменты и т. д.

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

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

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

Избегайте… ложной ликвидации очередей за счет повышения многозадачности или увеличения загрузки людей

Предположим, пока вы работаете над пакетом А, у вас накапливается очередь из пакетов Б, В, Г и Д. Ложная ликвидация очереди – когда вы решаете работать над всеми пакетами одновременно, с высоким уровнем многозадачности и перегрузки. Многозадачность квалифицируется в бережливом подходе как источник потерь, потому что, как мы вскоре увидим, она ведет к увеличению средней длительности цикла, а не его уменьшению (и теория массового обслуживания объясняет почему).

Таким образом, повышать многозадачность[40]40
  Браться одновременно за две задачи может быть уместно в тех случаях, когда работа над одной из задач может быть остановлена по независящим от вас причинам и у вас нет возможности улучшить систему, чтобы устранить это ограничение.


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

Какие очереди могут сохраниться после системной перестройки?

Традиционные очереди НЗР могут быть ликвидированы переходом на скрам с кросс-функциональными фича-командами и внедрением метода разработки через приемочное тестирование (ATDD). Окончательно и бесповоротно. Но даже после реализации плана А – изменения самой системы – некоторые очереди все равно сохранятся:

■ очереди на общие ресурсы, такие как тестовая лаборатория;

■ очередь запросов на новую функциональность в бэклоге продукта;

■ очереди НЗР, потому что: 1) план А еще не реализован в полной мере (глубокие изменения в больших группах требуют времени) или 2) инструменты и техники, такие как переход от ручного к полностью автоматизированному тестированию, пока используются слабо (их освоение также требует времени).

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

Попробуйте… использовать небольшие партии одинакового размера

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

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

Как все это конкретно применяется в скраме? Об этом мы поговорим чуть позже, а сначала нам необходимо разобраться с основами теории массового обслуживания.