Почему стоит выбрать Kanban?

От выбора подходящей методологии разработки зависит будущая жизнь продукта или услуги. В этой статьей будут рассмотрены преимущества Kanban для разработки программного обеспечения.

[sendpulse-form id=”278″]

Что такое Kanban?

Разберем следующий пример.

Шоурум Toyota в наши дни. Покупатель выбирает модель и вносит оплату. Однако на складе Toyota в этот момент нет вашего цвета автомобиля. Заказ отправляется в головной офис Toyota. Вам сообщают сроки, когда машина будет доставлена. Только с этого момента автомобиль начинают производить. Специально для вас. Налицо принцип: сперва продажа, потом производство. Другими словами, работает принцип точно в срок just in time (JIT). Сперва цели и сроки, затем план и работа.

Складские запасы Toyota не будут переполнены, у них не будет необходимости долго хранить заранее произведенные запчасти. Все потому, что то, что производится прямо сейчас на линии – это необходимая норма для какой-то недавно проданной машины.

Одной из ключевых составляющих JIT-принципа является Kanban. Доски и карточки Kanban – это своеобразные светофоры в системе just in time. Kanban дает возможность бизнесу быть реактивным по отношению к потребностям клиента вместо прогнозирования потребностей.

Спроецируем этот пример на разработку ПО:

Тестировщик получает несколько задач для проверки. Когда у него заканчиваются задачи на проверку, он должен поставить в известность программистов, чтобы получить новые задачи от них. Если программисты не успевают закончить новые задачи, тестировщик просто остается на какое-то время без работы.

Случается и обратная ситуация: у тестировщика скапливается очень много задач и он не успевает все вовремя проверять. В этом случае, срок выпуска продукта также откладывается либо снижается качество проверки.

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

Для чего разработке ПО нужен Kanban?

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

Причины выбрать Kanban

Определение узких мест

Переход на Kanban доски с обычных списков задач сразу покажет узкое место в процессе разработки.

Рассмотрим на примере:

Отдел разработки выполняет 10 задач в течении спринта, а тестировщики могут закрыть только 5. Значит нужно увеличить количество тестировщиков или повысить их продуктивность, чтобы к концу спринта у нас были готовы к релизу все задачи, которые были сделаны отделом разработки.

Kanban доска позволяет увидеть узкие места в вашем процессе, где образуются очереди. С этой задачей помогают справиться WIP лимиты. Если у вас больше или меньше задач, чем нужно — колонка подсвечивается выбранным цветом. В YouTrack, который нами используется это красный цвет при недостатке и желтый при превышении.

Порядок выпуска фич и приоритет задач

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

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

Kanban доска предлагает выход из ситуации, когда порядок имеет значение — вертикальная колонка с задачами, а также использование горизонтального swimlane для приоритетов. Swimlanе определяет критичность приоритета. Чем выше swimlane, тем важнее задачи, которые необходимо решить. Чем выше задача внутри swimlane, тем она важнее.

Мы используем следующие Swimlane:

• Critical— задачи и баги, которые надо править в режиме реального времени. Пример – сломанная форма в момент проведения акции.
• Serious – задача без которой не может быть закрыт спринт, баг устранение которого необходимо для нормальной работы.
• Normal – обычные текущие задачи и баги, задача которая может быть перенесена в следующий спринт, но не отложена.
• Someday — задачи, которые имеют низкую актуальность по той или иной причине.

Эта система схожа с квадрантом Эйзенхауэра. Важные и срочные вопросы — это Critical / Serious. Важные, но несрочные — Serious / Normal, а также неважные и срочные – Normal / Serious; какой тип проставить определяется важностью закрытия задачи для завершения спринта или требованию к устранению в режиме реального времени. Неважные и несрочные — это Someday.

Концентрация на работе

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

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

Фильтр My Tasks помогает установить фокус на свои задачи. Он помогает быстро увидеть свои задачи на доске.

При разном уровне исполнителей задачи в Backlog уже расписаны между исполнителями.

Я иногда расписываю только задачи для Senior и Middle предоставляя джунам право побороться за оставшиеся задачи. Иногда поступаю наоборот, разделяю мелочи джунам, а важные задачи предлагаю разобрать Senior и Middle специалистам. В этом случае я все равно смотрю кто что взял, чтобы не получилось, что человек взял задачу, которая ему не по силам.

Панорамный вид

Перед вашими глазами — вся картина по проекту. Открыв доску, можно оперативно получить ответы на важные вопросы:

• Кто чем занят в данный момент времени?
• Что будет в работе дальше у каждого отдельного специалиста?
• Какие задачи были переоткрыты из-за багов?
• Кто находится без задач?
• У кого большая очередь задач?
• Где случились какие-либо изменения за последние сутки?
• Когда будет сделана конкретная задача?
• Как скоро закончатся задачи у конкретного специалиста?
• На какие задачи уже потрачено больше времени, чем было запланировано?

Гибкость

Kanban помогает стать гибкими. Это нужно, когда продукт выходит «в свет» и получает обратную связь. Сообщения в поддержку, поведенческая аналитика, результаты а/б тестирования, отзывы и т.д. Когда мы «заливаем» новую фичу на продакшн, сразу же начинаем ее менять на основе обратной связи. Раньше программист не хотел делать «левые» задачи, боясь «завалить» сроки по спринту. По Kanban программист работает как процессор: один такт — одна задача.

Чем чаще такты, тем команда разработки становится более гибкой. Крупные задачи обязательно декомпозируются. В нашей команде один такт это 6-10 часов.

Командный дух

С Kanban команда начинает работать более согласованно. Тестировщик проверяет фичу практически сразу после того, как ее сделал программист. Аналогично и в других областях: у дизайнеров, UX.

Раньше QA проверяли фичу не тогда, когда программист ее сделал, а спустя некоторое время. Программист за это время успевал забывать все на свете, включая детали этой задачи.

Ошибаться раньше — быстрее находить решение

В Scrum мы «заливаем» фичи на production только в конце спринта. В Kanban — практически сразу после приемки тестировщиком. Раз в несколько дней.

Так мы быстрее узнаем, зашла фича пользователям или нет. Если нет — где-то произошла ошибка. Это вовсе не означает, что мы любители ошибаться. Но если мы узнаем об ошибке первыми, мы первыми будет знать и решать, что делать.

Больше потока

Не нужно постоянно «дергать» программистов. Открыли Kanban доску, быстро глянули кто и чем занят, все статусы, и спокойно можно вернуться к менеджменту. А программист продолжает оставаться в состоянии потока, и в предвкушении взятия новых вершин.

Концентрация на одной задаче

Раньше программист занимался сразу несколькими задачами параллельно. Мог выбрать таск по настроению, а мог и вовсе в понедельник забыть о том, чем занимался в пятницу.

Сейчас WIP лимиты и панорамный вид грамотно ограничивают программиста: он не может делать более одной задачи сразу.

Вместо заключения

Может показаться, что мы настаиваем на том, что Kanban лучше Scrum. Но это не так. Всему свое время. Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.

Kanban — не панацея для любого бизнеса. Если вы приставили лестницу не к той стене, то как бы круто вы не поднимались по ней, вы все равно окажетесь не там, где нужно. Поэтому Kanban — необходимое, но не достаточное условие для успеха продукта или проекта. Ну и помните, что всегда есть Scrumban в котором внутри каждого спринта применяется Kanban методология.