Kanban что это в бизнесе

Вы когда-нибудь пытались собрать вместе группу людей, чтобы создать продукт или запустить проект? В качестве бонусов: жесткий дедлайн, объемное техзадание и несговорчивый заказчик. Получилось? Если да, то дальше можете не читать.

Управлять командой нелегко. Особенно в digital. Нужно организовать работу так, чтобы качество продукта было на высоте, дедлайны соблюдались, команде было комфортно, а заказчик остался доволен. Важно не допускать конфликтов и постоянно развивать команду.

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

Что такое Kanban

Kanban ― это метод улучшения процессов разработки и часть agile-философии. В его основе ― «Манифест гибкой разработки программного обеспечения».

Манифест гибкой разработки ПО

Цель Kanban ― получать готовый качественный продукт вовремя. Давайте разбираться, как этого добиться.

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

Методология Kanban в бизнесе и жизни. Принципы Канбан.

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

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

Kanban-доска ― универсальный инструмент, который можно подстроить под любой процесс и применить в любой области. Например, составить список дел.

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

Названия столбцов можно менять в зависимости от проекта, но важно сохранять их последовательность. Доска должна полностью отражать процесс создания ценности, который в Kanban называют потоком.

Kanban-карточки ― это задачи, которые команда перемещает по доске в зависимости от их состояния. Количество карточек можно менять. На карточке или стикере пишут название задачи и прикрепляют в начало доски.

C помощью kanban-доски команда может вести несколько проектов одновременно, использовать карточки разных цветов: один цвет ― один проект.

Как помогает визуализация

Получить результат точно в срок возможно, если контролировать нагрузку. Для этого нужно ограничить количество задач.

В одном столбце kanban-доски одновременно находится столько задач, сколько команда реально выполняет в установленные сроки. Например, в состоянии «Проектирование» одновременно ― не больше двух задач, а в графе «Тестирование» ― только одна. Количество команда выбирает в зависимости от своих возможностей.

Пример

Разработчик еще не закончил с текущей задачей, а ему уже поступила следующая. Он не успевает и тормозит всю работу.

Про KANBAN простыми словами / Эффективная работа с беклогом

Решение: прекратить передавать задачи в разработку и дать программисту время закончить работу.

Важно найти баланс: выбрать темп работы, который удобен команде и не вредит срокам проекта. Для этого в Kanban учитывают время выполнения каждой задачи. Так команда понимает, что занимает больше времени, а что ― меньше, и может правильно организовать работу.

Пример
На этапе тестирования продукта возникли трудности и нужно больше времени.

Решение: выяснить, какую часть работы можно сделать быстрее, не потеряв в качестве. Или сотрудника, который свободен и поможет тестировщику.

На доске отражаются все процессы, а команда их анализирует и устраняет слабые места. В Kanban это называется управление потоком .

Чтобы использовать Kanban, мало просто повесить доску с карточками. Команда должна знать правила, по которым работает.

Это еще и про прозрачность процесса: когда работа — на виду и всем понятен результат.

Важна сплоченность, постоянное совершенствование продукта и развитие сотрудников. Команда в Kanban ― единый механизм. Если кто-то не справляется, то страдает общее дело. Работу планируют на доске, весь процесс на виду, поэтому каждый может увидеть свой вклад и ценность для проекта.

В Kanban смешались принципы agile-методологий и lean-мышления. Здесь нет жестких правил и кардинальных перемен, но есть принципы, на которые можно опираться.

Как не путать Kanban и Scrum

Kanban часто путают или объединяют с гибкой методологией Scrum. Чтобы с вами такого не произошло, давайте посмотрим, в чем основные различия.

Scrum ― это гибкая методология управления проектами, а Kanban ― метод улучшения любой методологии.

KANBAN
• Нет совещаний
• Нужна отправная точка
• Могут работать узкопрофильные команды
• Последовательные и плавные перемены
• В команде нет разделения на роли

SCRUM
• Есть совещания
• Не нужна отправная точка
• Только кроссфункциональная команда
• Кардинальные перемены
• В команде есть разделение на роли

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

Scrum сейчас популярен, все говорят о его пользе. Но страшно: придется уйти от привычного процесса разработки, а вдруг не поможет. В такой ситуации лучше начать с Kanban. Если команда заметит явные улучшения, то потом сможет решиться и на Scrum.

Команда, уже внедрила Scrum, но хочет продолжать совершенствовать процесс. Тут снова поможет Kanban.

