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

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

Но каким образом достигалась расстановка приоритетов, если подсчет ROI больше не проводился? Оказалось, что он и не нужен. Если элемент важен и ценен, то его выбирали из очереди в бэклоге, а если нет, то отодвигали дальше. Позже Драгош понял, что необходимо еще одно правило – безжалостно удалять из бэклога любой элемент более чем шестимесячной давности. Если за полгода о нем ни разу не вспомнили, то наверняка он не имеет никакого значения. А если выяснится, что данный элемент все же важен, то его можно включить заново.

А как насчет правила, согласно которому крупные запросы не поступали в техподдержку, а становились частью большого проекта? В итоге решили, что некоторые из них все же могут туда направляться. Опыт показывал, что таких запросов обычно менее 2 %. Разработчиков просили быть внимательными и, если новый запрос, по их оценкам, требовал на обработку более 15 дней, предупреждать своего менеджера. Риски и затраты в данном случае составляли менее 1 % доступной мощности. Это прекрасно окупалось: отказавшись от оценок, команда обрела более 33 % мощности за счет затрат менее 1 % той же мощности. Это новое правило позволило разработчикам управлять рисками и при необходимости высказывать свое мнение!

На первые два изменения отвели шесть месяцев. В течение этого периода внесли еще кое-какие незначительные улучшения. Как уже упоминалось, появилось правило очищения бэклога, а еженедельное совещание с владельцами продукта исчезло. Процесс протекал так гладко, что Драгош автоматизировал инструмент Product Studio: теперь он получал электронное сообщение каждый раз, когда образовывалось свободное место для нового задания. После этого Драгош предупреждал по электронной почте владельцев продукта, что им необходимо решить, за какое задание браться прежде всего. Производился выбор, и запрос из бэклога работы переводился в очередь через два часа после того, как появлялось свободное место.

Поиск дальнейших улучшений

Драгош начал искать способы для дальнейших улучшений. Изучив данные о продуктивности тестировщиков его команды и сравнив их с показателями других команд XIT от того же подрядчика, он заподозрил, что тестировщики располагают существенными резервами. Между тем звено разработчиков можно было назвать настоящим узким местом. Драгош решил навестить команду в Индии и, возвратившись, посоветовал подрядчику перераспределить ресурсы. Число тестировщиков сократили с трех до двух, но добавили дополнительного разработчика (рис. 4.6). Это привело к практически линейному увеличению производительности: пропускная способность за квартал повысилась с 45 до 56.

Рис. 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 % и существенно повысить предсказуемость при минимальных политических рисках и сопротивлении изменениям?