Часто задаваемые вопросы

Вы говорите о WIP-лимитах и явной стратегии как об инструментах, способных изменить работу команды. Но этот аргумент кажется надуманным. Или это все-таки правда?

Удивительно, но это правда. Чтобы понять почему, вернемся к истокам Lean и Канбана.

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

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

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

Иногда легче понять это при помощи примера, не имеющего ничего общего ни с конвейером, ни с программным обеспечением. Каждое лето на большой выставочной площадке в Сент-Поле проводится ярмарка, которую посещает более миллиона жителей штата. На территории выставочного комплекса располагается множество поставщиков продуктов питания. Один из самых популярных – стенд компании – производителя кукурузы гриль. Другие известные поставщики имеют длинные очереди у своих стендов – например, не менее двух десятков людей выстраиваются, чтобы купить жареные оливки на палочке[87]. Но там, где посетителям предлагают кукурузу гриль, как правило, огромное количество людей обслуживается практически без очередей. Как они этого добились?

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

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

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

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

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

Регулирование WIP-лимита предоставляет поставщику кукурузы гриль свободу действий. Увеличение чеков приводит к росту количества жарящейся кукурузы в периоды с пиковой нагрузкой (например, после окончания больших шоу на ближайших трибунах). Они могут быстро и плавно нарастить производство, а затем так же плавно его уменьшить после спада спроса. Знают ли продавцы кукурузы, что они применяют закон Литтла? Ограничивая число прибывающих в систему людей, они могут уменьшить время обработки заказа, чтобы клиенты, заплатившие за кукурузу, не ожидали ее. (Вы можете представить, как выглядит кумулятивная диаграмма потока?)

Этот пример помогает проиллюстрировать разницу между выталкивающими и вытягивающими системами. Производители жареных оливок используют выталкивающую систему – длинную очередь. Люди «проталкивают» ее, потому что она привлекает покупателей и создает спрос. Поставщики оливок не имеют контроля над спросом, они могут продавать оливки только следующему человеку из очереди. Продавцы кукурузы гриль «втягивают» очередь, потому что выдают чеки заплатившему клиенту. Они используют их для притягивания людей к своему стенду и могут ограничить количество покупателей, если оно достигает лимита. Так они устанавливают WIP-лимит, позволяющий им уравновешивать производственные возможности и спрос. Регулирование WIP-лимита дает возможность мгновенно приспосабливаться к меняющейся ситуации.

У меня нет обилия деталей для сборки автомобиля или кукурузы, которую нужно обжарить на гриле. Я создаю программное обеспечение, поэтому постоянно решаю различные проблемы. Какое отношение ко мне имеют эти примеры?

Канбан имеет к вам самое прямое отношение, потому что это система, позволяющая мгновенно реагировать на изменения в проекте. Вводя лимит на выполнение незавершенных работ и контролируя размер очереди, вы уменьшаете вариабельность. Выделяя источники задержек и применяя такие методы, как кластеризация блокеров (или анализ коренных причин блокировок и усовершенствования, направленные на снижение вероятности и влияния блокеров), мы сокращаем вариабельность. Атака на ее источники, негативно влияющие на экономический результат системы, является одной из основных техник Канбана[88].

Командам разработчиков нужно этим заниматься – и много. Можно утверждать, что разработчики гораздо чаще имеют дело с изменчивостью, чем производители автомобилей или поставщики кукурузы. Программное обеспечение отличается от любого другого инжинирингового продукта тем, что оно изменчиво. Так как ПО не является физическим объектом, программисты имеют гораздо больше возможностей, чем другие инженеры, изменять его и на более поздних этапах проекта. Но каждое изменение несет риск. И если ваш проект бросало из стороны в сторону вследствие изменившихся требований, то появляются неравномерности (мура), потому что эти изменения могут стать очень разрушительными.

Так что же вы можете сделать, чтобы убедиться, что эти неравномерности не сорвут проект?

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

Мир традиционного управления проектами выглядит не таким мрачным, как это может показаться. В

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Часто задаваемые вопросы:

  1. Часто задаваемые вопросы
  2. Часто задаваемые вопросы
  3. Часто задаваемые вопросы
  4. Часто задаваемые вопросы
  5. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  6. Часто задаваемые вопросы
  7. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  8. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  9. Часто задаваемые вопросы
  10. Часто задаваемые вопросы
  11. Часто задаваемые вопросы
  12. Часто задаваемые вопросы
  13. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  14. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  15. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