Портал №1 по управлению цифровыми
и информационными технологиями

Возврат в системе канбан

В идеальном мире, в производственной системе, построенной по принципу вытягивания, задачи (ticket, work item) двигаются по потоку создания ценности слева направо, а информация справа налево. На доске канбан это будет соответствовать движению элементов (стикеров) только слева направо.
Но вот беда. Мир неидеален. Обнаруживаются дефекты и прочие причины, по которым часть работы в рамках решения задачи, приходится переделывать. Как это отображать на доске?
Варианты, с которыми доводилось сталкиваться, можно свести к следующим.

  1. Задача остаётся на том месте, где выявлена необходимость в переделке (например, на этап тестирования). Необходимые ресурсы (например, разработчик) привлекаются для исправления ситуации, чтобы как можно скорее обеспечить дальнейшее движение задачи по потоку. Ведь эта задача — «блокер», поскольку блокирует поток (о чём мы делаем отметку, используя те правила визуализации, о которых нужно явно договориться). В этом варианте движения задачи «против потока» нет. Но то, насколько эффективной будет такая визуализация сигнала о необходимости привлечения ресурса, зависит от того, как у нас построенная практика работы с блокерами. Обычно анализ блокеров происходит в т.ч. на так называемых kanban meetings ежедневно (aka daily meetings). Всегда ли нам достаточно такой частоты, или хотелось бы передать сигнал быстрее? И, если быстрее, то насколько в нашей команде приемлемо прямое обращение к коллеге для привлечения внимания? Заметим, что это уже не столько про систему канбан как средство визуализации, сколько про команду, как группу эффективно взаимодействующих специалистов. Про культуру в том числе.
  2. Задача возвращается на тот этап потока создания ценности, на котором требуется переделка. Обычно это сопровождается отметкой о возврате для последующего анализа и совершенствования нашей производственной системы. Здесь всё более-менее понятно, поскольку возврат происходит явно. Правда, «ломается» течение потока. В т.ч. усложняется работа с WIP-лимитами. Встречаются два варианта обработки: мы не учитываем возвраты при контроле лимитов (что несколько искажает смысл WIP-лимитов); или мы допускаем превышение лимитов, что усложняет их использование.
  3. Задача остаётся на месте (как в варианте №1), создаётся дочерняя задача на переделку, которая отправляется туда, где переделка должна быть выполнена. Здесь будет комбинация плюсов и минусов предыдущих вариантов. У нас явно визуализирован блокер. Но зато (привет У. Оккаму) у нас появилась дополнительная сущность, а, следовательно, нам нужно контролировать связь между родительским и дочерним объектами. В системе автоматизации это не проблема. Но, например, для физической канбан-доски такой вариант, возможно, будет сложноват. Ну, и сказанное в п.2 про WIP-лимиты относится и к этому сценарию.
    Кстати, если передать дочернюю задачу вместе с родительской, то это фактически вариант №2. Хотя, например, Д. Андерсон и Т. Божева в описании модели зрелости канбан-систем (KMM) говорят о том, что именно такой сценарий характерен для системы более высоких уровней зрелости (4-й или 5-й).

Вроде бы других вариантов нет. Или есть?
Кажется, в большинстве случаев подойдёт второй вариант (его упомянутые авторы относят ко второму уровню зрелости [это хуже чем 4 и, тем более, 5 😊]).

А как поступаете вы?
Есть способы и/или аргументы помимо перечисленных?

«Kanban Flow Metrics: управление потоковым производством на основе данных»
Тренажёр про метрики на реальных примерах

