мури

– перегрузка, или ожидание необоснованных либо невозможных вещей.

Хотя есть много различий между разработкой программного обеспечения и производством автомобилей, Поппендик признали, что идеи бережливого производства имеют место в программных проектах. Поэтому логично предположить, что если команды разработки ПО сталкиваются с проблемами, похожими на те, что встречаются в промышленном производстве, то и решения, подходящие для производителей автомобилей, будут полезны и для команд программного обеспечения. В промышленности таким решением является вытягивающая система (также известная под названием «точно-в-срок»).

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

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

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

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

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

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

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

Система вытягивания – это лучший способ удалить неравномерности и предотвратить перегрузки.

Первым шагом в создании системы вытягивания должно стать разделение работы на маленькие вытягиваемые куски. Таким образом, вместо создания большой спецификации команда может разбить ее на минимальные маркетинговые функции – скажем, отдельные пользовательские истории и, возможно, небольшие фрагменты документации, сопровождающей каждую историю. Затем эти истории будут утверждены по отдельности. Как правило, когда процесс просмотра и согласования спецификации затягивается, причина в том, что люди имеют проблемы с некоторыми функциями. (Способны ли вы понять, как разделение работы на более мелкие ММФ дает команде больше возможностей? Это вариантное мышление.) Утверждение индивидуальных ММФ должно привести к быстрому получению одобрения как минимум для нескольких функций. Как только первая ММФ утверждена, команда может начать работать над ней. Теперь не нужно строить предположений. Вместо этого начинается реальное обсуждение той работы, которую требуется выполнить. Процесс утверждения может иметь под собой реальные основания (например, нормативное требование регулятора или подлинную необходимость узнать точку зрения каждого), теперь команда может получить реальный сигнал начать работу.

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

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

Еще по теме мури:

  1. Вспомогательная аксиома № 15. Никогда не пытайтесь спасти плохие инвестиции за счет усреднения
  2. Спекулятивная стратегия
  3. Основная аксиома № 12
  4. О планировании
  5. Вспомогательная аксиома № 16. Избегайте долгосрочных инвестиций
  6. Спекулятивная стратегия
  7. Основная аксиома № 11
  8. Об упорстве
  9. Спекулятивная стратегия
  10. Основная аксиома № 10
  11. О консенсусе
  12. Вспомогательная аксиома № 14. Никогда не следуйте чужим прихотям. Часто наилучшее время для покупки наступает тогда, когда никто другой этого не хочет
  13. Спекулятивная стратегия
  14. Основная аксиома № 9