Совсем недавно я начал работать в компании 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 раза подряд. Думаю, что именно в этот момент мы действительно усвоили полученные ранее теоретические знания по Канбану.
На самом деле перечень уроков более длинный. Выше я привел только самые важные уроки (откровения), которые возможно получить только на практике, в данном случае в рамках игры.
Практика
На второй день мы разбирали реальные ситуации в компаниях, где мы работаем, выстраивая для них Канбан-системы. По разумеющимся причинам приводить детальное описание разобранных случаев не буду.
Заключение
Судя по составу участников, тренинг полезен не только командам на старте внедрения Канбан в процесс разработки, но и компаниям, которые хотят выстроить прозрачный сквозной процесс. Итого, что дает тренинг в крупную клетку? Теорию с вопросами на понимание. Игру на то, чтобы прочувствовать теорию на практике. Разбор реальных примеров ваших компаний, чтобы применить полученные знания в деле. Ни убавить, ни добавить?
Комментарии (10)
c4ugov
10.03.2016 16:39Но порог вхождения у Канбан ниже? Ведь его начинают применять вместе с разработчиками и другие подразделения компаний…
Спорное заявление, учитывая что в разработку Канбан пришел из производства. Для разъяснения не нужно даже выдумывать примеры: ящики с бирками (собственно «канбанами») на производственных участках Toyota отлично это иллюстрируют.
Askofen
10.03.2016 16:51На заводах концерна Тойота используется Toyota Production System (производственная система Тойота), а вовсе не канбан в том виде, в котором его пытаются поженить с ИТ-отраслью. Использование же общего названия "канбан" ни о какой похожести систем менеджмента не говорит.
Следует также понимать, что Toyota Production System разработана для массового или крупносерийного производства, а разработка программного обеспечения — это даже не мелкосерийное, а штучная разработка (часто на заказ).c4ugov
11.03.2016 09:55Какая разница. Можно еще больше указать различий между автомобилем и ПО, но это все дальше уводит от сути.
Общее название и призвано указать на общую суть.
Естественно есть различия, но цель одна — оптимизировать работу потока.
И бесполезно слушать тренеров, какими бы они не были гуру, пока суть всего этого не понятна.
Тот же Голдратт упоминается в статье, во всех своих книгах он говорит о том, что нужно упрощать и доходить до сути, но нет, мы смотрим на то что отличается игнорируя общее...
T13Nemo
10.03.2016 21:42+1Весьма занятная статья. В рамках этой статьи я бы хотел поднять пару действтиельно интересных для меня вопросов.
Вместо предисловия:
… есть владелец продукта и Скрам-мастер, прилежно проводятся встречи, есть спринты. Но при этом нарушают основополагающие принципы эмпиризма: прозрачность… и т.д.
Это означает только то, что у команды не внедрён scrum и команда не понимает базовых принципов agile (http://www.agilemanifesto.org/). И Kanban не будет серебряной пулей в этом случае. Бардака будет даже больше.
Дальше больше.
Как правильно отметил топикстартер, Kanban — это пара принципов и 4 правила. Четвёртое — придумайте свои правила сами.
И вот тут-то и начинается всё самое интересное.
Meetings? В Kanban нет ни слова о том, что нужно проводить Retro, Daily Standup и т.д. Но, если мы обратимся к Agile-практикам, то мы увидим, что практика проведения данных мероприятий рекомендована для всех команд, которые практикуют Agile.
Таким образом, внедрять Kanban не имея хорошего бэкграунда и понимая принципов и всей базы Agile и проектного управления — не стоит.
Kanban не предполагает оценки задач. Простите, но как же тогда отслеживать control flow — график же будет неравномерным из-за разброса стоимости задачи!
«Приведи их к одному размеру, Люк» — лышен нам голос из зала. Но, подождите, ведь практика scrum нам говорит о том, что задачи с разной оценкой всё-равно будут. А если резать крупные задачи на ещё более мелкие, то как мы в итоге соберём нужную функциональность — у нас увеличивается плотность потока, но снижается % законченности задачи. Непорядок.
«Введи оценку в SP» — говорит тот, что постарше. И, да, в его словах есть смысл. Оценка действительно решает многие проблемы с Control flow, но нужно быть готовым к тому, что поток начнёт двигаться неравномерно — ряд задач будут проскакивать быстро, а другие будут ползти очень медленно.
Таким образом, внедрять Kanban с командой, которая не умеет отлично оценивать — гиблое дело.
Wrong way, задача!
Kanban — прекрасный процесс, если он движется в одном направлении. Но что делать, если задача должна вернуться назад? Например, на этапе QA найдены ошибки и задача должна вернуться назад в разработку?
«DevOps — и нет проблем!» — слышен бодрый голос из зала. Да, и это прекрасный выход! Таким образом процесс у нас всегда будет идти в одном направлении, теоретически… Но, подождите, почему у нас DevOPS-команда такая же большая, как и команда основной разработки? Где, чёрт возьми, оптимизация?
«Используй тесты, Люк» — говорит седовласый участник дискуссии. Да, это действительно поможет сократить количество задач, которые будут возвращаться. Не исключить, но существенно сократить, при условии, что культура написания тестов хорошо развита.
Остаётся открытым вопрос как организовать процесс таким образом, чтобы задачи не возвращались. Т.к. любое движение назад — это всегда заваливание WIP-Limits причём сразу нескольких этапов — того, на который вернули, предыдущего, т.к. на него вернут те задачи, которые разрабы отложат, чтобы решить вернувшуюся.
В итоге, стройный Kanban-ряд будет сломан.
Таким образом, Kanban очень сильно подвержен порождению хаоса в случае возврата задачи на предыдущие этапы. Переброс «свободных специалистов» (например, разработчиков в помощь тестерам) — не решает проблему в комплексе т.к., как мы выяснили на этапе 1, поток движется неравномерно и лимиты будет очень сложно спрогнозировать.
Expedite за Expedit'ом. И вот мы подошли к самой интересной части. Мы имеем — заваливаемые этапы работы из-за возвращения задач и неравномерную скорость движения потока из-за разного объёма задач. В итоге, наш Backlog может начать плавать — из-за того, что в работе находятся большие задачи и нет возможности взять ещё одну большую. И, как результат, начинают появляться Blocker — задачи «ну они же маленькие», которые ещё больше заваливают основной процесс. В итоге, может появиться задачи, которые залипнут на доске очень и очень долго.
Подытожим.
Kanban — это сложная методология, которая в процессе внедрения потребует намного больше знаний и мотивации у команды, чем Scrum. Маловероятно, что получится внедрить Kanban на мало-мальски технически сложном проекте, если команда недостаточно зрелая.
«А зачем нам вообще Kanban, Зин?» — спросит читатель.
На самом деле, Kanban — это отличная практика, если вы хотите построить у себя CI.
Но, поскольку Continious Integration — достаточно сложная инжинерная практика, то и сам Kanban выходит непростым.
Я бы расставил этапы зрелости команды в таком порядке:
code and fix, waterfall, code and fix, scrum, scrumban, #noestimates.
А статья, конечно, замечательная… Вот только ответов на ключевые вопросы в ней нет.
rsn81
11.03.2016 08:45Все верно, но задачи по Кабан-доске могут двигаться только вперед. Это основа вытягивающей системы задач, вместо проталкивающей. Задача из столбца тестирования не возвращается обратно, вместо этого разработчики подключаются к этой задаче, переключаясь с задач в столбце разработка. Столбцы доски описывают стадию задачи, но не являются разграничением зон ответственности функциональных специалистов.
А так, да, чаще всего вначале внедряется, так называемый, прото-Канбан.
В задачи этой заметки, конечно, не входило рассмотрение всех вопросов теории Кабан.
Askofen
Проблема в том, что все эти примеры с автомобильным движением, пробками, командами типа "Газмяс" и прочее оторваны от реальных программных проектов. Серьёзно любую методологию управления проектами можно обсуждать только после того, как она опробована в жизни на реальном проекте.
При таком обсуждении интересуют не общие слова о ценностях и не формальная схема типа "потока работ" — это может быть интересно разве что студентам, а не профессионалам, поучаствовавшим в десятках проектах. Интересна специфика, которая может свидетельствовать как за, так и — главное — против обсуждаемой методологии ведения проектов.
К таким специфичным деталям относятся информация о продукте, сложность проекта, время проекта, размер команды, междисциплинарное взаимодействие (сколько и каких специалистов было задействовано на проекте, как они взаимодействовали). Например, при создании видеоигры в работе над проектом участвуют люди совершенно разных специальностей: программисты, продюсеры, гейм-дизайнеры, моделлеры, аниматоры, 2Д-художники, технические аниматоры, аудиодизайнеры, инженеры по качеству и т.д. и т.п. Специальностей будет больше, чем при создании бизнес-софта. Как построено взаимодействие между этими людьми? Как они находят общий язык между собою? Как методология помогает в этом?
А примеры с дорожным движением — это для детей.
rsn81
2 день обучения был практически полностью посвящен разбору реальных примеров компаний, в которых работают участники тренинга. На том тренинге, где побывал я, в одной группе разбирался пример одной известной интернет-компании с участием самого генерального директора этой компании, а в другой группе — пример одного прогрессивного государственного ведомства. Примеры реальные и масштабные. По разумеющимся причинам приводить детальное описание этой части тренинга я не могу.
;-)А про эффективность наглядных примеров как для детей, так и для профессионалов с 10 проектами за плечами, хорошо сын божий сказал:
numberfive
«По разумеющимся причинам приводить детальное описание этой части тренинга я не могу.»
а вы приняли на себя обязательство по неразглашению информации?
априори, всё что рассказывается на общедоступном треринге широкой аудитории — публичная информация, если иное не оформлено бумажно.
rsn81
Просто не считаю это приемлемым.
Askofen
Не с десятью проектами, а с десятками завершённых проектов. На текущий момент это 40 проектов.