Совсем не важно, какую методологию разработки использует команда, но чтобы внедрить Kanban, нужна отправная точка.

Как внедрить Kanban

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

Подведем итоги

Теперь вы знаете, что такое система Kanban, чем отличается от Scrum и как ее можно использовать. И уже готовы проверять все в деле. Теория ― это хорошо, но нужна практика. И лучше практиковаться без опасений, что одно неверное движение может навредить делу. Поэтому в Skillbox есть курс, который прокачает вас в управлении проектами.

Вы сможете внедрять в свою работу любые agile-системы и будете уверены в результате.

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

Источник: dzen.ru

Канбан: методология, инструменты и принципы системы

Как с помощью канбана наладить бизнес-процессы и соблюдать дедлайны

корреспондент
Беседовали с Ириной Каплуновой
Enterprise Agile Coach (IBM Consulting)
корреспондент
Беседовали с: Ириной Каплуновой

Когда в компании нужно синхронизировать процессы, отрегулировать нагрузку участников команд и получать результат в намеченный срок – можно внедрить систему Kanban. Это метод организации и управления задачами. Он основан на визуализации бизнес-процессов и поиске способов их улучшения для повышения эффективности почти в любой сфере. Поговорили с аджайл-коучем Ириной Каплуновой и выяснили, как устроен канбан и как эффективно использовать его в бизнесе.

1 5 15/06/2022

Канбан появился, как и многие другие инструменты бережливого производства, на заводах Toyota в Японии в 50-х годах прошлого столетия. В то время компания искала способы сократить время производства одного автомобиля. В компании внедрили систему карточек , через которые передавали информацию: сколько и каких деталей требуется. Это помогло выпускать автомобили быстрее, не создавать лишней нагрузки на логистику, производить запчасти в том объеме, в котором они были нужны.

В 2000-х Дэвид Андерсон адаптировал концепцию бережливого производства для управления разработкой ПО . Его метод заключался в визуализации всех этапов работы над задачей с помощью колонок на доске. Разработчики по очереди выполняли свою часть работы и отправляли на следующий этап. Задачи постоянно приоритизировали – участники команды всегда знали, какая из них сейчас наиболее важна для бизнеса. В 2007 году метод назвали «канбан», и он широко распространился.

Сегодня канбан – популярная методология гибкого управления. Система реализуется через физические и виртуальные kanban-доски, на которых карточки проходят несколько этапов, двигаясь из одной колонки в следующую. Канбан применяют российские и иностранные компании: HeadHunter, «Альфа-банк», Microsoft, «Додо Пицца», Clever и другие.

Суть канбана

Канбан отличается от метода, который применяли на заводе Toyota. Общее для них – визуализация с помощью карточек и цель получить результат как можно быстрее. Канбан адаптировали для работы с творческими и интеллектуальными задачами, которые нельзя «пощупать». Теперь его используют в IT, службах технической поддержки, в продажах, услугах.

Канбан – это визуальная система управления работой команды, одна из самых популярных методологий управления наравне со Scrum

Чаще Agile используется в IT, но именно канбан можно применить ко всем сферам бизнеса. В конце концов, канбан – это способ визуализировать задачи для повышения продуктивности команды, и неважно – команды разработчиков, продаж, врачей или строителей.

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

Суть kanban-методологии заключается в следующем:

• Есть план того, что нужно сделать, он называется backlog (бэклог). В нем список задач отсортирован по приоритету, при необходимости его можно и нужно корректировать, меняя важность карточек.
• Есть ограничения по количеству задач «В процессе», чтобы регулировать нагрузку сотрудников или отделов, избегать завалов и простоев. Это ограничение называется WIP -лимит.

При необходимости для задач можно выставлять дедлайн, но это необязательно. Приоритетные задачи всегда находятся вверху бэклога – это значит, что они будут сделаны как можно скорее.

Ценности метода

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

1. Прозрачность – открытый обмен информацией;
2. Баланс – равновесие между нагрузкой и возможностями;
3. Сотрудничество – совместная работа участников команды и ее совершенствование;
4. Фокус на заказчике и его потребностях – создание продукта, который нужен клиенту;
5. Поток – непрерывная работа;
6. Лидерство – вдохновление своим примером других участников. При этом нет иерархии, понятие применимо на всех уровнях;
7. Понимание – знание всеми участниками целей развития команды;
8. Согласие – совместное движение к целям и совершенствованию;
9. Уважение – понимание и положительная оценка всех участников команды.

