Поэтому у команд возникают сложности при написании коротких пользовательских историй, которые можно уложить в небольшие, ограниченные по времени итерации. Это привело к ряду функциональных нарушений. Первое из них – отказ от сокращения итераций и возвращение к более долгим. Альтернатива – написание таких пользовательских историй, которые сосредоточены на элементах архитектуры или какой-то технической декомпозиции требований. Так появляются, например, отдельные истории для пользовательского интерфейса, уровня хранения данных и т. д. Еще одна альтернатива – разбить историю по трем итерациям на фазы, когда первая итерация предполагает анализ и, возможно, планирование тестов, вторая – разработку кода, а третья связана с системным тестированием и отладкой. Встречаются либо одна из этих альтернатив, либо сразу обе. При этом они не имеют ничего общего с ограниченными по времени итерациями и лишь маскируют тот факт, что работа продолжается, хотя о ней уже отчитались как о законченной.
Канбан отделяет время реализации пользовательских историй от темпов их поставки. Когда какая-то часть работы завершена и готова к сдаче, над другими элементами еще нужно работать. Отделив время разработки от каденции поставки, мы можем спросить и о том, как часто должна проходить расстановка приоритетов (а также планирование и оценка). Трудно поверить, что обсуждения планирования, оценки и расстановки приоритетов должны проводиться с той же частотой, что и разработка и сдача программ. Это совершенно непохожие функции, часто требующие внимания разных групп людей. Координационная деятельность по сдаче работы определенно отличается от координационной деятельности по расстановке приоритетов для новой работы. Канбан позволяет распараллелить эти виды деятельности.
Канбан также отделяет каденцию расстановки приоритетов от общего времени выполнения по всей системе и от каденции сдачи работы. В этой главе говорится об элементах, связанных с договоренностью о подходящей каденции поставки, и о том, когда поставка может происходить согласно запросу или сложившейся ситуации, а не регулярному расписанию (если оно вообще возможно). В соответствии с теми же принципами глава 9 рассказывает о том, как установить каденцию расстановки приоритетов и когда она может происходить по запросу или по ситуации, а не на специальном регулярном совещании. В главе 11 говорится о том, как задать ожидания времени выполнения и как определить содержание релиза.
Координационные затраты на релиз
Координация любого программного релиза связана с затратами. Необходимо собрать людей для обсуждения выпуска, производства, упаковки, маркетинга, работы с потенциальными клиентами, документации, подготовки конечных пользователей, дилеров, отдела справок и службы технической поддержки, документации и процедур по установке, дежурных сотрудников, расписания выпуска и т. д. Планирование поставки элемента работающей программы бывает невероятно сложным – все зависит от отрасли бизнеса и типа программы. Обновление сайта, например, может оказаться тривиальной задачей по сравнению с обновлением прошивки военного оборудования, используемого по всему миру, спутников на орбите, боевого самолета или узлов телефонной сети. В 2002 году, когда мы планировали релиз обновления PCS Vision для американской сети сотовых телефонов Sprint PCS, требовалось обучить десятки тысяч людей. Нужно было объяснить 17 тысячам продавцов по всей стране, как работают около 15 новых телефонов, выводимых на рынок. Примерно такому же количеству человек предстояло объяснить, как отвечать на неизбежные звонки в службу техподдержки, которые обязательно последуют, когда неопытные клиенты приобретут свои новые устройства. Одно только планирование обучения 30 тысяч человек обходится недешево.
Поэтому важно понимать координационные издержки, связанные с релизом. Например, если разработчикам нужно посещать совещания по координации релиза, то не отрывает ли это их от работы над программами? Ниже представлен список вопросов, которые нужно задать себе в первую очередь.
• Сколько совещаний?
• Сколько людей?
• Сколько времени это займет?
• Каков будет ущерб в результате отрыва людей от их основной работы?
Операционные расходы релиза
В случае с физически существующими товарами легко представить себе операционные расходы. Первый из них – платеж. Клиент платит поставщику, используя некое платежное средство, например кредитную карточку. За удовольствие получить платеж по кредитной карте ведущие компании в этой сфере, например MasterCard и Visa, взимают с продавца операционные расходы, обычно составляющие 2–4 % от стоимости сделки.
Помимо затрат на финансовые расчеты между продавцом и покупателем нужно учесть и возможные расходы на доставку – а это не только деньги, но и время и рабочая сила. Могут быть также и монтажные расходы. Например, вы покупаете в Sears стиральную машину и заказываете доставку на определенный день. Тем временем происходит планирование и уточнение, чтобы водитель доставил выбранную модель в нужный дом в правильное время и в срок. Все это – координационные расходы на доставку. Водитель забирает стиральную машину на складе, везет ее к вам домой и распаковывает там – это операционные расходы. Он же или вызванный специалист устанавливает ее. Специалисту нужно время, чтобы добраться до вашего дома, а затем установить купленное устройство. Все это – время, усилия на доставку и монтаж – составные части операционных расходов на покупку стиральной машины.
С экономической точки зрения розничный оператор абсорбирует операционные расходы на использование кредитных карт. Но операционные расходы на доставку и монтаж часто оплачивает покупатель. При этом не все они «видны» или «ощутимы» участниками цепочки создания ценности, но влияют на экономическую производительность системы в целом. Результат всех этих издержек состоит в повышении конечной стоимости, которую выплачивает покупатель, но при этом поставляемая ценность не увеличивается.
Действительно, от стиральной машины без доставки и установки мало толку, но ее ценность состоит в том, что она стирает одежду. Доставка и установка не создают ценности, так что должны быть отнесены к операционным расходам.
В разработке ПО операционные расходы на поставку программ тоже могут быть по своей природе физическими.
Так, некоторые фирмы, например Microsoft, продолжают производить «окончательные версии для промышленной эксплуатации» (RTM) и выпускают физические носители – DVD, упаковывают их и рассылают распространителям, розничным операторам и другим партнерам. Если ПО – часть встроенной системы, то необходимой может оказаться поставка чипов или, по крайней мере, запись программного кода в прошивку при помощи таких технологий, как EE-PROM. Чипы после этого, вероятнее всего, придется вмонтировать в оборудование, которое они призваны контролировать.
В иных случаях достаточно электронного распространения. Например, прошивку и настройки сотовых телефонов сейчас обновляют посредством так называемого управления устройством «по воздуху». Так же можно поступить с прошивкой многих спутников и автоматических межпланетных станций, поэтому космические аппараты сейчас стали намного более гибкими, чем ранее. Их работу можно изменить, загрузив новое оборудование. Ошибки тоже можно исправлять на местах. Некоторые печально известные дефекты, например фокусировка телескопа «Хаббл», были (частично) исправлены за счет изменения программного кода. Это трансформировало экономику эксплуатации.
