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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать

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

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

Рис 42 Изначальный рабочий процесс технического обеспечения в XIT с - фото 9

Рис. 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).

Рис 43 Рабочий процесс демонстрирующий оценки ROM и внесение PTC - фото 10

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

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

Команда следовала предписанным процедурам, которые, к сожалению, содержали и неудачные решения, принятые менеджерами на различных уровнях. Важно помнить, что процесс – это набор правил, управляющих поведением, которые находятся под контролем руководства. Например, решение использовать PSP/TSP приняли на уровне вице-президента, то есть всего рангом ниже Билла Гейтса. Такое правило отменить тяжело или невозможно. Но другие правила, например приоритет оценок перед написанием кода и тестированием, были разработаны непосредственными руководителями на местах. Возможно, эти правила имели смысл, когда их внедряли. Но обстоятельства изменились, однако никто не попытался пересмотреть и обновить правила, по которым работала команда.

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

Интервал:

Закладка:

Сделать

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

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


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

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

x