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

Рис. 4.6. Перераспределение ресурсов

Финансовый год Microsoft подходил к концу. Высшее руководство заметило значительный рост производительности и стабильности результатов команды техподдержки XIT.

Руководители наконец-то поверили в Драгоша и его методы. Отделу были выделены средства, чтобы нанять еще двух сотрудников. В июле 2005 года в команде появились новый разработчик и тестировщик. Результаты оказались существенными.

Рис. 4.7. Добавление ресурсов

Дополнительная мощность позволила пропускной способности превысить требования. В результате бэклог 22 ноября 2005 года оказался полностью исполнен. К тому времени команда сократила срок выполнения в среднем до 14 дней при сохранении 11-дневного периода разработки. Выполнение 25-дневного дедлайна составляло 98 %. Пропускная способность увеличилась более чем втрое, время выполнения сократилось на 90 % и выше, а надежность программ примерно на столько же выросла. В процессы разработки ПО и тестирования не было внесено никаких изменений. Метод PSP/TSP остался неизменным, все корпоративные нормы, процедуры и контрактные обязательства строго соблюдались. Во второй половине 2005 года команда стала лучшей среди всех инженерных коллективов корпорации. Драгош получил дополнительные полномочия, а текущее руководство команды перешло к региональному менеджеру в Индии, который, впрочем, перебрался в Вашингтон.

Рис. 4.8. Квартальная пропускная способность на единицу производства

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

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

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

Рис. 4.9. Время выполнения командой техподдержки XIT по финансовым годам Microsoft

Но какой менеджер проигнорирует возможность увеличить производительность более чем на 200 %, сократить время выполнения на 90 % и существенно повысить предсказуемость при минимальных политических рисках и сопротивлении изменениям?

• Первая канбан-система была внедрена в команде техподдержки XIT в Microsoft в 2004 году.

• Первая канбан-система использовала ПО для отслеживания работы.

• Первая канбан-система была внедрена в удаленной команде подрядчика в Хайдарабаде, которая стояла на пятом уровне в модели зрелости CMMI.

• Рабочий поток требуется описать и визуализировать.

• Процесс следует описывать как явно заданный набор правил.

• Канбан способствует постепенным изменениям.

• Канбан минимизирует политические риски при внесении изменений.

• Канбан минимизирует сопротивление изменениям.

• Канбан предоставляет возможности совершенствования, которые не предполагают сложных изменений в инженерных методах.

• Первая канбан-система показала более чем 200 %-ное увеличение производительности, 90 %-ное снижение времени выполнения и примерно такое же увеличение предсказуемости поставки.

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

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