Бас Водде
Масштабированный скрам. Как организовать гибкую разработку в крупной компании
Попробуйте… сократить три источника потерь: вариативность, перегрузку и не добавляющие ценности действия.
Фокус на вариативности, перегрузке и не добавляющих ценности действиях – Вместе с НЦД в бережливом подходе Toyota выделяют три основных источника потерь, которые представлены вместе с вариантами их устранения на рис. 3.6.
Многие компании, которые пытаются внедрить бережливый подход, совершают ошибку, фокусируясь исключительно на устранении не добавляющих ценности действий [LM06a]. Между тем в Toyota всем трем источникам потерь придается равное значение и, как следствие, уделяется равное внимание. Более того, вариативность и перегрузка рассматриваются как типичные корневые причины, которые часто приводят к не добавляющим ценности действиям. Например, перегруженные работой программисты допускают больше дефектов.
Стремление к совершенству
Это третий элемент парадигмы непрерывного улучшения в бережливом подходе.
В ходе нашего посещения Toyota мы пригласили поужинать с нами в Нагое бывшего инженера компании, теперь – пенсионера. После нескольких чашечек саке мы спросили у него: «Чего не хватает вам после увольнения? По чему вы скучаете больше всего?» «По возможности поговорить с людьми о совершенстве», – ответил он.
Когда нас приглашают в организации, которые раздумывают над внедрением гибкого или бережливого фреймворка, кто-нибудь обязательно высказывается против и приводит следующий типичный аргумент: «Мы создаем продукты, зарабатываем неплохую прибыль, наши процессы проверены и устоялись. Зачем нам что-то менять?» Не думаем, что в Toyota можно услышать что-то подобное. Да, компания еще далека от совершенства, и мы не предлагаем слепо копировать все, что она делает. Но ее культура построена на менталитете кайдзен – высоко ставить планку ожиданий для себя, для своих людей и команд, а также партнеров в отношении мастерства, качества, скорости, сокращения потерь, видения и постоянно ее повышать, бросая вызов статус-кво.
Это очень мощно!
Бесконечный процесс
В 2001 г. Toyota подготовила внутренний манифест «Дао Toyota» с описанием своих принципов бережливого подхода. Но когда ее президент Акио Тоёда услышал название, он предложил переименовать документ в «Дао Toyota 2001». Почему? Чтобы подчеркнуть, что процесс в Toyota не имеет конца (что задушило бы кайдзен), а является непрерывным процессом изменений и улучшений.
Принципы кайдзен и йокотен (горизонтальное распространение знаний) предполагают отсутствие финализированного или регламентированного «правильного» процесса, который разрабатывается центральной группой и спускается сверху для обязательного применения на местах. Да, в кайдзене есть рабочие соглашения, которые люди должны знать и соблюдать, но они передаются и развиваются через систему горизонтального распространения знаний. Вот почему бережливый подход так трудно внедрить в организациях с традиционным менталитетом, «централизованно разработать (или купить) финализированный процесс, разослать его по всей организации и требовать его неукоснительного соблюдения». Позвольте нам еще раз процитировать слова генерального директора Toyota: «Основа дао Toyota – быть постоянно недовольным существующим положением дел, все время задавать вопрос "почему/зачем мы это делаем?"». Ценности бережливого и гибкого подходов – и, разумеется, скрама – основаны на идее эмпирического процесса: на понимании того, что невозможно создать фиксированный или финализированный процесс, книгу готовых рецептов, которым можно было бы следовать с учетом реальности динамически меняющихся систем и цели непрерывного улучшения. Вместо этого скрам предполагает упорную и неустанную работу в духе кайдзен – инспектировать текущие процессы в конце каждого двухнедельного спринта и планировать эксперименты по их улучшению на следующий двухнедельный спринт. В Toyota и в скраме этот цикл повторяется бесконечно.
14 принципов
Два столпа – уважение к людям и непрерывное улучшение – это не весь «дом» как в прямом, так и в переносном смысле. Существует еще целый ряд мощных принципов, которые все вместе образуют систему бережливого подхода и напрямую перекликаются с элементами из обеих «колонн».
Как отмечает Фудзио Тё, председатель Toyota:
«Многие хорошие американские компании уважительно относятся к людям, применяют кайдзен и другие инструменты [Toyota]. Но важно то, чтобы все эти элементы практиковались как система – изо дня в день, очень последовательно» [Liker04].
Попробуйте… применять 14 принципов бережливого подхода, такие как развитие лучших людей, «остановись и исправь», выравнивание и вытягивание.
Эта более обширная система частично охватывается 14 принципами, описанными в книге «Дао Toyota», которая основана на десятилетиях непосредственного наблюдения и бесед с людьми в Toyota. Мы кратко резюмировали эти принципы в таблице 3.1 и дальше рассмотрим некоторые из них более подробно.
Поток
Поток предполагает, что создание ценности для клиента происходит быстро и гладко, без задержек. В качестве контрпримера: запрос клиента ожидает в очереди, когда его утвердят, проанализируют, реализуют, переработают или протестируют. Это не поток. Поток – когда созданная ценность в виде продукта, функционала, информации, решения, услуги и т. п. поставляется клиенту незамедлительно. Это перекликается с метафорой «следить за эстафетной палочкой» и с концепцией ускорения перехода «от идеи к прибыли». Совершенный поток с нулевыми потерями в системе и немедленной непрерывной поставкой ценности клиенту – очень серьезный вызов, возможно, не достижимая на практике цель. Поэтому под «фокусом на потоке» мы подразумеваем постоянное движение в направлении этой цели.
В «доме бережливого подхода» (рис. 3.1) поток включен в 14 принципов, а также является одним из ключевых элементов непрерывного улучшения. Почему? Потому что налаживание потока требует уменьшения размера партий, времени циклов, задержек, НЗР и других потерь. Это, в свою очередь, ведет к положительному побочному эффекту – позволяет выявить ранее скрытые слабые места и потери, что дает новые возможности для непрерывного улучшения. Этот тонкий, но важный момент более подробно рассмотрен в разделе «Косвенные преимущества уменьшения размеров партий и времени циклов».
Налаживание потока является предметом прикладной теории массового обслуживания, вытягивающих систем и других моделей. В его основе лежат такие фундаментальные принципы, как уменьшение размера партий, сокращение очередей и снижение вариативности. Обо всем этом мы подробнее поговорим в главе «Теория массового обслуживания».
Вытягивающие системы
Вытягивание против выталкивания. Возьмем процесс производства ноутбуков. В чистой вытягивающей системе[26] ноутбуки производятся только при поступлении заказов от клиентов; ни один ноутбук не производится загодя и не хранится на складе. Любая работа выполняется лишь в ответ на «вытягивающий» сигнал от клиента, благодаря чему достигается идеальная цель – нулевые запасы и нулевые НЗР[27]. В этом суть системы вытягивания: вы получаете «сигнал» от клиента и выполняете работу; в остальное время отдыхаете или совершенствуете продукт/систему. Примеры вытягивающих систем – издание книг способом «печать по требованию», приготовление блюд в ресторане.
Но смысл вытягивающей системы гораздо глубже этого, потому что под «клиентом» здесь понимается не только конечный клиент. В многоэтапном процессе, где одна команда выполняет часть работы и передает ее другой команде, команда на следующем этапе является клиентом для команды на предшествующем этапе. В чисто вытягивающей системе команда на предшествующем этапе не делает никакой работы, пока следующая не подаст запрос.
В выталкивающей системе, наоборот, производитель заранее производит и создает запасы ноутбуков, а затем пытается продать (вытолкнуть) их клиентам. В многоэтапном процессе это означает, что предшествующие команды создают запасы частично сделанной работы для следующих команд. Накопление запасов любого вида – запасов пицц, книг, больших детализированных планов, спецификаций на множество функций сомнительной ценности – в надежде получить запросы клиентов присуще выталкивающим системам.
Стратегии управления ресурсами, которые фокусируются на высокий уровень использования сотрудников – на бегунах, а не на эстафетной палочке, – формируют среду, где люди неизбежно создают большие запасы всего (требований, продуктов, кода) в соответствии с выталкивающей моделью.
Выявление дефектов. Если вы создаете только один продукт в ответ на вытягивающий запрос от клиента (в нашем контексте вашим клиентом может быть любой, кто находится ниже вас по потоку) и клиент быстро его потребляет, любые дефекты в этом продукте – допущенные либо по случайности, либо по ошибке – быстро обнаруживаются. При наличии культуры «остановись и исправь» это может приводить к незамедлительному улучшению системы. Напротив, в выталкивающей системе дефекты скрываются в нереализованных запасах (требований, кода и т. д.). Например, выталкивание большого пакета требований отсрочит выявление скрытого в них неправильного понимания или других проблем, поскольку пройдет много времени, прежде чем они будут реализованы, а затем обнаружены клиентом, использующим ваш программный продукт.
Принимайте решения как можно позже. В вытягивающих системах вы принимаете решения не как можно раньше, а, наоборот, как можно позже, «в самый последний момент» [Poppendieck03, Smith07]. При таком подходе вы имеете возможность собрать максимум информации для принятия правильного решения. Вы не тратите ресурсы на создание ненужных запасов и не попадаете в ситуацию, когда преждевременно принятое решение оказывается неверным или неэффективным в свете новых вводных и вам приходится переделывать уже сделанную работу.
Уменьшение размеров партий может привести к радикальным улучшениям. В вытягивающих системах используются партии меньшего размера и частые короткие циклы. Когда задействованы старые процессы со свойственными им выталкиванием и крупными партиями (эти процессы основаны на не терпящей изменений традиционной модели экономии за счет масштаба), более короткие циклы могут увеличивать общие накладные расходы или операционные издержки и, следовательно, признаваться неэффективными. Выход из этого тупика – в радикальном улучшении процессов так, чтобы они позволяли эффективно работать с партиями небольшого размера и внедрять изменения в текущем режиме. Именно в этом кроется секрет эффективности Toyota: вытягивающие системы с небольшими партиями в сочетании с кайдзеном стимулируют поиск новых способов работы, которые снижают операционные издержки производственного цикла. Более подробно эта динамика улучшения будет рассмотрена в разделе «Косвенные преимущества уменьшения размеров партий и времени циклов».
Таким образом, вытягивающие системы во многих отношениях помогают наладить движение потока и поддерживать его.
Избегайте ложной дихотомии. Категорически заявлять, что вытягивание всегда хорошо, а выталкивание всегда плохо, – ложная дихотомия. Как правило, из-за наличия жестких ограничений (например, скорости транспортировки) создание некоторого объема запасов и некоторое выталкивание может быть полезной мерой – временно необходимой потерей. Toyota создает запасы автомобилей для отправки за границу, что иногда окупает себя, иногда нет. В скраме группа выталкивает небольшие запасы хорошо проанализированных, небольших, соразмерных друг другу требований в верхнюю часть бэклога продукта, чтобы уменьшить вариативность.
Как вытягивающие системы применимы к разработке ПО? Давайте сравним, например, вытягивающее и выталкивающее планирование:
■ При выталкивающем планировании создается большой и очень подробный предварительный план: детально описываются все требования и указываются сроки их выполнения; все задачи оцениваются, упорядочиваются и распределяются между сотрудниками и командами – с первого дня работы до момента поставки. Затем эти задачи выталкиваются разработчикам, от которых зачастую требуют соблюдения первоначального (чисто гипотетического) графика. Обратите внимание: выталкивающее планирование предполагает, что все требования будут тщательно проанализированы и подробно описаны до начала планирования (по крайней мере если план составляется не наобум), а это, в свою очередь, не предусматривает или существенно затрудняет последующее внесение корректировок (не говоря уже о более серьезных изменениях) в ответ на новые вводные.
■ При вытягивающем планировании или адаптивном итеративном планировании создается начальный бэклог продукта с высокоуровневыми требованиями или целями. В «самый последний момент» – в первый день новой итерации – владелец продукта выбирает список небольших целей для предстоящего спринта из чуть более расширенного списка элементов, которые были проанализированы и оценены по итогам одного-двух предыдущих спринтов. Получив этот вытягивающий сигнал от владельца продукта, команда решает, что она может реализовать и поставить в этой итерации. Обратите внимание, что, поскольку все решения принимаются в «самый последний момент», с максимумом доступной информации и самым свежим взглядом на постоянно меняющуюся ситуацию, они являются наиболее качественными. Принцип вытягивания также используется в планировании методом набегающей волны.
Остановись и исправь
Менеджеры-учителя в Toyota учат сотрудников, что при возникновении дефектов или проблем нужно обязательно остановиться. Вместо того чтобы пытаться найти хоть какое-то быстрое решение или же вовсе закрыть глаза на проблему, команда проводит кайдзен-встречу, доискивается до корневых причин, а затем предпринимает шаги по искоренению проблемы, которые в идеале не только предотвращают ее повторение, но и превращают слабое место во встроенное качество.
Например, Toyota известна своей практикой «останови конвейер», когда любой рабочий, обнаружив проблему, может «дернуть стоп-кран» и остановить работу всей сборочной линии. Это первый шаг в системе реагирования, нацеленной на встроенное качество. Еще одна практика: Toyota старается использовать дружественные человеку производственные устройства, которые сами обнаруживают неисправности, автоматически останавливаются и предупреждают людей о проблеме. Эта идея восходит еще к основателю компании Сакиси Тоёда, заработавшему первоначальный капитал благодаря изобретению ткацкого станка, который автоматически обнаруживал неполадку и останавливался [Hino06]. Эта практика бережливого подхода называется дзидока[28].
Гибкая разработка ПО с ее практикой непрерывной интеграции также базируется на менталитете «останови конвейер»: если сборка ломается (из-за сбоя на уровне компиляции, компоновки или тестирования), это считается малым кризисом; ответственные за сбой люди должны быстро выявить причину и устранить ее, сделав сборку рабочей. В ходе следующей ретроспективы спринта команда должна постараться выявить причины поломки сборки и затем экспериментальным путем найти способ улучшить процесс.
Простое визуальное управление
Toyota делает упор на простые и БОЛЬШИЕ визуальные инструменты, сообщающие о проблемах, коммуникации и координации вытягивающей системы. Это большие информационные доски на стенах, яркие заметные карточки с цветовой кодировкой и другие визуальные средства, которые люди могут перемещать, изменять и т. д. Ключевые требования – возможность видеть с дальнего расстояния, физические элементы (например, карточки), цвета и простота. Конечно, это полная противоположность тому, с чем мы имеем дело при разработке ПО с ее отображением множества мелких и детальных элементов информации на небольших компьютерных экранах; но экран с пятном красного цвета, сигнализирующим о сломанной сборке, – вполне в духе визуального менеджмента.
Попробуйте… использовать средства визуального управления.
Такие информационные радиаторы для визуального управления применимы в продуктовой разработке для отображения задач, статуса сборки и т. п.; впервые они получили широкое распространение в гибком методе XP в виде практики Больших наглядных схем (Big Visible Chart / BVC) [JAH00].
В главе «Теория массового обслуживания» мы подробнее поговорим об очередях и о том, почему для отображения очередей – особенно невидимых очередей – в процессе разработки необходимо использовать именно физические визуальные средства.
Обратите внимание: визуальное управление опирается именно на физические элементы или носители (а не на цифровые в компьютерной программе)[29]. Например, в скраме и других гибких методах принято записывать все задачи на следующий спринт на бумажных носителях (карточках задач), которые прикрепляются к «доске задач» на стене и перемещаются по мере их выполнения (рис. 3.7). Людям нужно видеть и чувствовать очереди, потому что на протяжении сотен тысяч лет эволюции мы привыкли иметь дело с материальными, осязаемыми вещами. Отображение задач только в цифровой форме на компьютере не позволяет задействовать это человеческое качество и значительно снижает эффективность визуального управления.
В Toyota для сигнализации о проблемах на производственной линии используется система андон с трехцветными индикаторами и табло. В гибкой разработке ПО для оповещения об ошибках также обычно используется красный цвет: когда при автоматической сборке (компиляции и тестировании) происходит сбой, световой индикатор или веб-страница становятся красными, чтобы привлечь внимание людей.
Канбан – один из видов визуального менеджмента для сигнализации о запросах на вытягивание в вытягивающей системе. Давайте рассмотрим самый простой пример – магазин, продающий товары с полок, например пироги. За каждым пирогом на полке стоит ярко-оранжевая карточка с надписью «Один пирог» – это так называемый канбан изъятия (withdrawal kanban). Когда покупатель берет с полки пирог, продавец видит канбан изъятия и передает его в пекарню, чтобы получить еще один пирог и пополнить опустевшую полку. Это возможно благодаря тому, что у пекарни в запасе имеется один пирог, испеченный в ожидании вытягивающего сигнала.
Вместе с канбаном изъятия в пекарню одновременно отправляется канбан заказа (creation kanban) на выпечку еще одного пирога. Таким образом, магазин «вытягивает» по одному пирогу, вместо того чтобы заказывать сразу много пирогов и «выталкивать» их покупателям.
Разумеется, разработка ПО – это не производственный процесс наподобие выпечки пирогов, и при параллельной разработке с использованием кросс-функциональных команд и практически отсутствием передачи партий от процесса к процессу такие вытягивающие сигналы, как канбаны изъятия и заказа, не нужны. Тем не менее термины «канбан-карточки» и «канбан-доски» в среде гибкой разработки прижились, хотя и приобрели несколько другое значение [Poppendieck03, Hirinabe08]. На канбан-карточках указываются задачи или требования, которые должны быть реализованы в ходе спринта. Эти карточки размещаются на канбан-доске – большой доске задач на стене (рис. 3.7). Эта практика визуального управления также изначально родилась в экстремальном программировании [Beck99], а терминология бережливого подхода была наложена на нее уже позже.
Самоорганизация работы – одна из ключевых тем в исследованиях командной эффективности. Обратите внимание, что визуальное управление способствует самоорганизации, потому что люди могут легко видеть текущую ситуацию и координировать свои действия. Кроме того, канбан-карточки, такие как «испечь один пирог» или «изменить стиль веб-страницы», просты и понятны и не требуют дополнительных пояснений.
Бережливая разработка продуктов
Два столпа и 14 принципов – основа бережливого подхода. Но бережливая разработка включает еще ряд важных принципов и практик, которые позволяют превзойти конкурентов в обучении.
Люди в Toyota славятся своим мастерством в двух ключевых процессах: 1) производстве и 2) разработке новых продуктов. Исследователи из Мичиганского университета несколько лет изучали эффективность разработки продуктов в Toyota и североамериканских компаниях [LM06]. И что же они обнаружили?
Попробуйте… превзойти конкурентов в обучении.
Например, на создание пресс-формы[30] – от идеи до запуска в производство – у инженеров Toyota уходило в среднем пять месяцев, а у их североамериканских конкурентов – 12. И это при сохранении самого низкого соотношения НИОКР к продажам среди всех крупнейших автомобильных компаний в мире. Очень эффективный процесс разработки, согласитесь.
Как они это делают? В чем секрет бережливой разработки продуктов? Ответ:
в способности превосходить конкурентов в обучении[31].
Например, когда Toyota разработала гибридный автомобиль Prius, что она создала?
■ Конструкцию автомобиля (и встроенное программное обеспечение).
■ Знания или информацию – о клиентах, экспериментах, альтернативах и т. д.
Бережливая разработка фокусируется на создании более полезных знаний и на более эффективном обучении, чем конкуренты. А также на более эффективном использовании этих знаний и их сохранении. (Другими словами, вы должны учиться лучше своих конкурентов и не разбазаривать плоды своих усилий, забывая то, чему научились.) На рис. 3.8 и 3.9 проиллюстрированы некоторые практики бережливой разработки; часть из них подробнее рассматривается дальше.
Попробуйте… использовать инженеров-практиков с большим опытом работы (в вашей компании).
Экономически эффективное обучение
Не все новые знания и сведения одинаково ценны; в идеале, нужно стремиться получать самую полезную информацию самым дешевым способом [Reinertsen97]. Это не так просто, потому что в любом исследовательском процессе вы иногда открываете что-то новое, а иногда – нет.
Попробуйте… увеличить ценность информации и снизить ее стоимость.
Основная стратегия бережливого (и гибкого) подхода базируется на простом принципе, позаимствованном из теории информации: увеличивать ценность создаваемой информации/знаний и одновременно уменьшать стоимость их создания.
Информация с высокой ценностью. Вот несколько полезных идей касательно бережливой и гибкой разработки:
■ Сосредоточьтесь на неясных моментах. В скраме один из принципов приоритизации состоит в том, чтобы в первую очередь реализовывать и тестировать элементы с наибольшей степенью неопределенности или риска. Ценность обратной связи резко возрастает как раз из-за непредсказуемости результатов, потому что на предсказуемых экспериментах многому не научишься.
■ Фокусируйтесь на раннем тестировании и обратной связи. Задержка информации имеет реальную стоимость, что частично объясняет, почему тестирование только в конце длинного последовательного цикла (движимое заблуждением, будто такая локальная оптимизация уменьшает затраты на тестирование) – почти всегда очень плохой подход. Согласитесь, после 18 месяцев разработки крайне затратно обнаружить в ходе стресс-тестирования производительности, что ключевое архитектурное решение оказалось ненадежным. В бережливом подходе (и в скраме) используются короткие циклы с ранней обратной связью, что вместе с акцентом на первоочередной реализации и тестировании наименее предсказуемых элементов значительно снижает стоимость задержки информации[32].
Снижение стоимости информации. В разделе «Косвенные преимущества уменьшения размеров партий и времени циклов» рассматривается, как внедрение принципов бережливой и гибкой разработки приводит к уменьшению накладных (непроизводительных) расходов в процессах. Другими словами, эти методы фактически снижают стоимость изменений – и позволяют вам конкурировать за счет гибкости. И это включает снижение стоимости обучения. Вот несколько советов:
■ Сосредоточьтесь на широкомасштабной автоматизации тестирования – чтобы узнавать о дефектах и реальном поведении разрабатываемого продукта. Первоначальные затраты на внедрение могут быть значительными (если прежде вы тестировали только вручную), но последующие затраты на использование практически равны нулю.
■ Используйте непрерывную интеграцию – чтобы узнавать о дефектах и недостаточной синхронизации. Частая интеграция небольших партий кода позволяет снизить средние накладные расходы благодаря нелинейной зависимости результата от усилий при интеграции бо́льших объемов кода.
■ Фокусируйтесь на наставничестве, осуществляемом экспертами, и распространении знаний – чтобы сократить издержки на «изобретение велосипеда».
Каденция
Работа в регулярном темпе является важным принципом бережливого подхода как в производстве, так и в разработке [Ward06]. Это стабильное, ритмичное «сердцебиение» в бережливом производстве называется временем такта[33], а в бережливой разработке – каденциями. В скраме аналогом каденции является практика регулярных двух- или четырехнедельных циклов разработки (с регулярной поставкой результатов и регулярными встречами). Каденция очень мощный принцип, поэтому эту тему стоит рассмотреть более подробно.
Попробуйте… использовать регулярный ритм (тайм-боксы) в организации разработки.
В каденции есть что-то очень человечное и фундаментальное: людям нужны и важны определенные ритмы в работе и жизни – а также некие ритуалы в рамках этих ритмов [Kerth01]. Пример – работа с понедельника по пятницу с обязательными ритуалами вроде еженедельного собрания по вторникам утром и т. п. Проще говоря, каденция в работе улучшает предсказуемость, планирование и координацию. На более глубинном уровне это отражает фундаментальную ритмичность нашей жизни.
После внедрения масштабированного скрама в больших группах (где до этого использовались длительные, неограниченные по времени рабочие циклы без регулярных встреч) люди часто говорят нам: «Короткие спринты – самая полезная вещь, которую только можно придумать!» Это показывает, насколько высоко люди ценят каденцию.
Возьмем большую группу, которая не использует скрам с его регулярными короткими циклами и теоретически может поставлять работающую протестированную систему в любой день в любое время. Также предположим, что группе нужно проводить встречи по планированию и координации (потому что она состоит из нескольких команд), а также общие ретроспективы. У нее есть два варианта: 1) организовывать эти мероприятия когда придется или 2) проводить их через регулярные интервалы времени. Скорее всего, второй вариант будет гораздо эффективнее.
Каденция и тайм-боксы
Благодаря скраму создается очень четкий ритм: строго ограниченные по времени двух- или четырехнедельные циклы, называемые тайм-боксами. Тайм-боксы – это не панацея от всех проблем продуктовой разработки, но они имеют ряд важных преимуществ:
■ Тайм-боксы способствуют каденции.
■ В небольшой группе, разрабатывающей небольшие продукты с минимальными требованиями (например, многие веб-приложения), двух- или четырехнедельный тайм-бокс будет восприниматься как шаг назад: «Вы хотите, чтобы мы поставляли работающую систему раз в четыре недели? Да мы делаем это еженедельно!» Но возьмем группу из 300 человек, которая привыкла работать с крупными требованиями, реализация которых занимает по 18 месяцев, и выпускать продукт – встраиваемую систему с площадками в Сан-Паулу, Оксфорде и Варшаве – раз в три года. Для такой группы предложение «перейти к непрерывной реализации микротребований с непрерывной интеграцией и тестированием системы, чтобы продукт был всегда готов к поставке» – небо и земля по сравнению с привычным режимом работы. В этом контексте новый режим «поставлять работающую систему ровно каждые четыре недели» представляет собой привлекательное и достижимое улучшение и вводит в систему каденцию, которой ей так не хватало.
■ Исследовательская или разработческая деятельность часто имеет расплывчатые или слабо ограниченные рамки. Когда команда знает, что ей нужно поставить работающую функциональность через две недели к 15 марта, это задает четкие рамки, ограничивает объемы работы и усиливает фокус. По словам одной компании – разработчика игр, внедрение скрама помогло ей «вогнать» своих разработчиков игрового арта в рамки тайм-боксов, что принесло немедленные и значительные выгоды [Keith08]. Таким образом:
○ тайм-боксы (строго ограниченные по времени циклы) не дают расползаться объемам работ, ограничивают шлифовку и усиливают фокус, что является одной из ценностей скрама.
■ Тайм-боксы помогают бороться с аналитическим параличом.
■ Представьте, что вы студент, которому нужно подготовить доклад к понедельнику. Когда вы начнете? Большинство скажут: «Ближе к понедельнику». Это называется студенческим синдромом [Goldratt97], и тайм-боксы являются эффективным противовесом им.
■ Когда команде нужно поставлять готовый инкремент продукта строго каждые две недели, это со всей болезненной очевидностью выводит на поверхность все источники потерь и неэффективность текущих методов работы. Например, становится очевидно, что параллельная разработка (в сравнении с последовательной) позволяет быстрее создавать и поставлять ценность, ускоряет петли обратной связи и имеет другие преимущества – и работа в режиме тайм-боксов создает ту самую движущую силу, которая помогает перейти к параллельной разработке с использованием кросс-функциональных фича-команд.
■ При крупномасштабной разработке с участием нескольких команд время от времени требуется осуществлять межкомандное планирование. Встречи по планированию спринта в первый день каждого цикла (тайм-бокса) упрощают координацию.
■ Тайм-боксы упрощают планирование рабочего графика, позволяя заранее составить расписание таких предсказуемых событий, как встречи по планированию спринта и ретроспективы. Это особенно полезно для владельцев продуктов, которым приходится проводить множество встреч: теперь они могут составить свое рабочее расписание на несколько недель вперед.
■ Люди, кажется, больше чувствительны к вариативности во времени, чем в объеме работ, – «Вы задержали поставку» вызывает более негативную реакцию, чем «Вы сделали меньше, чем я ожидал». Тайм-боксы позволяют избежать такой ситуации, когда разработчики теряют доверие заинтересованных сторон, в очередной раз говоря: «Нам нужна еще неделя, чтобы все доделать».
Многократное переиспользование информации
Чтобы обеспечить многократное переиспользование информации и знаний, необходимо развивать устойчивую культуру наставничества со стороны менеджеров-учителей и опытных инженеров. Еще один способ – использовать простые инструменты распространения информации. Как показывает наш опыт коучинга, самый эффективный и «липкий» инструмент – это вики, современная гипертекстовая модель в духе Web 2.0, которая намного превосходит старые инструменты на основе отдельных документов.