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

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

Устраняем потери

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

Спросите себя: «Что мешает выполнить работу?». Задавая этот вопрос, вы анализируете свои процессы с точки зрения клиента. Что клиент хочет от этого процесса? Клиент может быть конечным потребителем или внутренним клиентом на следующем этапе производства. То, что хочет клиент, имеет ценность. Все остальное будет потрачено впустую. Некоторые шаги в процессе добавляют ценность, другие не добавляют. Это верно для всех процессов.

Сначала Toyota определила семь категорий потерь, которые применяются для производства. С тех пор различные отрасли выработали категории потерь для своего конкретного контекста. Мэри и Том Поппендик сделали это для разработки программного обеспечения в книгах: «Lean Software Development: An Agile Toolkit» и «Бережливое производство программного обеспечения. От идеи до прибыли».

Семь потерь при разработке программного обеспечения

  • Частично выполненная работа. Работа, которая еще не выполнена полностью, в действительности является просто незавершенной работой.
  • Излишняя функциональность – Тайити Оно сказал: «Нет больших потерь, чем перепроизводство». Многие производимые в мире программы на самом деле не используются и не ценятся заказчиком. Согласно известному докладу CHAOS, 45% возможностей программных приложений никогда не используются. Это говорит о том, что можно избежать большого количества отходов при лучшем понимании того, что нужно клиенту.
  • Повторное обучение. Разработка программного обеспечения – это, в значительной степени, обучение. Неспособность вспомнить ошибки, которые вы сделали раньше, и необходимость их переделывать (и заново изучать решение) – большая трата.
  • Передача. Когда вы передаете работу от одного человека другому, создается много дополнительной работы, чтобы передать необходимую информацию следующему человеку. Даже с этой дополнительной работой много информации будет потеряно при передаче.
  • Задержки. Задержки создают дополнительную работу.
  • Переключение внимания на другие задачи. Убедитесь, что вы всегда работаете только над одной или максимум двумя задачами.
  • Дефекты. Дефекты – это работа, которая возвращается к вам, потому что в первый раз вы сделали что-то не так. Это не только создает дополнительную работу, но обычно такая работа приходит в неподходящее время.

Способы создания равномерного потока

Ограничьте работу в процессе

Ограничение работы в процессе, безусловно, является важной практикой. Чем меньше процессов, тем быстрее будет выполняться работа и тем больше возможностей для улучшения вы откроете. Возможно, вы помните закон Литтла, который гласит, что чем больше у вас работы в процессе, тем больше времени затрачивается на каждый элемент.

Сокращаем время ожидания

Есть ли у вас рабочие элементы, которые располагаются в столбцах «Готово» на канбан-доске и ожидают перехода в следующее состояние? Элементы, находящиеся в таких состояниях, как Waiting to Deploy или Todo? Нет ничего необычного в том, что элементы работы тратят больше времени на ожидание, чем на работу над ними. Как можно сократить это время ожидания?

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

Убедитесь, что работа готова

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

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

Сделайте рабочие элементы меньше по размеру

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

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

Устраняйте блокаторы (blockers)

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

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

Пример роения в канбан

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

“Роение” также можно использовать для описания общего поведения за пределами вашей специализации. Чтобы ускорить выполнение работ с высокой ценностью или сократить общее количество работы в процессе. Такое поведение высоко ценится многими командами в Agile методологиях.

Избегайте переделывания

Одним из ключевых принципов разработки программного обеспечения Lean является повышение качества с самого начала. Хороший способ сделать это – инвестировать в технические практики, такие как парное программирование, разработка через тестирование, непрерывная интеграция и автоматизация тестирования.

Дефекты не единственные причины, которые вызывают переделывание. Джон Седдон ввел концепцию неудачное требование.

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

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

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

Случай когда на канбан-доске много дефектов, вместо фич

Кросс-функциональные команды

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

Стремление сделать команды кросс-функциональными помогает сократить время ожидания, устранить блокаторы и избежать переделок. Это также может снизить WIP. Другими словами, это отличный способ ускорить работу.