Теория, игра и практика Канбан — Certified Kanban/Lean Training

b2bf858f0fa24a2d9d8b28b24bda5818.jpg

Совсем недавно я начал работать в компании ScrumTrek. Все новички у нас в рамках ввода в строй в обязательном порядке проходят обучение на открытых тренингах компании. И так устроен мой мозг, что хорошо усвоить материал у меня получается только тогда, когда удается внятно донести основные его тезисы другим. Бедная моя жена, коллеги и друзья — сколько им всего пришлось выслушать от меня! Кстати, Ицхак Пинтосевич называет это универсальной методикой системы сверхобучения 3-П.

Итого, по мере прохождения тренингов я буду рассказывать вам про полученные знания глазами участника. Конечно, для компании ScrumTrek это реклама. Хотя лично я надеюсь, что выбранный формат поможет с ответом на вопрос: нужно ли это обучение вам или вашим коллегам?

Непривычно разношерстный состав участников тренинга Certified Lean/Kanban Training в компании ScrumTrek привлек мое внимание только спустя неделю, когда я начал разбирать свои записи. На обучении были представители не только традиционного сегмента: ИТ-компании и банки –, но также промышленной компании и государственного ведомства. А кто сами участники? Разработчик, аналитик, менеджеры проектов, менеджер продуктов, руководители отделов разработки, руководитель отдела кадров, генеральный директор компании. Все мы признались тренеру в малом практическом опыте в Канбан. При этом многие давно и активно применяют Скрам, но сейчас хотят масштабировать процесс с команды разработки на внешние подразделения.

2de1e01e9778437e887c9d30b3b74895.png

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


Канбан — это процесс разработки программного обеспечения? Канбан внедрить относительно просто: достаточно нарисовать поток работ на доске, ограничить WIP, измерять lead time — и никакой работы с людьми не требуется? Если на один из этих вопросов вы ответили или хотели ответить утвердительно, то теорию вам стоит подтянуть.

На самом деле Канбан — это метод улучшения сервиса (процессов), который основывается на 9 ценностях и 3 принципах. Почему это так важно? Возьмем, к примеру, самую неочевидную ценность — понимание. Она говорит о необходимости понять текущие процессы прежде, чем вносить в них изменения. В этом смысле Канбан дистанцируется от реализаций культа Карго. Например, зачастую Скрам-команды прилежно, но слепо (без понимания) исполняют формальные регламенты: есть владелец продукта и Скрам-мастер, прилежно проводятся встречи, есть спринты. Но при этом нарушают основополагающие принципы эмпиризма: прозрачность (к примеру, изолируются от «неприятных» заинтересованных лиц, не приглашая их на демонстрации, избирательно относятся к обратной связи), инспекция и адаптация (к примеру, работающий продукт есть в конце каждого спринта, правда, потребителю он почему-то не нужен, а команда ничего с этим не делает). Следуя этой ценности тренер и давал нам теорию, постоянно задавая нам вопросы на засыпку (понимание).

Например, такая задачка. 2 из 3 полос дороги перекрыты на ремонт, а тут еще и авария происходит. Быстро формируется пробка, среднее время проезда которой составляет 1 час. В это время ремонт дороги до места аварии завершается, поэтому появляются 2 дополнительные полосы подъезда к пробке. Каким будет среднее время ожидания в пробке теперь? А если справа есть широкая обочина, а сама история происходит в России? Во сколько раз в среднем увеличивается скорость движения машин после проезда аварийного участка?

fd838e4ceeeb4b5d83fc706b3d01dac2.png

