Методология Lean, о которой мы говорили ранее, выглядит немного абстрактной с точки зрений управления проектами, но если к ней добавить метод Kanban, который является достаточно конкретным и соединить их, о как раз получится вполне себе конкретный, понятный инструмент с точки зрения управления проектами. Метод Kanban был разработан в 1957 году инженером компании «Toyota» — Таичи Оно и достаточно сильно похож на схему промышленного производства. Если совсем грубо представлять процесс управления создания продукта тем или иным проектом с точки зрения методики Kanban, то на воде мы можем иметь какой-то кусок металла, а на выходе готовую деталь для использования в производстве. Kanban инкремент продукта передается с этапа на этап и только в конце получается готовый к использованию элемент, то есть продукт. Создатель Kanban известен своим вдохновением от супермаркетов и именно он является создателем или автором принципа «держи на полках то, что нужно клиенту». Именно поэтому в Kanban, например, разрешается оставить не законченную задачу на одном из этапов проекта и перейти к другой задачи более приоритетной или возможно новой, в связи с появившимися изменениями и начать ее делать. Если приоритет меняется, то незаконченная статья для блога, недописанный код, подвешенная без даты публикация или часть публикации на сайты компании, все это вполне себе допустимо методологией Kanban, в случае если приоритеты меняются. Если сравнивать Kanban, с известной нам с вами, методологией Scrum, то Kanban намного менее строгий нежели чем Scrum. Нет конкретных ролей, за исключением владельца продукта, отсутствуют конечные даты, то есть нет такого четкого и жесткого ограничения спринтов, как в Scrum. Но при этом Kanban позволяет команде вести несколько задач одновременно, в отличие от Scrum и Kanban гибкий с точки зрения взаимодействия команды, то есть не ограничивает и не регламентирует частоту встреч и их некий сценарий проведения. Встречи в методологии Kanban, когда этого требует некая стадия завершения промежуточного или финального с точки зрения создания продукта и как правило владелец продукта назначает и инициирует подобные встречи. Чтобы работать с Kanban нам необходимо определить этапы потока операций, так называемые Workflow. В Kanban они изображаются, как столбцы, а задачи изображаются в виде карточек. Карточка перемещается от столбца к столбцу, то есть от этапа к этапу, подобно детали на заводе, которая переходит от станка к станку и на каждом этапе процент завершения той или иной задачи становится выше. По итогам мы видим, что задача выполнена. Если говорить про подобную, типовую доску Kanban, то она может быть, как создана вручную и повешена, например, открытом Open Space пространстве офиса, где работает команда над проектом Kanban, либо она может быть электронной. Сейчас существует достаточно большое количество различных сайтов, где вы можете вашей командой создать, вот эту доску Kanban, в электронном виде и каждый из членов команды перемещает, по мере завершения того или иного этапа, свои задачи, то есть карточки, из столбца в столбец. Здесь уже команда и владелец продукта, вместе решают, как лучше поступить. Система Kanban, вами может быть использована на столько гибко, насколько вы хотите, чтобы она была гибкой. Пожалуй, Kanban можно назвать лучшей визуализацией идеи Agile. Kanban обладает 4 столпами, на которой держится вся идея данной методологии. Если не научиться правильно и эффективно применять эти столпы, принципы метода Kanban, то пожалуй, не всегда мы сможем получить качественный эффект от использования методологии. Для каждой задачи в Kanban, существует своя карточка, в которую заносится вся необходимая информация о задачи в рамках проекта. Таким образом, весь перечень задач, в рамках реализации проекта, всегда по рукой. Ограничения на количестве задач. Количество карточек с задачами, в одном столбце, то есть на одном этапе, строго регламентировано. Непрерывный поток. Задачи из Back Lock попадают в поток, то есть на этап на карточке в задаче, порядке своего приоритета. Таким образом Kanban обеспечивает непрерывность реализации того или иного процесса и работы над проектом. Постоянно улучшение. Здесь авторы и пользователи методики Kanban прибегают к методологии «кайзен» (kaizen), которая говорит нам о непрерывном совершенствовании того или иного процесса или продукта. То есть, когда мы создали некий продукт, мы все равно за ним следим, смотрим, как работает и постоянно ищем пути совершенствования, обеспечивая тем самым конкурентоспособность и постоянную ценность для конечного клиента, нашего продукта или услуги, которые мы создаем в ходе того или иного проекта. В отличие от Scrum, Kanban не работает в продолжительном периоде. То есть, если Scrum мы можем создавать большое количество спринтов, пока не получим лучший продукт, конкурентноспособный, то Kanban более ориентирован на краткосрочные проекты, в которых мы можем достаточно быстро отследить результат и условно выход из процесса, продукта или услуги, которые мы совершенствуем. Kanban, как и Scrum подходит для сплоченных с высокой, качественной коммуникацией команд. В отличие от Scrum, как я уже сказала ранее, Kanban не имеет четких ролей и вот здесь, как раз способность договариваться, качественно коммуницировать, самостоятельно ориентироваться на дедлайн и иметь высокую мотивацию выпустить хороший продукт по итогам проекта это, пожалуй, важные и основные качества членов команд, которые работают по методологии Kanban. Важно, быть замотивированным и опытным командным игроком, для того чтобы получить необходимы результат. Говоря о Kanban, важно помнить, что данная методология все-таки подходит для проектов, где нет очень жестких дедлайнов. Здесь ответственность на реализации и выполнении того или иного проекта, лежит строго на команде проекта. И как я сказа ранее, очень важно чтобы они обладали высокой мотивацией, как командные игроки ориентированы на результат и высокозамотивированы, из, по сути, никто не контролирует, исключительно на собственном опыте и личных качествах достигаются высокие результаты методологии Kanban. В отличие от Scrum, где все-таки спринты и ретроспективы достаточно жестки с точки зрения сроков и контроля, хоть это и гибкий так же подход, как и Kanban, поэтому Scrum больше подходит для проекта, где есть четкие, четкие сроки, а Kanban, там, где сроки не настолько в приоритете, в приоритете качество и улучшение. Именно поэтому мы соединяем Lean и Kanban.