Если отступиться хотя бы от одной из ценностей, у команды ничего не получится – так считают создатели краткого руководства по канбану Дэвид Дж. Андерсон и Энди Кармайкл .

Принципы

Чтобы успешно использовать систему в своей команде, нужно придерживаться основных принципов канбана:

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

Инструменты

Главный инструмент канбана – доска с карточками. Это может быть физическая меловая доска, магнитная, со стикерами или электронная. К ней должны иметь доступ все участники команды в любой момент времени.

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

На одной доске можно вести сразу несколько проектов, для этого используют карточки разных цветов или swimlanes – горизонтальные разделители. Каждая карточка в канбане может содержать дополнительную информацию с описанием задачи, именем того, кто над ней работает, ее приоритет, дедлайн. Задачи могут быть ежедневными, еженедельными, ежемесячными.

Правила работы с карточками

Основные правила Kanban при работе с карточками направлены на непрерывное течение процесса, регулирование сроков и внимание к задачам, которые по каким-то причинам не движутся по потоку:

• WIP-лимит может быть разным для конкретных специалистов или отделов в зависимости от их ресурсов. Цель применения лимита – направить фокус сотрудника на одну задачу, вместо того, чтобы он пытался делать несколько сразу.
• Максимальным лимитом регулируется количество карточек в каждом столбце. Лимит основывается на реальных возможностях команды, в него входят все карточки, которые находятся в работе.
• Нельзя начинать новую карточку, если не сделана предыдущая. Если задача по каким-то причинам не может быть завершена, ее нужно перенести в колонку Blocked и искать другие способы ее завершения.

Главный закон эффективности канбана – «прекращайте начинать, начните заканчивать»

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

• срочный – нельзя откладывать;
• с фиксированной датой – нужно сделать к определенному сроку;
• стандартный – издержки растут пропорционально задержке, желательно сделать вовремя;
• нематериальный – стоимость задержки растет медленно, задача несрочная, делать ее сейчас необязательно, если есть более важные.

Для контроля за продвижением карточек канбана должен быть ответственный сотрудник – Service Delivery Manager. Он может быть один на три-пять команд.

Обязанности Service Delivery Manager:

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

В методологии канбана не прописана необходимость в специальной роли фасилитатора – аналога Scrum Master в скраме. Однако часто на практике такой человек необходим. Это может быть Agile Coach , который работает одновременно с несколькими командами. Его задача – помочь командам правильно адаптировать канбан под нужды бизнеса и постоянно улучшать процессы.

Ритм работы команды

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

Встречи на уровне команды:

1. канбан-митинг – ежедневные встречи по 15 минут для обсуждения текущих задач на сегодня;
2. встречи для обновления бэклога – один раз в неделю по 30 минут для добавления и приоритизирования новых задач;
3. встреча с клиентом – собрание на 30 минут вместе с заказчиком, на котором команда выясняет, доволен ли он качеством и скоростью работы;
4. обзор рисков – ежемесячная встреча для обсуждения прошлых неудач и поиска вариантов их устранения.

Встречи на уровне компании:

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

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

Канбан – это шаблон, который нужно с умом адаптировать под ваши процессы

Чем канбан отличается от скрама

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

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

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

Цель в канбане – решить задачу

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

Преимущества и недостатки подхода

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

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

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

Еще одно преимущества метода – простота. Не нужно быть экспертом, чтобы понять, как работать с ним на базовом уровне. Компании понадобится эксперт, чтобы начать, но в дальнейшем команды быстро привыкают, потому что эта система интуитивно понятна каждому.

Когда и кому нужен канбан

Выделяют несколько характерных сигналов, которые указывают на возможность и даже необходимость внедрения канбана:

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

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

Как внедрить канбан и как организовать работу

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

Enterprise Agile Coach Ирина Каплунова рекомендует внедрять подход в имеющийся коллектив. Именно знания действующих сотрудников о процессах в компании помогают их улучшить: «Agile – это изменение философии менеджмента. Именно сотрудники, а не менеджмент, чаще всего имеют прямой контакт с клиентом, и именно они страдают от непродуктивности процессов в компании. Первым шагом к изменениям всегда является анализ – выслушать сотрудников и найти те процессы, которые не работают. Для этого нужен Agile Coach».

Насколько длительным будет внедрение, зависит от численности сотрудников. Проанализировать работу в группе из 10 человек и обучить ее участников канбану Agile Coach сможет за две-четыре недели. Масштабировать на коллектив из 1000 специалистов можно в срок от двух до пяти лет. Большое влияние на длительность внедрения оказывает вовлеченность сотрудников в процесс.

