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

Итак, релизы сопровождения ПО были единственной отраслью в IT-подразделении Corbis, где канбан мог обеспечить некоторую степень бизнес-гибкости.

Небольшие проекты сопровождения ПО неэффективны

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

Внедрение изменений

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

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

Первичные результаты изменений

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