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

Здесь есть возможность читать онлайн «Дэвид Андерсон - Канбан. Альтернативный путь в Agile» — ознакомительный отрывок электронной книги совершенно бесплатно, а после прочтения отрывка купить полную версию. В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2017, ISBN: 2017, Издательство: Литагент МИФ без БК, Жанр: Экономика, org_behavior, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Канбан. Альтернативный путь в Agile: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Канбан. Альтернативный путь в Agile»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

«Канбан» в переводе с японского – «сигнальная доска». В производстве такая доска используется для визуализации нарастающих темпов, что позволяет выпускать больше продукции с меньшими затратами. Яркий пример – подход компании Toyota, благодаря которому в течение многих лет эффективно реализуется принцип «точно в срок» с минимальными издержками.
Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.
В книге описаны инструменты, позволяющие эффективно вводить идеи бережливого производства в технологические разработки и IT-операции с минимальным сопротивлением изменениям и при этом сохранять оптимальный для всех вовлеченных в работу сотрудников темп.
На русском языке публикуется впервые.

Канбан. Альтернативный путь в Agile — читать онлайн ознакомительный отрывок

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Канбан. Альтернативный путь в Agile», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Выводы

• Канбан делает возможным реализацию всех составляющих рецепта успеха.

• Рецепт успеха объясняет ценность Канбана.

• Плохое качество – это главный источник потерь в разработке ПО.

• Снижение количества незавершенных задач повышает качество продукта.

• Повышение качества порождает доверие у сотрудников ниже по цепочке создания ценности – например, операционных инженеров.

• Частый выход релизов порождает доверие со стороны сотрудников выше по цепочке создания ценности – например, отдела маркетинга.

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

• Вытягивающие системы выявляют бутылочные горлышки и создают резервы времени и усилий в остальных местах.

• Качественная расстановка приоритетов максимизирует производительность цепочки создания ценности в разработке ПО.

• Расстановка приоритетов сама по себе мало значит без хорошего изначального качества и предсказуемости производственной системы.

• Чтобы внести изменения для сокращения вариативности, требуются резервы.

• Сокращение вариативности снижает потребность в резервах.

• Сокращение вариативности позволяет сбалансировать ресурсы (а в дальнейшем, возможно, и сократить численный состав команды).

• Сокращение вариативности снижает требования к ресурсам.

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

• Появление резервов создает возможности для улучшения.

• Усовершенствование процесса ведет к повышению производительности и предсказуемости.

Глава 4

От худшего к лучшему за пять кварталов

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

Должность «менеджер программ» в Microsoft примерно соответствует тому, что в других местах называют менеджером проектов, но обычно включает также некоторую ответственность за анализ и архитектуру. Менеджер программ назначается на инициативу, проект или продукт и отвечает за часть функционала. Чтобы выполнить работу, он привлекает ресурсы из функциональных областей, например разработки и тестирования. Драгош отвечал за техническое обеспечение ПО для бизнес-подразделения XIT. Эта команда (рис. 4.1), зрелость процессов которой оценивалась как CMMI Model Level 5, располагалась в Индии и состояла из трех разработчиков, трех тестировщиков и менеджеров, занимавшихся разработкой небольших обновлений и устранением ошибок примерно в 80 кроссфункциональных IT-приложениях, используемых сотрудниками Microsoft по всему миру. Сам Драгош находился в кампусе в Редмонде. В то же самое время там работал и я.

Рис 41 Команда в Хайдарабаде Индия Драгош четвертый слева Проблема - фото 8

Рис. 4.1. Команда в Хайдарабаде (Индия). Драгош – четвертый слева

Проблема

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

Программисты и тестировщики этой организации следовали методологии PSP/TSP (Personal Software Process / Team Software Process). Такие требования компании Microsoft были записаны в контракте. Джон Де Ваан в то время – непосредственный подчиненный Билла Гейтса и большой поклонник Уоттса Хамфри из Института программной инженерии. Как глава Engineering Excellence в Microsoft, он мог требовать от IT-отдела и его поставщиков соблюдения определенных процедур. Поэтому изменение метода жизненного цикла разработки ПО было невозможным.

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

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Канбан. Альтернативный путь в Agile»

Представляем Вашему вниманию похожие книги на «Канбан. Альтернативный путь в Agile» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Канбан. Альтернативный путь в Agile»

Обсуждение, отзывы о книге «Канбан. Альтернативный путь в Agile» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x