Дэвид Андерсон - Канбан. Альтернативный путь в Agile
- Название:Канбан. Альтернативный путь в Agile
- Автор:
- Жанр:
- Издательство:Литагент МИФ без БК
- Год:2017
- Город:Москва
- ISBN:978-5-00100-530-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Дэвид Андерсон - Канбан. Альтернативный путь в Agile краткое содержание
Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.
В книге описаны инструменты, позволяющие эффективно вводить идеи бережливого производства в технологические разработки и IT-операции с минимальным сопротивлением изменениям и при этом сохранять оптимальный для всех вовлеченных в работу сотрудников темп.
На русском языке публикуется впервые.
Канбан. Альтернативный путь в Agile - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Не подвергайте организацию стрессу
Излишне жесткие WIP-лимиты могут подвергнуть вашу организацию сильному стрессу. У компаний с низкой степенью зрелости и невысокой производительностью изначально проблем будет больше. Для таких организаций внедрение канбан-системы может протекать болезненно при наличии слишком жестких WIP-лимитов. Если выявляется большое количество препятствий, отмеченных на стене розовыми карточками, то слишком жесткие WIP-лимиты могут привести к полной остановке работы, так что жертвами простоя окажутся все сотрудники. Конечно, простой можно использовать для концентрации внимания и накопления сил с целью решить проблемы и устранить препятствия, но он может слишком дорого обойтись недостаточно зрелой организации. Руководители начнут испытывать раздражение при виде праздношатающихся людей, которые продолжают получать зарплату.
Внося изменения, необходимо помнить о так называемом эффекте J-кривой. Обычно при каждом изменении WIP-лимитов на графике производительности появляется фигура, похожая на букву J: когда изменения незначительны, размер J невелик. Если установить слишком жесткие WIP-лимиты, то эффект J-кривой окажется слишком глубоким и длительным, что способно привести к нежелательным последствиям. Канбан обнажает все проблемы организации, но в итоге метод могут обвинить в том, что из-за него все стало только хуже. Канбан начнут воспринимать как часть проблемы, а не как ее решение. Поэтому действуйте осторожно. Если организация обладает большей мощностью и зрелостью и реже страдает от неожиданных проблем (вариативностей систематической погрешности), то можно проводить более агрессивную политику WIP-лимитов. Если организация менее слаженна, то изначально стоит ввести более свободные ограничения, с тем чтобы снизить WIP-лимиты позже.
Не устанавливать WIP-лимит – это ошибка
Хотя я советую быть сдержаннее при установлении изначальных WIP-лимитов, вовсе не устанавливать их – это ошибка.
Некоторые ранние последователи Канбана, например Yahoo! решили отказаться от WIP-лимитов, поскольку считали, что их команды недостаточно слаженны, чтобы справиться с негативными ощущениями, которые лимиты вызовут в компании. Предполагалось, что организации превратятся в более зрелые благодаря средствам визуального контроля Канбана, а WIP-лимиты можно будет внедрить позже. Однако это оказалось непросто, и несколько команд отказались от Канбана, а остальные захлестнула волна реорганизаций и отмен проектов, так что дальнейший сбор данных был затруднен. В Corbis некоторые команды на крупных проектах продолжали работать в рамках Канбана с очень свободными WIP-лимитами над высокоуровневой функциональностью. Результаты вызвали смешанные впечатления.
Я убедился, что напряжение, которое создается при наложении WIP-лимитов на цепочку создания ценности, – это позитивный фактор. Позитивное напряжение вызывает обсуждение организационных проблем и дисфункций. Дисфункции создают помехи рабочему потоку, в результате время выполнения и качество окажутся неоптимальными. Дискуссии и совместная работа, вызванные позитивным напряжением, созданным WIP-лимитом, идут организации на пользу. Это механизм, который порождает культуру непрерывного совершенствования. Без WIP-лимитов улучшение процессов идет очень медленно. Команды, которые сразу же установили WIP-лимиты, сообщают об ускорении роста мощности и организационной зрелости и увеличении коммерческих показателей благодаря регулярным частым релизам высококачественного программного обеспечения. Напротив, команды, пренебрегающие введением WIP-лимитов, обычно сталкиваются с проблемами и демонстрируют лишь незначительные улучшения.
Распределение мощности
Установив WIP-лимиты для всего рабочего потока в системе, можно задуматься о распределении мощности по типам единиц работы или классам обслуживания.
На рис. 10.3 изображена стена карточек из главы 6с WIP-лимитами по столбцам – всего 20 карточек. Мощность распределена по типам работы: 60 % идет на запросы изменений, 10 % – на элементы поддержки и 30 % – на производственные текстовые изменения.

Рис. 10.3. Стена карточек с «плавательными дорожками» для каждого типа единиц работы с указанными для каждой дорожки WIP-лимитами
Это соответствует таким значениям WIP-лимитов для каждой «плавательной дорожки»: 12 для запросов изменений, 2 для элементов поддержки и 6 для производственных текстовых изменений.
Распределение мощности позволяет гарантировать обслуживание для каждого типа работы, введенного в канбан-систему, и должно производиться в соответствии с примерным спросом для каждого типа работы. Таким образом, чтобы разумно распределить WIP-лимиты для каждого типа работы по «плавательным дорожкам», важно провести некоторый анализ предъявляемых требований.
Выводы
• WIP-лимиты должны быть согласованы с заинтересованными лицами из других подразделений и высшего руководства на основе общего консенсуса.
• Возможно и одностороннее установление WIP-лимитов, однако позднее, когда система окажется под стрессом, эту позицию будет трудно защищать.
• WIP-лимиты для рабочих задач должны устанавливаться как среднее количество элементов на одного-двух человек или на небольшую команду, работающую над единым проектом.
• Обычно лимит задается из расчета 1–3 единицы на 1–2 человек или на команду.
• Лимиты для очереди должны быть достаточно небольшими – обычно такими, чтобы амортизировать естественную (случайную) вариативность в размере элементов и длительности задач.
• Бутылочные горлышки нужно снабдить буфером.
• Размер буфера должен быть минимальным, но при этом достаточным для обеспечения оптимальной производительности в бутылочном горлышке и устойчивого распределения рабочего потока по системе.
• Все WIP-лимиты можно изменять эмпирически.
• Канбан – это эмпирический процесс.
• Не нужно тратить слишком много времени, пытаясь определить идеальный WIP-лимит; просто возьмите приблизительное значение и работайте. При необходимости внесете изменения позже.
• Можно отказаться от лимитов для более поздних этапов работы.
• Нужно убедиться, что отказ от лимитов на некоторых этапах рабочего процесса не приводит к образованию бутылочных горлышек либо появлению чрезмерных операционных или координационных расходов при релизах.
• После установления WIP-лимитов распределяйте мощность по типам единиц работы.
• Для каждого типа единиц работы часто используются «плавательные дорожки», для каждой из которых задается свой WIP-лимит.
Читать дальшеИнтервал:
Закладка: