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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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