style="font-size:15px;"> Канбан делает возможными все шесть этапов рецепта успеха и обеспечивает его реализацию, а рецепт успеха создает доверие к внедряющему его менеджеру. В свою очередь, рецепт успеха иллюстрирует ценность Канбана.
Выводы
• Канбан делает возможным реализацию всех составляющих рецепта успеха.
• Рецепт успеха объясняет ценность Канбана.
• Плохое качество – это главный источник потерь в разработке ПО.
• Снижение количества незавершенных задач повышает качество продукта.
• Повышение качества порождает доверие у сотрудников ниже по цепочке создания ценности – например, операционных инженеров.
• Частый выход релизов порождает доверие со стороны сотрудников выше по цепочке создания ценности – например, отдела маркетинга.
• Вытягивающая система может сбалансировать нагрузку и пропускную способность.
• Вытягивающие системы выявляют бутылочные горлышки и создают резервы времени и усилий в остальных местах.
• Качественная расстановка приоритетов максимизирует производительность цепочки создания ценности в разработке ПО.
• Расстановка приоритетов сама по себе мало значит без хорошего изначального качества и предсказуемости производственной системы.
• Чтобы внести изменения для сокращения вариативности, требуются резервы.
• Сокращение вариативности снижает потребность в резервах.
• Сокращение вариативности позволяет сбалансировать ресурсы (а в дальнейшем, возможно, и сократить численный состав команды).
• Сокращение вариативности снижает требования к ресурсам.
• Сокращение вариативности позволяет уменьшить количество канбан-жетонов, незавершенных задач и приводит к снижению среднего времени выполнения.
• Появление резервов создает возможности для улучшения.
• Усовершенствование процесса ведет к повышению производительности и предсказуемости.
Глава 4
От худшего к лучшему за пять кварталов
В октябре 2004 года Драгош Думитриу был менеджером программ в Microsoft. Он только что возглавил отдел, который имел репутацию худшего IT-подразделения компании.
Должность «менеджер программ» в Microsoft примерно соответствует тому, что в других местах называют менеджером проектов, но обычно включает также некоторую ответственность за анализ и архитектуру. Менеджер программ назначается на инициативу, проект или продукт и отвечает за часть функционала. Чтобы выполнить работу, он привлекает ресурсы из функциональных областей, например разработки и тестирования. Драгош отвечал за техническое обеспечение ПО для бизнес-подразделения XIT. Эта команда (рис. 4.1), зрелость процессов которой