Или вот пример. Тренер показывает нам видео «ONE PIECE FLOW versus BATCH PRODUCTION», которое убедительно показывает выигрыш в скорости работы малыми порциями. И, кажется, нам всем и все понятно! Но вот очередной вопрос тренера на засыпку: «Выходит так, что можно уволить много народу, если делать работу малыми порциями?» — возвращает нас к необходимости более глубокого осмысления. Правильный ответ: конечно, нет. При работе большими порциями часть сотрудников вынужденно простаивает, поэтому в большинстве компаний их начинают перекидывать туда-обратно между несколькими проектами. Иными словами, конечно же, Канбан не может сделать ту же самую работу быстрее, но он позволяет делать быстрее весь проект в целом, как набор работ, взаимосвязанных в едином потоке.

Конечно, WIP limits, Classes of Services, Cost of Delay, Explicit Policies и прочие базовые инструменты Канбан в лекции также были освещены. Но выше я постарался привести самое интересное из теоретической части — примеры того, как тренер мучал нас для глубокого понимания закона Литтла, а также закона Бернулли и теории ограничений Голдратта.


В целом весь тренинг оказался очень практическим. Теория (лекция) заняла незначительную его часть. Большую часть времени мы играли в игру getKanban. Опишу, как это было, и какие уроки мы вынесли.

481df98af81945daa0a0c291e65793ee.png

Мы разбились на команды по 6 человек: Кабаны (и почему не Канбаны?), Газмяс и Ромашка. Каждой команде ведущий выдал на стол Канбан-доску, разложил на ней бумажки работ, как будто бы идет уже 9 день работы, и поставил задачу: «Ваша компания разрабатывает веб-приложение и зарабатывает на подписчиках. Новые фичи приносят новых подписчиков. Больше подписчиков, больше прибыль. Ваша цель в максимизации прибыли. Ваша задача в оптимизации потока работы».

30515c5e710d4ba0ad269943de9a5c53.png

В течение игры мы отмечали показатели нашей работы на контрольной диаграмме (Run Chart), диаграмме распределения времени выполнения (Lead Time Distribution Chart) и кумулятивной диаграмме (Cumulative Flow Diagram), а также считали прибыль от накопленных подписок.

033cdb7ca41b41049ddcb8faf7ed8480.png

05fd9051a3e643e188a2b04b2d1c0be6.png

59d676366ad943fba2a25621e43575f9.png

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

243d8d749b074f6fa99dfa400919adb9.png

Время за игрой пролетело незаметно! После игры тренер помог нам закрепить наши уроки. Итак, чему мы научились?

  1. Игра позволила прочувствовать механику потоковой работы, опасность накапливания очереди и инерцию ее рассасывания. После тренинга по пути в метро я смотрел на пробку на Садовом кольце, но видел поток. Автомобиль скорой помощи с включенным проблесковым маяком и сиреной ускоренно двигался по Expedite lane. Редиски-водители нарушали движения по полосам, чем увеличивали WIP, помогая пробке расти. Неплохо меня вставило, неправда ли?
  2. Мы увидели, как уменьшение ограничения на количество незавершенной работы увеличивает скорость ее выполнения. Хорошо помню тот момент, когда первый раз Cycle time стал равным одному дню. Ощущение: «Невероятно, вот оно!» Но оставалось легкое недоверие: «Быть может, нам просто повезло в этот раз, это ведь кости?» — как минимум, снижать WIP limits еще больше мы испугались. Но потом успех повторился еще 2 раза подряд. Думаю, что именно в этот момент мы действительно усвоили полученные ранее теоретические знания по Канбану.

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


На второй день мы разбирали реальные ситуации в компаниях, где мы работаем, выстраивая для них Канбан-системы. По разумеющимся причинам приводить детальное описание разобранных случаев не буду.
Судя по составу участников, тренинг полезен не только командам на старте внедрения Канбан в процесс разработки, но и компаниям, которые хотят выстроить прозрачный сквозной процесс. Итого, что дает тренинг в крупную клетку? Теорию с вопросами на понимание. Игру на то, чтобы прочувствовать теорию на практике. Разбор реальных примеров ваших компаний, чтобы применить полученные знания в деле. Ни убавить, ни добавить?

© Megamozg