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

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

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

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

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

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

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

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

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