Занимательная статистика
Канбан и Аджайл
Чтобы правильно понять метод Канбан, важно четко понимать его связь с Agile и возможные точки схождения и расхождения.
Гибкое управление проектами Agile ориентировано на параллельные адаптивные рабочие процессы и относится к группе методологий управления, в которую также входят Scrum и Kanban.
Можно долго искать принципиальные различия между Agile и Kanban, но правда в том, что метод Канбан — это тип методологии Аджайл. Таким образом, идея их противопоставять – по сути, заблуждение.
Канбан использует принципы Agile и реализует их особым образом. Следовательно, Канбан — это структура, которая подпадает под методологию Agile.
Если ценности организации, использующей Agile, сочетаются с характеристиками Канбан, результатом будет Agile Kanban. Эта практика становится все более популярной в разработке программного обеспечения, где сочетаются подход Agile-итераций и фокус на потоке создания ценности Kanban. Agile Kanban Framework фокусируется на визуализации всего проекта на досках, чтобы повысить прозрачность проекта и сотрудничество между членами команды.
Но в отличие от Скрам или Аджайл, Канбан касается рабочих состояний, которые сосредоточены на спринтах и итерациях. Канбан фокусируется на разбиении работы на небольшие задачи, их визуализации и получении нескольких элементов в любом заданном рабочем состоянии. На Канбан-доске работа всегда движется слева направо.
Универсальность Канбан заключается в его простоте. Он вписывается в текущие рабочие процессы и учитывает существующие роли и обязанности. Его можно использовать независимо от отрасли. Редактор контента может использовать его точно также, как и собственник объекта электронной коммерции.
Канбан можно использовать в любой среде умственного труда и особенно в ситуациях, когда работа поступает непредсказуемым образом и/или когда необходимо развернуть работу то час же, как она будет готова, а не ждать других рабочих элементов.
В целом, Канбан — одна из самых простых используемых сред, поскольку она позволяет руководителям проектов эффективно управлять своими проектами и отслеживать их. Отличительной особенностью Канбан-фреймворка среди различных гибких методологий является его совместимость с существующей организационной средой.
Если в производственном процессе приоритеты меняются на лету, а разовые задачи могут выполняться в любое время, Канбан подходит лучше всего, так как предоставляет возможность добавлять задачи на любой этап работы. Его можно использовать и тогда, когда нет итераций.
Канбан и Скрам
Стоит уделить немного времени, чтобы сравнить Канбан с одной из самых популярных гибких сред, — Скрамом.
Скрам (Scrum) — это структура (категории «легкий фреймворк»), предназначенная для управления проектами с первоначальным упором на разработку программного обеспечения, хотя она используется и в других областях, включая исследования, продажи, маркетинг и передовые технологии.
Иначе говоря, Скрам — это фреймворк управления, согласно которому одна или несколько кроссфункциональных самоорганизованных команд создают продукт инкрементами, то есть поэтапно.
В Скраме есть система ролей, событий, правил и артефактов. В этой модели за создание и адаптацию рабочих процессов отвечают команды.
В отличие от других популярных фреймворков, Канбан предполагает внесение очень небольших, но значимых изменений в существующую настройку. Это подходит организациям с традиционалистской культурой, где важными считаются иерархия и роли функциональных менеджеров.
Методология Канбан — это гибкий метод, направленный на постоянное совершенствование, повышение гибкости в управлении задачами и улучшение рабочего процесса. При таком визуализированном подходе ход всего проекта можно легко понять с первого взгляда.
Канбан использовался в производственных условиях для управления запасами по всей цепочке поставок с использованием практики, называемой производством «точно в срок» (JIT). В управлении проектами методология Канбан адаптирует ту же концепцию, гарантируя, что объем требуемой работы совпадает с рабочими возможностями команды.
Канбан — это вытягивающая система. Вытягивающая система — это метод бережливого производства, который контролирует поток работы, заменяя то, что уже сделано. Торговый автомат — прекрасный пример вытягивающей системы: товары будут пополняться только тогда, когда они закончатся. Канбан точно соответствует этому определению.
Скрам и Канбан считаются краеугольными камнями методологии внедрения Agile. Согласно отчету PMI «Pulse of Profession 2019», более 57% организаций использовали различные методологии Agile, и наибольшая доля привержена использованию Скрам и Канбан.
И Канбан, и Скрам сосредоточены на последовательном выпуске продукта и продолжают итерации до тех пор, пока не будет достигнуто совершенство, однако их подход отличается. Среды Канбан и Скрам реализуют ценности и принципы манифеста Agile, но способы, которыми они это делают, совершенно разные.
Самое важное отличие Канбан от Скрам заключается в том, что первый — это метод, а второй — фреймворк. Канбан строит модель непрерывной доставки, при которой команды создают ценность по мере готовности, а Скрам организует работу в спринтах.
Применение того или иного решения зависит от характера процесса. Однако можно сказать, что Канбан предлагает более индивидуальный подход, в то время как Скрам опирается на заранее определенные правила.
Еще одна ключевая отличительная черта между ними — образ мышления и основополагающие системы убеждений Scrum и Kanban.
Чтобы это понять, обратите внимание на таблицу ниже.
Kanban | Scrum | |
Природа | Канбан — адаптивный метод | Скрам — предписывающая структура |
Принципы | 1. Начните с того, что вы делаете сейчас 2. Согласитесь на эволюционные изменения 3. Поощряйте акты лидерства на всех уровнях 4. Сосредоточьтесь на потребностях клиента 5. Управляйте работой 6. Регулярно пересматривайте сеть услуг | 1. Эмпиризм 2. Прозрачность 3. Осмотр 4. Адаптация |
Каденции — каденции командного уровня | - Каденции, ориентированные на обслуживание - Спринт с фиксированной продолжительностью | - Планирование спринта - Ежедневный Скрам - Обзор спринта - Ретроспектива спринта |
Роли | - Предварительно определенные роли не требуются | - Владелец продукта - Скрам-мастер - Команда разработчиков |
Показатели | - Время цикла - Пропускная способность - Работа в процессе | - Скорость - Планируемая мощность |
Итак, Скрам вращается вокруг «спринта» фиксированной длины, и работа выполняется небольшими партиями. Канбан фокусируется на процессе непрерывного улучшения, а задачи выполняются упорядоченно.
В Канбан изменения можно легко внести в любое время, поскольку он основан на задачах, в то время как Скрам требует завершения одного плана спринта, прежде чем можно будет вносить какие-либо изменения.
Это делает Канбан подходящим вариантом для чрезвычайно универсальных проектов, в то время как Скрам лучше подходит для проектов, требующих, чтобы работа выполнялась партиями. Канбан также не имеет предписанных ролей. Скрам имеет заранее определенные роли - Scrum Master, Product Owner и член команды.
Наконец, если Вы когда-либо были частью Agile-команды, возможно, Вы использовали родственника доски Канбан: доску Скрам. Скрам-доски внешне очень похожи на Канбан-доски, и большинство команд, использующих их, следуют тем же основным принципам.
Фундаментальное различие между досками Канбан и досками Скрам заключается в том, что доски Скрам предназначены для использования командами, работающими в итерациях, ограниченных по времени. Тогда как доски Канбан используются командами, работающими над непрерывным потоком. Другими словами, Скрам-команды используют доски, чтобы «сжечь» все задачи, тогда как Канбан-команды используют свои доски для непрерывного перемещения работы по процессу.
Итак, становится понятным, что там, где Канбан тянет, Скрам подталкивает. Канбан гибок, а Скрам имеет более четкую структуру. Канбан ограничивает незавершенное производство, чтобы сбалансировать работу с фактическими мощностями, а Скрам опирается на постоянную оценку. Канбан менее предписывающий, чем Скрам; поэтому ожидается, что пользователи Канбан будут экспериментировать с процессом, чтобы адаптировать его к своей среде.
Но, если кому-то показалось, что Канбан сочетается со Скрамом, он не ошибается. Многие команды ИТ-разработчиков действительно смешивают рабочие стили в так называемом «Scrumban», хотя сторонники «чистого» Kanban утверждают, что от некоторых практик Скрам придется отказаться, поскольку они представляют собой пустую трату времени, не добавляя напрямую ценности для клиента. Например, спринты фиксированной длины, оценка пользовательских историй, совещания по планированию спринтов и релизов, строгая расстановка приоритетов пользовательских историй в Бэклоге Продукта.
Команды, входящие в группу Скрамбан, сохраняют концепцию Скрам-итераций фиксированной длины. Каждый Спринт начинается с совещания по планированию Спринта, на котором содержание следующей итерации согласовывается с Владельцем Продукта и определяется первоначальная версия Бэклога Спринта.
Принимая во внимание правила гибкого планирования, истории в Бэклоге Продукта имеют приоритет, и каждая команда должна:
определить свою ожидаемую скорость
оценить пользовательские истории в баллах, используя предварительно определенные значения (например, 0, 1, 2, 3, 5, 8, 13 и 20).
Содержание Бэклога Спринта не должно превышать расчетную скорость. В конце каждого Спринта организуются обзор Спринта и ретроспектива Спринта. На обзоре команды Скрамбан представляют свои результаты Владельцу продукта, а на ретроспективной встрече участники встречаются, чтобы оценить процесс разработки в предыдущем спринте и дать предложения по улучшению в следующем.
Вышеупомянутая среда Скрам дополняется использованием доски Канбан и лимитами незавершенного производства. Доска визуализирует рабочий процесс, а ограничения WIP не позволяют членам команды работать над несколькими рабочими элементами одновременно, что минимизирует время выполнения заказа. Канбан-доска включает столбец «Журнал спринта», который открывается на каждом собрании по планированию спринта.
Итак, важно понимать, что метод Канбан — это не практика разработки программного обеспечения и не методология управления проектами. Канбан ничего не говорит о том, как следует разрабатывать программное обеспечение. В нем ничего не говорится о том, как следует планировать и реализовывать программные проекты.
Таким образом, Канбан не является управленческой структурой, такой, как Скрам. Однако цель Канбан — постоянное улучшение собственного рабочего процесса. Следовательно, Канбан-метод — это процесс постепенного улучшения всего, чем занимается организация, будь то разработка программного обеспечения, ИТ/эксплуатация, подбор персонала, маркетинг и продажи, закупки и т. д. Практически любая бизнес-функция может выиграть от применения принципов методологии Канбан.
Прелесть метода Канбан в том, что его можно применить к любому процессу или методологии. Независимо от того, используются ли Agile-методы (Scrum, XP и другие) или более традиционные методы — (водопад, итеративный и т.д.) — всегда есть возможность применить Канбан для того, чтобы постепенно улучшать процессы, сокращать время цикла и улучшать поток.