Комментариев: 7

  • По моему опыту важный фактор, который следует принять во внимание – скорость потока. Если задачи “ползут” медленно, дни и недели, то есть смысл думать про способ 2. Если же задачи “бегут” быстро, единицы дней, то второй способ создаёт лишние требования, лишнюю нагрузку, взамен не давая полезной информации, а потому используется способ 1.

    Плюс, разумеется, “выбор” способа зависит от уровня ответственности (зрелости, если хотите) команды и понимания гигиены тех же объектов учёта и их статусов.

    • [22.12.2021 отредактировал п.2. Там «не всё так однозначно» (с). Во всяком случае функция точно не монотонная. Удалять не стал, чтобы не терять из обсуждения и можно было вернуться.]
      Ну, вот! Опять “зрелость” 🙂
      Я, конечно, сам виноват. Первым начал – написал в заметке “культура”.
      Попробуем как-нибудь в матерелЬяной плоскости всё разложить?

      Не возвращать, а привлечь нужный ресурс быстрее, если условное “эй ты, иди сюда” будет принято/обработано (“эй ты”, грубо говоря, “встанет и пойдёт сюда”) быстрее, чем, если бы задача дожидалась в очереди этого самого “эй ты”. Даже если бы она была с самым высоким приоритетом (в крайнем случае expedite). Верно?
      Это возможно при стечении следующих обстоятельств.
      1. У нас в команде такие коммуникации норма. Все готовы, понимают, откликаются.
      2. Это отвлечение/переключение (что само по себе потери – «переключение контекста», muda, не побоюсь этого слова) есть меньшее зло, чем ожидание. Что, похоже, возможно, когда время такта большое. Т.е. удельная доля потерь, вызванных переключением контекста ниже. Но так будет только в медленном потоке, а не в быстром.
      Что упустил?

      Я, собственно, очень ЗА быструю обратную связь. Понятно, что вместо того, чтобы быстро делать ерунду и быстро спускать это в… далее по потоку, лучше быстро выявить это и остановить/поправить. Но почему для этого нужно привлекать коллегу с другой этапа, оставляя задачу на текущем. Чем это такая обратная связь лучше, чем обратная связь в виде: «От тебе ещё задача в очередь. С высоким приоритетом. Это то, что было сделано, но требует [пере/до]делки»?
      Понятно также, что, если такое происходит нечасто (редко!), то проще не городить огород, а «просто поговорить». Но до этого состояния нужно ещё дойти. Или именно это подразумевается под зрелостью команды – у них возвраты происходят редко?

      На самом деле (я просто не успел сформулировать это в заметке) обсуждаемые варианты различаются с точки зрения смысла размещения задачи в той или иной колонке канбан.
      В случае, когда мы возвращаем задачу, наше средство визуализации отражает реальное состояние дел. Если в рамках решения задачи какую-то часть работы нужно переделать на предыдущем этапе потока, задача (её карточка) перемещается на этот предыдущий этап. Это ломает поток? Да. Но не перемещение карточки его ломает. А факт некорректно выполненной работы. Возврат карточки лишь визуализирует этот факт, делает его явным.
      Если же мы задачу не возвращаем, оставляем на этапе, где была выявлена потребность в переделке, но занимается ею коллега с предыдущего этапа, то что нам говорит наша визуализация. Каков смысл нахождения карточки задачи в колонке этапа, на котором прямо сейчас в рамках этой задачи никакой работы не выполняется?

      • Михаил

        Я бы не стал делить людей на колонки. Это влечет за собой одну большую проблему. В команде начинают кидаться какашками друг в друга. Типа это на твоей стороне косяк. Я то хорошо работаю. Ну или еще хуже: это аон тот тормозит весь процесс. У меня то все хорошо, нет задач в МОЕЙ колонке. Я молодец.
        Задачи общие, колонки лишь говорят до какого момента задача дошла.

      • Михаил

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

  • Михаил

    Есть интересный фактор. Тикет или задача – это накопление знаний по какому-то вопросу. Исходя из этого, нет смысла двигать тикет назад. Визуализация ломается и мы перестаем видеть на доске то, для чего это доску делали.

    • Михаил, любопытное соображение. Поясните, пожалуйста, как оно влияет на выбор варианта возвращать/не возвращать?
      Допустим, что в описании задачи накапливается информация по мере её решения (канбан как визуализация не для этого [не для отражения ВСЕЙ информации], особенно канбан физический; но допустим – тем более, что в системе автоматизации это чаще всего именно так [хотя это уже не совсем про визуализацию]). Почему в этом случае не смысла двигать назад? Ведь, двигая назад, мы передаём тому, кому нужно поработать над этой задачей (ещё раз) всю необходимую информацию. Нет?
      Похоже в логической цепочке пропущено какое-то звено. Поясните, пожалуйста.

      • Михаил

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


Добавить комментарий для МихаилОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM