Книга Канбан. Альтернативный путь в Agile, страница 35. Автор книги Дэвид Андерсон

Разделитель для чтения книг в онлайн библиотеке

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

Cтраница 35
Не устанавливать WIP-лимит – это ошибка

Хотя я советую быть сдержаннее при установлении изначальных WIP-лимитов, вовсе не устанавливать их – это ошибка.

Некоторые ранние последователи Канбана, например Yahoo! решили отказаться от WIP-лимитов, поскольку считали, что их команды недостаточно слаженны, чтобы справиться с негативными ощущениями, которые лимиты вызовут в компании. Предполагалось, что организации превратятся в более зрелые благодаря средствам визуального контроля Канбана, а WIP-лимиты можно будет внедрить позже. Однако это оказалось непросто, и несколько команд отказались от Канбана, а остальные захлестнула волна реорганизаций и отмен проектов, так что дальнейший сбор данных был затруднен. В Corbis некоторые команды на крупных проектах продолжали работать в рамках Канбана с очень свободными WIP-лимитами над высокоуровневой функциональностью. Результаты вызвали смешанные впечатления.

Я убедился, что напряжение, которое создается при наложении WIP-лимитов на цепочку создания ценности, – это позитивный фактор. Позитивное напряжение вызывает обсуждение организационных проблем и дисфункций. Дисфункции создают помехи рабочему потоку, в результате время выполнения и качество окажутся неоптимальными. Дискуссии и совместная работа, вызванные позитивным напряжением, созданным WIP-лимитом, идут организации на пользу. Это механизм, который порождает культуру непрерывного совершенствования. Без WIP-лимитов улучшение процессов идет очень медленно. Команды, которые сразу же установили WIP-лимиты, сообщают об ускорении роста мощности и организационной зрелости и увеличении коммерческих показателей благодаря регулярным частым релизам высококачественного программного обеспечения. Напротив, команды, пренебрегающие введением WIP-лимитов, обычно сталкиваются с проблемами и демонстрируют лишь незначительные улучшения.

Распределение мощности

Установив WIP-лимиты для всего рабочего потока в системе, можно задуматься о распределении мощности по типам единиц работы или классам обслуживания.

На рис. 10.3 изображена стена карточек из главы 6 с WIP-лимитами по столбцам – всего 20 карточек. Мощность распределена по типам работы: 60 % идет на запросы изменений, 10 % – на элементы поддержки и 30 % – на производственные текстовые изменения.


Канбан. Альтернативный путь в Agile

Рис. 10.3. Стена карточек с «плавательными дорожками» для каждого типа единиц работы с указанными для каждой дорожки WIP-лимитами


Это соответствует таким значениям WIP-лимитов для каждой «плавательной дорожки»: 12 для запросов изменений, 2 для элементов поддержки и 6 для производственных текстовых изменений.

Распределение мощности позволяет гарантировать обслуживание для каждого типа работы, введенного в канбан-систему, и должно производиться в соответствии с примерным спросом для каждого типа работы. Таким образом, чтобы разумно распределить WIP-лимиты для каждого типа работы по «плавательным дорожкам», важно провести некоторый анализ предъявляемых требований.

Выводы

• WIP-лимиты должны быть согласованы с заинтересованными лицами из других подразделений и высшего руководства на основе общего консенсуса.

• Возможно и одностороннее установление WIP-лимитов, однако позднее, когда система окажется под стрессом, эту позицию будет трудно защищать.

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

• Обычно лимит задается из расчета 1–3 единицы на 1–2 человек или на команду.

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

• Бутылочные горлышки нужно снабдить буфером.

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

• Все WIP-лимиты можно изменять эмпирически.

• Канбан – это эмпирический процесс.

• Не нужно тратить слишком много времени, пытаясь определить идеальный WIP-лимит; просто возьмите приблизительное значение и работайте. При необходимости внесете изменения позже.

• Можно отказаться от лимитов для более поздних этапов работы.

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

• После установления WIP-лимитов распределяйте мощность по типам единиц работы.

• Для каждого типа единиц работы часто используются «плавательные дорожки», для каждой из которых задается свой WIP-лимит.

• Распределение мощности требует проведения сравнительного анализа спроса на разные типы работы, вводимые в канбан-систему.

Глава 11
Формирование соглашений об уровне обслуживания

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

Эта идея известна в сфере программного обеспечения и IT-систем, в частности, при исправлении ошибок, особенно возникших в продуктивной среде. Мы разделяем ошибки по степени серьезности (воздействия) и приоритету (срочности). Очень серьезные и высокоприоритетные ошибки устраняются немедленно. Они получают другой, более высокий класс обслуживания по сравнению с остальными задачами. Чтобы устранить серьезную ошибку в продукте, мы откладываем в сторону другую работу, привлекаем максимальное количество людей и часто составляем отдельные планы для срочной отладки, патча или релиза, разрешающих проблему.

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

Классы обслуживания повышают удобство при классификации работы, чтобы обеспечить приемлемые уровни удовлетворенности покупателя по оптимальной с экономической точки зрения цене. Быстро определив для элемента класс обслуживания, мы устраняем необходимость проводить детальную оценку или анализ. Правила, связанные с классом обслуживания, влияют на то, как элементы втягиваются в систему, и определяют приоритет в системе. Классы обслуживания дают возможность применить к расстановке приоритетов и смене приоритетов задач, находящихся в работе, подход, основанный на самоорганизации, оптимизации ценности и рисков.

Вход
Поиск по сайту
Ищем:
Календарь
Навигация