Раздел 3 (главы 6–15) описывает механизмы внедрения канбан-системы, заканчиваясь главой 15, где говорится о том, как выступить с инициативой перехода на Канбан. Инициация перехода требует договоренности с различными внешними заинтересованными лицами, а не только с клиентами, типичными для компаний по разработке и их партнеров. Например, эта новая договоренность предполагает обязательство по регулярной выдаче работающего продукта.

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

В кругах, близких к гибкой разработке ПО, устоялось мнение о важности регулярной каденции. В agile-методах разработки она достигается благодаря сгруппированным по времени итерациям длиной от одной до четырех недель. Необходимость таймбоксинга (ограничения по времени) основана на том, что для проекта очень важен устойчивый ритм, а для этого нужно применять строго ограниченные по времени итерации. В начале каждой итерации определяется объем работ (бэклог итерации) и обязательства по их выполнению. Все приходит в действие! Проводятся анализ, планирование тестов, проектирование, разработка, тестирование и рефакторинг. Если все идет по плану, то запланированная работа делается в полном объеме. Итерация заканчивается предоставлением работающего продукта и ретроспективным собранием, на котором обсуждаются возможности будущих усовершенствований и модификаций процесса. Затем цикл повторяется с четко заранее оговоренной частотой – еженедельно, раз в две недели, ежемесячно и т. д.

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

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

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

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

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

Координация любого программного релиза связана с затратами. Необходимо собрать людей для обсуждения выпуска, производства, упаковки, маркетинга, работы с потенциальными клиентами, документации, подготовки конечных пользователей, дилеров, отдела справок и службы технической поддержки, документации и процедур по установке, дежурных сотрудников, расписания выпуска и т. д. Планирование поставки элемента работающей программы бывает невероятно сложным – все зависит от отрасли бизнеса и типа программы. Обновление сайта, например, может оказаться тривиальной задачей по сравнению с обновлением прошивки военного оборудования, используемого по всему миру, спутников на орбите, боевого самолета или узлов телефонной сети. В 2002 году, когда мы планировали релиз обновления PCS Vision для американской сети сотовых телефонов Sprint PCS, требовалось обучить десятки тысяч людей. Нужно было объяснить 17 тысячам продавцов по всей стране, как работают около 15 новых телефонов, выводимых на рынок. Примерно такому же количеству человек предстояло объяснить, как отвечать на неизбежные звонки в службу техподдержки, которые обязательно последуют, когда неопытные клиенты приобретут свои новые устройства. Одно только планирование обучения 30 тысяч человек обходится недешево.

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

• Сколько совещаний?

• Сколько людей?

• Сколько времени это займет?

• Каков будет ущерб в результате отрыва людей от их основной работы?

В случае с физически существующими товарами легко представить себе операционные расходы. Первый из них – платеж. Клиент платит поставщику, используя некое платежное средство, например кредитную карточку. За удовольствие получить платеж по кредитной карте ведущие компании в этой сфере, например MasterCard и Visa, взимают с продавца операционные расходы, обычно составляющие 2–4 % от стоимости сделки.

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

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

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

В разработке ПО операционные расходы на поставку программ тоже могут быть по своей природе физическими.

Так, некоторые фирмы, например Microsoft, продолжают производить «окончательные версии для промышленной эксплуатации» (RTM) и выпускают физические носители – DVD, упаковывают их и рассылают распространителям, розничным операторам и другим партнерам. Если ПО – часть встроенной системы, то необходимой может оказаться поставка чипов или, по крайней мере, запись программного кода в прошивку при помощи таких технологий, как EE-PROM. Чипы после этого, вероятнее всего, придется вмонтировать в оборудование, которое они призваны контролировать.

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

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

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

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

Итак, первый вариант – модель на основе затрат. Мы должны учесть общие расходы между релизами. Часто их величина известна – это среднемесячные затраты организации. Если мы выпускаем релиз каждый месяц и ежемесячные затраты составляют 1,3 миллиона долларов, то наши расходы равняются минимум 1,3 миллиона долларов на релиз. В координационные издержки могут быть также включены расходы на физическое производство, печать, рекламу и накладные. Все это легко подсчитать. Предположим, они равняются 200 тысячам долларов. Итак, общая стоимость релиза составляет полтора миллиона.

Мы знаем, что дополнительные накладные расходы на релиз равны 200 тысячам, но какая часть из 1,3 миллиона потрачена на планирование, координацию и поставку продукта? Если у нас есть подходящие данные по учету рабочего времени, то можно посчитать и это. Но даже если их нет, мы все-таки способны сделать близкое к истине предположение. Сколько совещаний, людей? Как долго длились совещания? Включите сюда и число человеко-часов, потраченных на сдачу продукта. Умножьте на часовую ставку. Если результат составил около 300 тысяч долларов, то мы получили величину операционных и координационных издержек релиза на полмиллиона.

Эффективность релиза в процентах = 100 % × (общие затраты – (координационные затраты + операционные затраты)) / общая стоимость программного релиза.

В нашем примере эффективность равна

100 % × (1 500 000 – 500 000) / 1 500 000 = 66,7 %.

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

Какая эффективность считается достаточной?

Этот вопрос остается открытым. У всех компаний свои взгляды на достаточные показатели эффективности, и многое зависит от создаваемой ценности.

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

Эффективность релиза в процентах = 100 % × (1 – ((операционные затраты + координационные затраты) / (прибыль + операционные затраты + координационные затраты))).

В нашем примере показатель эффективности составит

100 % × (1 (500 000 / (500 000 + 500 000))) = 50 %.

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

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

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

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

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

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

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

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

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

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

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

Такая почти непрерывная выдача кода полезна для некоторых отраслей. Примеры, известные мне от ранних последователей Канбана, в основном связаны с медиаиндустрией: это, в частности, IPC Media в Лондоне, где используются многочисленные канбан-системы для планирования разработок онлайн-медиа, например , невероятно популярной онлайн-игры.

Снижение координационных и операционных затрат – признак высокой зрелости организаций. Это относится и к ранним последователям Канбана. Так, XIT-отдел Microsoft сотрудничал с поставщиком из Индии, обладающим пятым уровнем по шкале зрелости организаций, и Microsoft IT из Редмонда, находившимся примерно на третьем уровне. В зрелых организациях высок уровень доверия между членами цепочки создания ценности и внешними заинтересованными лицами, в том числе высшим руководством, поэтому для создания такого доверия не требуется разработки регулярной каденции релизов.

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

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

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

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

• Каденция поставки – это оговоренный заранее регулярный интервал между поставками работающего оборудования.

• Канбан отделяет каденцию поставки как от времени выполнения, так и от каденции пополнения.

• Короткие, ограниченные во времени итерации привели некоторые команды, желающие усвоить agile-методы, к печальным результатам.

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

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

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

• Каденцию поставки можно установить, сравнив стоимость поставки с общей суммой выручки от него.

• Эффективность и каденцию можно увеличить, сосредоточившись на сокращении операционных и координационных расходов.

• Регулярные поставки порождают доверие.

• Задавая ожидания регулярных поставок и постоянно их оправдывая, вы формируете привычку.

• Планирование регулярных поставок снижает координационные издержки.

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

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