Совсем недавно я начал работать в компании ScrumTrek. Все новички у нас в рамках ввода в строй в обязательном порядке проходят обучение на открытых тренингах компании. И так устроен мой , что хорошо усвоить материал у меня получается только тогда, когда удается внятно донести основные его тезисы другим. Бедная моя жена, коллеги и друзья – сколько им всего пришлось выслушать от меня! Кстати, Ицхак Пинтосевич называет это универсальной методикой системы сверхобучения 3-П.
Итого, по мере прохождения тренингов я буду рассказывать вам про полученные знания глазами участника. Конечно, для компании ScrumTrek это реклама. Хотя лично я надеюсь, что выбранный формат поможет с ответом на вопрос: нужно ли это обучение вам или вашим коллегам?
Непривычно разношерстный состав участников тренинга Certified Lean/Kanban Training в компании ScrumTrek привлек мое внимание только спустя неделю, когда я начал разбирать свои записи. На обучении были представители не только традиционного сегмента: ИТ-компании и банки – но также промышленной компании и государственного ведомства. А кто сами участники? Разработчик, аналитик, менеджеры проектов, менеджер продуктов, руководители отделов разработки, руководитель отдела кадров, генеральный директор компании. Все мы признались тренеру в малом практическом опыте в Канбан. При этом многие давно и активно применяют Скрам, но сейчас хотят масштабировать процесс с команды разработки на внешние подразделения.
Канбан более универсальный, нежели Скрам? Как иначе объяснить такую разношерстную аудиторию тренинга. При этом Канбан сложнее в освоении? Ведь разработчики приходят к нему, имея за плечами опыт Скрама. Но порог вхождения у Канбан ниже? Ведь его начинают применять вместе с разработчиками и другие подразделения компаний.
Теория
Канбан – это процесс разработки программного обеспечения? Канбан внедрить относительно просто: достаточно нарисовать поток работ на доске, ограничить WIP, измерять lead time – и никакой работы с людьми не требуется? Если на один из этих вопросов вы ответили или хотели ответить утвердительно, то теорию вам стоит подтянуть.
На самом деле Канбан – это метод улучшения сервиса (процессов), который основывается на 9 ценностях и 3 принципах. Почему это так важно? Возьмем, к примеру, самую неочевидную ценность – понимание. Она говорит о необходимости понять текущие процессы прежде, чем вносить в них изменения. В этом смысле Канбан дистанцируется от реализаций культа Карго. Например, зачастую Скрам-команды прилежно, но слепо (без понимания) исполняют формальные регламенты: есть владелец продукта и Скрам-мастер, прилежно проводятся встречи, есть спринты. Но при этом нарушают основополагающие принципы эмпиризма: прозрачность (к примеру, изолируются от «неприятных» заинтересованных лиц, не приглашая их на демонстрации, избирательно относятся к обратной связи), инспекция и адаптация (к примеру, работающий продукт есть в конце каждого спринта, правда, потребителю он почему-то не нужен, а команда ничего с этим не делает). Следуя этой ценности тренер и давал нам теорию, постоянно задавая нам вопросы на засыпку (понимание).
Например, такая задачка. 2 из 3 полос дороги перекрыты на ремонт, а тут еще и авария происходит. Быстро формируется пробка, среднее время проезда которой составляет 1 час. В это время ремонт дороги до места аварии завершается, поэтому появляются 2 дополнительные полосы подъезда к пробке. Каким будет среднее время ожидания в пробке теперь? А если справа есть широкая обочина, а сама история происходит в России? Во сколько раз в среднем увеличивается скорость движения машин после проезда аварийного участка?
Или вот пример. Тренер показывает нам видео «ONE PIECE FLOW versus BATCH PRODUCTION», которое убедительно показывает выигрыш в скорости работы малыми порциями. И, кажется, нам всем и все понятно! Но вот очередной вопрос тренера на засыпку: «Выходит так, что можно уволить много народу, если делать работу малыми порциями?» — возвращает нас к необходимости более глубокого осмысления. Правильный ответ: конечно, нет. При работе большими порциями часть сотрудников вынужденно простаивает, поэтому в большинстве компаний их начинают перекидывать туда-обратно между несколькими проектами. Иными словами, конечно же, Канбан не может сделать ту же самую работу быстрее, но он позволяет делать быстрее весь проект в целом, как набор работ, взаимосвязанных в едином потоке.
Конечно, WIP limits, Classes of Services, Cost of Delay, Explicit Policies и прочие базовые инструменты Канбан в лекции также были освещены. Но выше я постарался привести самое интересное из теоретической части – примеры того, как тренер мучал нас для глубокого понимания закона Литтла, а также закона Бернулли и теории ограничений Голдратта.
getKanban game
В целом весь тренинг оказался очень практическим. Теория (лекция) заняла незначительную его часть. Большую часть времени мы играли в игру getKanban. Опишу, как это было, и какие уроки мы вынесли.
Мы разбились на команды по 6 человек: Кабаны (и почему не Канбаны?), Газмяс и Ромашка. Каждой команде ведущий выдал на стол Канбан-доску, разложил на ней бумажки работ, как будто бы идет уже 9 день работы, и поставил задачу: «Ваша компания разрабатывает веб-приложение и зарабатывает на подписчиках. Новые фичи приносят новых подписчиков. Больше подписчиков, больше прибыль. Ваша цель в максимизации прибыли. Ваша задача в оптимизации потока работы».
В течение игры мы отмечали показатели нашей работы на контрольной диаграмме (Run Chart), диаграмме распределения времени выполнения (Lead Time Distribution Chart) и кумулятивной диаграмме (Cumulative Flow Diagram), а также считали прибыль от накопленных подписок.
По CFD видно, что команда Газмяс к концу игры научилась системно прокатывать любые работы всего за один день! Собственно, это и стало причиной победы Газмяс в общем зачете трех команд.
Время за игрой пролетело незаметно! После игры тренер помог нам закрепить наши уроки. Итак, чему мы научились?
- Игра позволила прочувствовать механику потоковой работы, опасность накапливания очереди и инерцию ее рассасывания. После тренинга по пути в метро я смотрел на пробку на Садовом кольце, но видел поток. Автомобиль скорой помощи с включенным проблесковым маяком и сиреной ускоренно двигался по Expedite lane. Редиски-водители нарушали движения по полосам, чем увеличивали WIP, помогая пробке расти. Неплохо меня вставило, неправда ли?
- Мы увидели, как уменьшение ограничения на количество незавершенной работы увеличивает скорость ее выполнения. Хорошо помню тот момент, когда первый раз Cycle time стал равным одному дню. Ощущение: «Невероятно, вот оно!» Но оставалось легкое недоверие: «Быть может, нам просто повезло в этот раз, это ведь кости?» — как минимум, снижать WIP limits еще больше мы испугались. Но потом успех повторился еще 2 раза подряд. Думаю, что именно в этот момент мы действительно усвоили полученные ранее теоретические знания по Канбану.
На самом деле перечень уроков более длинный. Выше я привел только самые важные уроки (откровения), которые возможно получить только на практике, в данном случае в рамках игры.
Практика
На второй день мы разбирали реальные ситуации в компаниях, где мы работаем, выстраивая для них Канбан-системы. По разумеющимся причинам приводить детальное описание разобранных случаев не буду.
Заключение
Судя по составу участников, тренинг полезен не только командам на старте внедрения Канбан в процесс разработки, но и компаниям, которые хотят выстроить прозрачный сквозной процесс. Итого, что дает тренинг в крупную клетку? Теорию с вопросами на понимание. Игру на то, чтобы прочувствовать теорию на практике. Разбор реальных примеров ваших компаний, чтобы применить полученные знания в деле. Ни убавить, ни добавить?
Автор: ScrumTrek
