Не пропусти интенсив по Telegram
Методология Kanban: основы
Баженова Маргарита
Директор по развитию LEADHUNTER GROUP
Левина Ильяна
Та самая королева конверсии
Как стать клиенто-ориентированной компанией?
В последние годы набирают востребованность Agile-методологии разработки программного обеспечения, такие как Scrum и Kanban. Известными понятиями пользуются непорядочные «тренеры», поэтому тренинги и семинары стремительно растут.

Во многих некачественных статьях любая методология описывается как способ решения трудностей с коммуникацией и проблем с некомпетентностью некоторых участников команды. То есть, иначе говоря, поможет вам избавиться от всех текущих проблем. На самом деле у каждой методологии разработки ПО есть свои преимущества и недостатки, также у них имеются ограничения по применению.

Часто инструменты методологий трактуют неверно, попросту не понимая, о чем идет речь или применяют модную методологию, не учитывая контекст. В данном материале речь пойдет о технологии Kanban, истории ее появления, главных принципах и возможных границах использования.
История возникновения термина
Термин Kanban появился в Японии, там его стали применять во второй половине XX столетия, говоря о производстве компании Toyota. В основу технологии был заложен метод конвейерного производства и разнообразные темпы выполнения конкретных технологических производственных операций.

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

Также в производственном процессе могут поменяться приоритеты. Например, стало известно, что станция, производящая левые зеркала, выпустила 20 штук готовой продукции, а станция, занимающаяся производством правых зеркал – 10 изделий. В это же время на конвейере расположены 15 машин, на них нужно установить 15 штук зеркал с обеих сторон. Подобная ситуация называется конфликтом метрики – количество изделий не уменьшилось, однако на производстве возникнут задержки, так как дополнительные конвейеры изготовили не ту продукцию. Методология Kanban может помочь в решении таких проблем.

В более простом варианте, Kanban основывается на двух несложных правилах:

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

  • число задач, которые выполняются на станции в одно и то же время ограничено. Это означает, есть возможность изготавливать не больше запрограммированного числа изделий одновременно. Данное ограничение нужно для того, чтобы управлять производственным темпом и скоростью реагирования на корректировки в запланированных действиях.
Scrum и Kanban за 180 слов
Scrum

Разделите организацию на маленькие, кросс-функциональные команды.
Разделите работу на маленькие, конкретные задачи. Отсортируйте этот список по приоритетам и оцените относительный объём работы по каждой задаче.
Разделите время на короткие итерации фиксированной длины (обычно 1-4 недели) так, чтобы после каждой итерации проводилась демонстрация потенциально готового к использованию кода.
Корректируйте приоритеты совместно с клиентом, основываясь на данных, получаемых при рассмотрении релиза после каждой итерации.
Оптимизируйте процесс с помощью проведения ретроспективы после каждой итерации.
Kanban
Визуализируйте поток работ:

  • Разбейте работу на задачи, выпишите каждый из пунктов на карточку и прикрепите на стену.
  • Подпишите столбцы, чтобы видеть, на какой стадии находится каждая задача.

Ограничьте WIP work-in-progress – незавершённая работа – пунктов на каждой стадии рабочего процесса.

Измеряйте время выполнения задачи (lead time) (среднюю продолжительность времени для завершения одного пункта, иногда называемую "оперативным временем" (cycle time)), оптимизируйте процесс, чтобы свести время выполнения задачи к минимуму и сделать его настолько прогнозируемым, насколько это возможно.
Ура, уложились в 100 слов по Kanban и 100 слов по Scrum!
Современный мир
В последние десятилетия Kanban становится все более популярным в производстве программ и приложений. Многие разработчики называют эту методологию очень практичной и выгодной, некоторые применяют ее по принципу «культа Карго». Однако у данной методологии есть один минус – она не совсем подходит для работы продуктовых команд. Зато она прекрасно работает с командами поддержки, такими как:

  • группы поддержки ПО, в которых важен на столько план, сколько темп возможной корректировки приоритетов;
  • группы тестирования, которые работают не вместе с командами разработчиков;
  • службы технической поддержки;
  • иные примеры дополнительных производственных линий.

Также нужно отметить, что Kanban отлично действует в молодых организациях, где отсутствует точный план, но быстро и инициативно проводится разработка. Например, в группе, где один человек трудится над проектом не слишком большого объема, план действий выстроен в приоритетном порядке частей создания, лимит команды на целевые установки в рабочем процессе составляет одну штуку.
Чтобы управлять процессом, начальник проекта способен предпринимать следующие шаги:

  1. менять лимит на число задач в производстве;
  2. добавить новую цель с большим приоритетом, чтобы исполнитель приступил к ее решению как можно быстрее.

В рабочем процессе могут случаться некоторые непредвиденные обстоятельства, которые повлекут за собой блокировку работу. Это может произойти из-за сломавшегося хостинга, отсутствия нужного framework и т.д. В таком случае в разработке начинается отставание, все возвращается к бэклогу, и возникает необходимость выбора новой цели с наиболее высоким приоритетом.

В зависимости от особенностей задач и разновидности команды лимит может увеличиваться или уменьшаться. То есть создатель может в одно и то же время прорисовывать регистрационную форму и наблюдать за процессом создания очередного сервера. Однако если период выполнения задач будет меньше запланированного, начальник проекта должен будет сократить лимит или расширить рабочую группу. Так, при правильном подходе, Kanban может обеспечить высокий темп реагирования на коррективы и уменьшить траты на поддержку методики.

Если говорить об ограниченности сферы применения Kanban'а, можно выделить неудобство его применения в продуктовых командах. Это происходит по следующим причинам:

  • эта методология не очень хорошо функционирует с масштабными рабочими группами (более 5 специалистов);
  • Kanban не очень успешно действует с кросс-функциональными командами, так как трудно соединить тестовый процесс и разработку в одной группе;
  • Kanban не подходит для создания долгосрочных планов.

Резюме

Как и любые инструменты, Scrum и Kanban не универсальны. Они не расскажут вам все. Вместо этого они дают определенные правила, устанавливают ограничения и предписания.

Например, Scrum предписывает фиксированные по времени итерации и кросс-функциональные команды, а Kanban – использование визуализации процесса на доске задач и ограничение НЗР.

Scrum предписывает наличие 3-х ролей: Product Owner (отвечает за видение продукта и приоритеты), Команда (отвечает за реализацию продукта) и Scrum Master (устраняет препятствия в работе и руководит Scrum-процессом). Kanban же не предписывает вообще никаких ролей, но это не значит, что у вас не может быть Product Owner.

Основным посылом как в Scrum-е, так и в Kanban-е является "Чем меньше, тем лучше". Поэтому в случае сомнений начинайте с меньшего.
Читайте ещё на тему
"Основы тайм-менеджмента"