муда – работа, которую вы должны делать, хотя она не добавляет ценности. Случалось ли вам сидеть, ожидая кого-то, чтобы получить работу? Это мура – неравномерность, или работа, происходящая урывками. А как насчет сверхурочных или работы по выходным, потому что вам надо было сделать больше, чем позволяют человеческие силы? Это мури – перегрузка, или ожидание необоснованных либо невозможных вещей.
Хотя есть много различий между разработкой программного обеспечения и производством автомобилей, Поппендик признали, что идеи бережливого производства имеют место в программных проектах. Поэтому логично предположить, что если команды разработки ПО сталкиваются с проблемами, похожими на те, что встречаются в промышленном производстве, то и решения, подходящие для производителей автомобилей, будут полезны и для команд программного обеспечения. В промышленности таким решением является вытягивающая система (также известная под названием «точно-в-срок»).
В 1950-е годы производственный коллектив Toyota возглавлял Тайити Оно. Он признавал, что трудно предугадать заранее, какие запчасти будут в дефиците, – часто оказывалось, что это самые разные детали. В этом заключалась первопричина потерь (муда, мура и мури). Поэтому они придумали систему, при которой на каждой сборочной линии специальные станции сигнализировали о готовности к большему количеству деталей группе, созданной для их поставки на основе этих сигналов. Каждая станция должна иметь небольшие очереди из запчастей, в которых нуждается производство. Вместо того склада, который выталкивал запчасти на линию, появилась линия, вытягивающая детали и бравшая их только тогда, когда запас в очереди сильно снижался.
Это называется вытягивающая система, потому что она состоит из отдельных независимых групп или членов команды, которые вытягивают лишь нужные им запчасти (вместо большого регулярно пополняемого запаса деталей, проталкиваемых к ним). Toyota и другие автопроизводители обнаружили, что процесс сборки стал значительно быстрее и дешевле, потому что избавился от огромных потерь и времени на ожидание. Действительно, каждый раз, когда определенный элемент потерь выявлялся, им удавалось сделать небольшое изменение в процессе с целью его ликвидации.
Системы вытягивания очень полезны для создания программного обеспечения – именно по той же причине, по которой они нужны на производстве. Вместо того чтобы пользователи, менеджеры либо владельцы продуктов проталкивали задачи, функции или запросы в направлении команды разработки, они добавляют их в очередь, из которой команда сама их вытягивает. Когда работа возвращается, вызывая неравномерность в середине проекта, они могут создать буфер, чтобы сгладить ее. Команда способна поддерживать несколько различных очередей и буферов в течение проекта. И как оказалось, это очень эффективный способ сокращения времени ожидания, удаления потерь и оказания помощи пользователям, менеджерам, владельцам продуктов и командам разработки в принятии решения о том, какое программное обеспечение уже готово.
Вот очень простой пример того, как система вытягивания может решить знакомую проблему: команде разработчиков ПО приходится ждать, пока каждая функция будет описана в большой спецификации, которая затем должна пройти через сложный процесс обзора и согласования. Может быть, этот процесс – способ получения всех перспективных мнений от каждого человека либо попытка спасти собственную шкуру, когда руководители и заинтересованные стороны боятся взять на себя ответственность. Это также может быть частью культуры компании, которая всегда так поступала, не думая о расточительности подобного поведения. Как бы выглядел этот процесс, если бы мы заменили его простой системой вытягивания?
Рис. 8.10. Эта карта потока ценности показывает потери, которые происходят, когда вся команда ждет большой спецификации, которая должна быть создана и утверждена
Это очень знакомая проблема, и в реальном мире многие команды нашли способы обойти ее. Например, дизайнеры и архитекторы могут сделать предпроект, основанный на раннем черновике спецификации и их лучших предположениях о том, что они будут создавать. Но время, которое команда тратит на поиск способов устранения потерь, она могла бы использовать гораздо продуктивнее. Она по-прежнему будет нести потери, часто и много, особенно если ее догадки окажутся неверными и ей придется отменить некоторые из предпроектных решений.
Система вытягивания – это лучший способ удалить неравномерности и предотвратить перегрузки.
Первым шагом в создании системы вытягивания должно стать разделение работы на маленькие вытягиваемые куски. Таким образом, вместо создания большой спецификации команда может разбить ее на минимальные маркетинговые функции – скажем, отдельные пользовательские истории и, возможно, небольшие фрагменты документации, сопровождающей каждую историю. Затем эти истории будут утверждены по отдельности. Как правило, когда процесс просмотра и согласования спецификации затягивается, причина в том, что люди имеют проблемы с некоторыми функциями. (Способны ли вы понять, как разделение работы на более мелкие ММФ дает команде больше возможностей? Это вариантное мышление.) Утверждение индивидуальных ММФ должно привести к быстрому получению одобрения как минимум для нескольких функций. Как только первая ММФ утверждена, команда может начать работать над ней. Теперь не нужно строить предположений. Вместо этого начинается реальное обсуждение той работы, которую требуется выполнить. Процесс утверждения может иметь под собой реальные основания (например, нормативное требование регулятора или подлинную необходимость узнать точку зрения каждого), теперь команда может получить реальный сигнал начать работу.
Вот так все принципы бережливого мышления – видение целого, выявление потерь и создание системы вытягивания для устранения неравномерности и чрезмерных нагрузок – могут собраться вместе, чтобы помочь команде усовершенствовать работу. Но это только начало. В следующей главе вы узнаете о том, как применить lean-мышление, чтобы улучшить способ, при помощи которого команда создает программное обеспечение.
Минимальная маркетинговая функция (ММФ) – самый маленький «кусок» ценности или функциональности, который команда способна поставить, например пользовательская история или запрос пользователя – то, что может закрыть пункт в бэклоге владельца продукта.
Карта потока ценности – это визуальный инструмент, помогающий lean-команде реально увидеть, как работает проект, показывая весь жизненный цикл ММФ, в том числе время работы и время ожидания на каждом этапе.
Понимание первопричин проблемы поможет вам увидеть ее в целом. Метод пяти «почему» – эффективный способ сделать это.
Полезный инструмент, помогающий команде поставлять как можно быстрее, – WIP-диаграмма, визуальный инструмент, который показывает, как ММФ следуют через поток создания ценности проекта.
Есть три важных вида потерь, которые ограничивают рабочий процесс: муда (потери), мура (неравномерность) и мури (необоснованность и невозможность).
Информация о том, как выполнять проекты, кажется полезной, но мне до сих пор трудно понять, как это влияет на мою повседневную работу. Как может Lean помочь в моей работе?
Обычно нам не нравится слушать теоретические рассуждения – когда говорят нечто подобное, это обычно признак того, что не видят здесь возможности немедленного практического применения. Однако во многом это на самом деле правда о Lean, так как Lean – это мышление. Оно не включает практик, которые ваша команда могла бы применять ежедневно, как Agile-манифест или Scrum и XP-ценности. Но, как и Agile-манифест, Scrum и XP-ценности, Lean является правильным мышлением, очень ценным для команды, если вы хотите лучше писать программное обеспечение.
В главе 2 мы ввели идею раздробленного видения. На протяжении всей книги вы видели много примеров, как это приводит к тому, что команда либо получает результат «лучше-чем-ничего», либо (в худшем случае) приходит к полному провалу проекта. Бережливое мышление помогает вам взглянуть с высоты птичьего полета не только на проект, но и на всю команду, компанию, ее правила, политику и культуру, которые вызывают у вас серьезные проектные проблемы.
Вернемся в начало этой главы и посмотрим на lean-ценности еще раз. Эти ценности помогут взглянуть на ту работу, которую вы делаете прямо сейчас.
Как только вы начинаете искать потери, вы замечаете их повсюду («устраняйте потери»). Вы перестаете видеть программу как набор отдельных задач и начинаете воспринимать ее как систему («видеть целое»). Вы будете использовать такие инструменты, как «пять “почему”», чтобы выйти за пределы фиксации отдельных проблем в работе, которую сделала команда, и распознать системные проблемы, влияющие на проект снова и снова («усиление обучения»). Каждая lean-ценность изменяет способ, которым вы смотрите на проект, команду и компанию. Это поможет вам увидеть более широкую перспективу.
В главе 9 вы узнаете, как обзавестись этой новой точкой зрения и использовать ее для реальных, постоянных изменений, чтобы улучшить создаваемое вами программное обеспечение.
Вы сказали, что «мури» может переводиться как «невозможно», но разве это не отрицание? Ведь считается, что все возможно при наличии мотивированной команды, верно?
Если бы только это было правдой. Проведем мысленный эксперимент, чтобы показать вам, что некоторые вещи действительно невозможны.
Представьте себе, что CEO вашего небольшого стартапа заходит в офис и говорит, что ваш самый крупный клиент зациклен на Бруклине. Руководитель кладет пакет зубочисток и палочек для мороженого на стол и сообщает: если ваша команда сможет сделать идеальный макет Бруклинского моста из зубочисток и палочек для мороженого к моменту появления клиента, то тот утроит бизнес компании и сделает вас богатыми. Если же работа не будет выполнена на отлично, то он уйдет к конкуренту, и тогда вашей компании конец.