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

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

Визуализация рабочего процесса

Я попросил Драгоша сделать изображение рабочего процесса. Он набросал схему, в которой описывался жизненный цикл для запроса изменений, после чего мы обсудили проблему. Рис. 4.2 – это факсимиле того, что он сделал. Фигурка PM (менеджера программ) изображает Драгоша.

Рис. 4.2. Изначальный рабочий процесс технического обеспечения в XIT с указанием времени выполнения Initial

Поступление запросов было бесконтрольным. Четыре менеджера продукта представляли и контролировали бюджеты для ряда клиентов, которые владели приложениями, обслуживаемыми XIT. Они добавляли новые запросы и дефекты, выявленные в процессе промышленной эксплуатации.

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

Факторы, влияющие на производительность

Когда поступал запрос, Драгош отправлял его на оценку в Индию. Согласно регламенту, оценку нужно было произвести и представить владельцам бизнеса в течение 48 часов. Так было легче вычислить ROI (прибыли на инвестицию) и принять решения по запросу. Раз в месяц Драгош встречался с менеджерами продукта и другими заинтересованными лицами: проводилась новая расстановка приоритетов в бэклоге и составлялся план проекта по запросам.

В то время в месяц обрабатывалось около семи запросов. В бэклоге было более 80 записей, и его объем продолжал увеличиваться. Таким образом, ежемесячно подвергались переоценке более 70 запросов, а обработка запроса занимала в среднем четыре месяца. В этом и крылась основная причина неудовлетворительной работы. Сами запросы были небольшими, но постоянное изменение приоритетов означало стабильную неудовлетворенность клиентов.

Запросы фиксировались при помощи инструмента под названием Product Studio. Обновленная версия этой программы была впоследствии выпущена под названием Team Foundation Server Work Item Tracking. Команда техподдержки XIT представляла собой хорошо мне знакомый тип организации, в которой имеется множество данных, но они не используются. Драгош начал анализировать данные и обнаружил, что средний запрос занимал 11 рабочих дней.

Время выполнения при этом составляло от 125 до 155 дней, более 90 % времени тратилось впустую, в том числе на ожидание в очереди.

Оценки поступающей работы отнимали много ресурсов. Мы решили проанализировать процесс оценки, сделав ряд предположений. Хотя аббревиатура ROM расшифровывается как rough order of magnitude (приблизительный порядок величины), клиенты ожидали, что оценка будет очень точной, и члены команды проводили ее с особой тщательностью. У каждого разработчика и тестера одна оценка занимала примерно рабочий день. Мы подсчитали, что на это уходило около 33 % ресурсов команды, а в неудачный месяц – и 40 % рабочего времени, то есть больше, чем на разработку и тестирование. К тому же оценка новых запросов нередко вносила путаницу в планы, составленные на текущий месяц.

Помимо запросов на изменения у команды имелся и второй вид работ – так называемые текстовые изменения на продуктивной среде (Production text changes, PTC), касающиеся интерфейса, редакционных исправлений, изменения данных таблиц или xml-сообщений. Эти изменения не требовали участия разработчиков и часто вносились владельцами бизнеса, менеджерами продукта или программ. Но поскольку они подвергались формальной тестовой приемке, участие тестировщиков было все же необходимо.

PTC традиционно выполнялись прежде всей остальной работы или оценок. PTC поступали неравномерными порциями и тоже нарушали планы на месяц (рис. 4.3).

Рис. 4.3. Рабочий процесс, демонстрирующий оценки ROM и внесение PTC

Установление явных процедурных правил