На начальном этапе внедрения нужно:

• визуализировать задачи с помощью доски со стикерами;
• обсудить с коллективом правила работы c канбаном;
• определить число карточек, выполняемых одновременно;
• следить за статусами карточек и временем прохождения по доске в колонку «Готово»;
• анализировать время движения карточек и выявлять возникающие проблемы, находить способы улучшения;
• экспериментировать – менять способы решения задач и организацию процесса, отслеживать, какие изменения за этим следуют и как они влияют на показатели продуктивности.

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

Резюме

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

Нравится: 5 Была ли статья полезна? Да Нет

Источник: kachestvo.pro

13 причин перейти на Kanban. И никаких суеверий

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

Что такое Kanban?

Разберем следующий пример, рассмотрев две ситуации.

Первая ситуация – представим конвейерную фабрику в советское время, деятельность которой напрямую зависела от госплана. Этот план четко определял количество продукции для производства. Как результат, переполненные склады из-за того, что составители госплана часто могли ошибаться со спросом. Продукцию не успевали продавать.

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

Другими словами, работает принцип точно в срок just in time (JIT). Сперва цели и сроки, затем план и работа.

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

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

Можно спроецировать похожий пример на область разработки ПО:

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

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

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

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

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

13 причин перейти на Kanban

Вот 13 причин, по которым стоит внедрять Канбан в IT компании, которые занимаются разработкой ПО:

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

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

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

2. Точный порядок выпуска фич

Часто большое значение имеет порядок выпуска фич. В списках, построенных на приоритетах, тяжело точно управлять порядком. Если у программиста будет одновременно пять задач с главным приоритетом, ему будет сложно сориентироваться, какую из этих задач взять в работу первой.
Kanban доска как раз предлагает выход из ситуации, когда порядок имеет значение. Это визуальное решение — вертикальная колонка с задачами. Чем выше задача, тем она важнее. Kanban, кстати, предполагает определение приоритетов, как один из важных аспектов методологии. Постоянно меняются требования, многие задачи могут терять актуальность и «спускаться» вниз.

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

3. Приоритет главным задачам

Kanban учит отдавать главное внимание главным вещам. Тому, что реально добавляет ценности продукту. Мы смогли «опустить» вниз множество бесполезных багов и доработок. Это дало результат.
Отличать важные баги от менее приоритетных – непростая задача для менеджера продукта, но здесь ему на помощь приходит функция Swimlanes. Это горизонтальные колонки на Kanban доске. Как правило, у программистов на доске присутствуют такие Swimlanes:

• Blockers — задачи и баги, которые надо править в режиме реального времени. Пример – сломанная регистрация.
• Tasks and Bugs – обычные текущие задачи и баги.
• Someday — задачи, которые потеряли актуальность по той или иной причине.

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

Программист должен быть сконцентрирован на своей работе. Поэтому хорошо, когда он получает очередь задач и ему не нужно думать, что делать дальше, об этом уже подумал менеджер. Просто нужно брать в работу следующую задачу или баг.
Иногда Kanban предполагает самостоятельный выбор программистами любых задач сверху. Тогда профессиональный уровень всех людей должен быть равным, чтобы не получилось, что самая сложная задача «падает» на junior специалиста.
Фильтр My Tasks помогает установить фокус на свои задачи. Он помогает быстро увидеть свои задачи на доске.

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

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

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

6. Гибкость

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

Раньше программист не хотел делать «левые» задачи, боясь «завалить» сроки по спринту. По Kanban программист работает как процессор: один такт — одна задача.

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

7. Не нужно оценивать фичи

Scrum забирал много времени на оценку фич перед стартом спринта. С Kanban потребности в оценке нет. Когда сделаем, тогда и будет сделано.

8. Больше дела

Scrum предполагает много коммуникации. Начало спринта сопровождается планированием: анализом и оценкой задач. Каждую неделю обязательны стенд-апы. После окончания спринта проводится ретроспектива. По итогу, вся коммуникация отнимает около 30% времени.

А ведь это время команда могла бы потратить на работу.

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

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

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

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

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

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

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

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

12. Больше знаний – лучше для проекта

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

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

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

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

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

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

• kanban
• agile
• управление проектами
• управление задачами

• Блог компании Hygger
• Управление разработкой
• Управление проектами
• Управление продуктом

Источник: habr.com