Канбан. Альтернативный путь в Agile - Дэвид Андерсон

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 9

Формирование каденции пополнения

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

Координационные расходы на расстановку приоритетов

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

Шесть подразделений конкурировали за общие ресурсы, необходимые для внесения небольших изменений и обновлений. При первом представлении канбан-системы был рассмотрен кейс, направленный на возможность поставки частых, «тактических» релизов командой поддержки. Эта команда обеспечивала ограниченную деловую гибкость путем выпуска небольших, инкрементальных релизов, тогда как новые IT-проекты создавались в соответствии с традиционным процессом управления отдела руководства программой (PMO). Обоснование и авторизация каждого проекта в портфеле проходили в индивидуальном порядке. Команда поддержки была одобрена исполнительным комитетом, на нее выделили 10 % бюджета, что позволило взять еще пятерых сотрудников. Отдел получил название «команда быстрого реагирования» (КБР). Но оно оказалось неудачным, потому что реакция не была быстрой, а иногда вовсе отсутствовала, да и команды как таковой не было.

Создать новый отдел технического обслуживания из этих пяти человек не удалось. IT-системы Corbis были очень разными, многие из них требовали специализированных навыков. Функции аналитиков, разрабатывающих и уточняющих системные требования, давались специалистам особенно тяжело. Пять новых сотрудников примерно на равных выполняли все задачи команды поддержки, включая управление проектами, системный анализ, разработку, тестирование, управление конфигурациями и сборками. То есть никакой команды не существовало. Буква «К» в аббревиатуре КБР ничего не значила. А ведь это считалось отдельной задачей менеджмента – показать, что дополнительные 10 % ресурсов потрачены на работу по обслуживанию и поддержке, а не просто поглощены общими крупными проектами.

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

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

До введения Канбана расходы на координацию – согласование требований для релиза техподдержки – были чрезмерными. Менеджеру проекта Дайане Коломиец, а часто и ее руководителю, менеджеру группы проектов, нужно было собрать встречу с участием всех заинтересованных сторон – бизнес-аналитиков, представителей бизнеса, системных аналитиков, руководителей разработки, руководителей групп тестирования и билд-инженера, а иногда также менеджера по управлению конфигурациями, представителей служб поддержки и сопровождения. Такие совещания порой длились несколько часов и заканчивались безрезультатно: членам разных команд поручалось провести оценки и назначалась следующая встреча. Она нередко переходила в дискуссию о приоритетах и тоже завершалась ничем. В сентябре 2006 года, чтобы договориться об объеме релиза, выпуск и поставка которого занимали две недели, приходилось затрачивать те же две недели на бесконечные совещания. Из-за двухнедельных итераций в релиз включались только очень небольшие задачи, а многие потенциально прибыльные запросы игнорировались. Эти запросы перенаправлялись в основной проект, поэтому период внедрения составлял месяцы, а порой и годы. Система, использовавшаяся до канбан-системы, не предполагала ни быстроты, ни реагирования. Буквы «БР» в аббревиатуре КБР не имели смысла.