Содержание

14 Лучших Kanban Инструментов в 2019 Году / Hygger corporate blog / Habr

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

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



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

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

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

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

Эффективный Kanban-инструмент поможет управлять Agile-разработкой с помощью удобных досок и карточек, потока действий, функций Swimlanes и WIP limits, диаграмм и таймлайнов — всего, что помогает качественно визуализировать управление рабочими процессами.

Что включает в себя мощное Канбан ПО


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

Тем не менее, существуют решения, которые выполняют работу лучше и эффективнее других. Рассмотрим главные критерии для поиска лучшего Канбан-инструмента:

  • Kanban доска — система, которая предназначена для организации карточек с задачами с помощью горизонтальных колонок (Swimlanes), ограничений (WIP limits), сабколонок, а также стандартного набора колонок («To-do», «In Progress» и «Done»).
  • Kanban карточка — элемент системы Канбан, который назначает задачи при помощью чек-листов и вложений. Карточки позволяют связывать задачи, добавлять иерархию и назначать необходимые ресурсы.
  • Аналитика — система, позволяющая создавать отчеты.
  • Интеграция — способность инструмента легко интегрироваться с другими системами управления проектами.
  • Автоматизация — возможность настроить рабочий процесс в соответствии с условиями вашего проекта.

Лучшие Канбан инструменты для управления проектами


У вас, по сути, есть два пути:
  • Не заморачиваться и бездумно зарегистрироваться в проверенные и пресловутые JIRA или Trello.
  • Потратить немного времени на изучение новой волны крутого ПО по управлению проектами, ориентированного на Kanban, с целью отбора самого подходящего софта для ваших нужд.

В любом случае, выбор за вами. Вот краткое описание некоторых из них:

JIRA


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

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

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

Trello


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

Сомнения: Trello не имеет своего собственного учета времени, поэтому вам придется платить за другое программное обеспечение (например, Everhour или Toggle). Кроме того, в Trello нет функций WIP limits, Swimlanes и диаграмм Burndown.

Hygger


Hygger — яркий представитель нового поколения PM-инструментов, который отлично подходит продуктовым компаниям, стартапам и организациям средних размеров. Сервис предоставляет удобные to-do листы с кастомными полями, Канбан досками, функциями Swimlanes, WIP limits и Timelines.

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

Hygger предлагает определять приоритеты с помощью простых методов (Eisenhower matrix, Value vs Effort, Value vs Risk), а также продвинутых техник (ICE и RICE, Weighted Scoring).

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

Asana


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

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

Сомнения: Платформа вряд ли будет полезна маркетинговым и креативным агентствам или сервис-компаниям.

Favro


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

Функция Breakdown в Favro помогает разбить ваши проекты на различные задачи. Инструмент интегрирован с Google Drive и Dropbox, что позволяет прикреплять файлы к доске планирования.

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

MeisterTask


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

Канбан доски MeisterTask помогают пользователям просматривать и управлять текущими действиями и активными проектами, создавать планы проектов и сотрудничать с членами команды. Платформа предлагает интеграцию с GitHub, DropBox, Zendesk и Bitbucket.

Сомнения: Отсутствие календаря, который мог бы показать, когда вы запланировали свои задачи. Нет диаграмм Ганта, чтобы установить продолжительность для задач.

Kanbanchi


Kanbanchi – еще одно подходящее решение, если вам нужно программное обеспечение для управления задачами и совместной работы с досками Kanban, диаграммами Ганта и системой учета времени.

Вы легко визуализируете рабочие процессы всех задач и действий с помощью удобных досок проектов со списками и карточками. Инструмент предназначен для G Suite. Вы должны зарегистрироваться в учетной записи Google, управлять досками в виде файлов на Google диске, помещать даты в Google календарь и т. Д. Приложение отлично подходит для работы отделов компании, потому как каждый член команды знает, над чем он работает.

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

Paymo


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

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

Breeze


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

Инструмент основан на принципах Agile и Lean и включает в себя следующие основные функции: списки задач, отслеживание времени, бюджетирование проекта, отчетность, календарь, экспорт данных, неограниченное количество пользователей, поддержка Android и iOS, интеграция с Google Drive и Dropbox, и т.п.

Сомнения: Малое количество инструментов, с которыми Breeze может быть интегрирован.

Blossom


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

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

Сомнения: Нет бесплатного плана для личного использования. Интеграционные возможности — только отправление обновлений на канал Slack.

ProofHub


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

ProofHub предлагает расширенные функции и ценовые пакеты в соответствии с требованиями различных компаний, а также приложения для iOS и Android, что позволяет пользователям работать более продуктивно. Среди ключевых функций выделим списки задач, календари, обсуждения, диаграммы Ганта, удобные расписания и т. д.

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

ZenHub


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

Инструмент можно использовать для организации, планирования и запуска спринтов. Нет необходимости в специальном обучении — ZenHub широко используется как командой разработчиков, так и продуктовиками. Основными функциями являются Kanban-доски, списки дел, графики Burndown, оценки времени, интеграция со Slack и др.

Сомнения: Zenhub не предоставляет достаточно аналитических и отчетных функций. В UX есть некоторые «причуды», которые могут периодически отвлекать и беспокоить.

Taiga


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

Сервис можно легко интегрировать с GitHub, GitLab, Webhooks, Bitbucket и Gogs. Доступны мобильные приложения для Android, iOS и Windows.

Сомнения: Интерфейс выглядит немного старомодно. Экраны довольно сложные — это немного запутывает работу с разными их видами.

LeanKit


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

LeanKit предлагает удобный способ соединения досок проектов на уровне команды и проекта и предоставляет пользователям полную видимость. Вы также получите модуль отчетности и аналитики с полезными показателями и метриками. Платформа поддерживает интеграцию с JIRA, Zendesk, Pivotal Tracker и другими инструментами.

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

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

habr.com

Что такое Канбан-метод – максимально коротко — статья в блоге ScrumTrek

Максимально коротко описали Канбан-метод, его основные термины и области применимости.

1. Что такое Канбан-метод?

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

Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.

2. Канбан-метод и Канбан Тойоты – это одно и то же?

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

Давайте разберем короткий пример. Нам нужно сделать три автомобиля “точно в срок”. Это значит, что мы точно заранее можем определить, сколько нам потребуется деталей на определенных этапах, и начинаем с конца вытягивать необходимое количество деталей для создания этого автомобиля, отвечая на вопросы: “Сколько литров краски нам потребуется?”, “Сколько колес?”, “Сколько двигателей?” и так далее. Таким образом, мы не создаем излишки запасных частей в виде остатков и экономим на складах, логистике и прочих издержках.

Канбан-метод тоже придерживается понятия “точно в срок”, но в отличие от заводов Тойоты здесь речь идет об интеллектуальном труде. Иными словами, код программиста или идею маркетолога нельзя пощупать и увидеть обычному человеку, пока он(она) не превратится в конечный продукт или сервис. Таким образом, Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.

3. Можно ли использовать Канбан-метод не в IT?

Да. Канбан-метод подходит для визуализации потока любой творческой и интеллектуальной работы. Но гораздо эффективнее использовать его через призму сервисной парадигмы. Посмотрите на то, что вы делаете, как на сервис. Через какие стадии проходит работа, чтобы сервис был оказан? По каким критериям вы поймете, что сервис оказывается в соответствии с ожиданиями Заказчика? Это отправная точка в применении Канбан-метода. Канбан-практики называют эту точку “начните с того, что есть сейчас”.

4. Канбан – это как Скрам?

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

5. У Канбана есть ценности?

Да. Их девять: прозрачность, баланс, сотрудничество, клиентоориентированность, поток, лидерство, понимание, согласие, уважение.

6. Вы написали о принципах Канбана. Какие они?

У Канбана действительно есть базовые принципы, которые еще называют принципами управления изменениями:

  1. Начните с того, что есть сейчас.
  2. Договоритесь об эволюционном развитии.
  3. Поощряйте развитие лидерства на всех уровнях.

Так как Канбан-метод живет в сервисной парадигме, он придерживается ее принципов:

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

7. А что за практики в Канбане?

Их тоже шесть:

  1. Визуализируйте.
  2. Ограничивайте незавершенную работу.
  3. Управляйте потоком работы.
  4. Используйте явные правила.
  5. Вводите петли обратной связи (каденции).
  6. Улучшайте и эволюционируйте.

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

8. О, каденции! Что такое каденции в Канбане?

Каденция – термин из музыки. В контексте Канбан-метода она обозначает ритм. Каденциями называют регулярные встречи, которые еще являются петлями обратной связи. Регулярность задает ритм, с которым течет поток работы. Каденций семь:

  1. Канбан-митинг (ежедневная). Здесь обсуждаем статус заблокированных задач.
  2. Встреча по наполнению очереди (обычно раз в две недели). Берем на себя обязательства, что будет делать, как сервис.
  3. Встреча по планированию поставки (обычно раз в две недели). Возвращаем выполненные обязательства обратно.
  4. Встреча по обзору сервиса (обычно раз в две недели). С метриками обсуждаем качество сервиса и как его улучшить, если нужно.
  5. Операционная встреча (обычно раз в месяц). С метриками обсуждаем качество взаимодействия связанных сервисов.
  6. Встреча по обзору рисков (обычно раз в месяц). С метрикам обсуждаем влияние заблокированных задач на работу сервиса.
  7. Встреча по обзору стратегии (обычно раз в квартал). С метриками обсуждаем изменения в стратегии.

9. Я что-то слышал про классы обслуживания. Что это?

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

  1. Ускоренный класс – неотложная скорая помощь-реанимация. Едет по выделенной полосе. Нет времени откладывать решение проблемы. Нужно как можно скорее.
  2. Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода. Пример: проект в виде ФЗ с фиксированной датой начала действия. Не успеем вовремя, есть риск потерять лицензию.
  3. Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, получаем прибыль сразу. Если делаем долго, получаем прибыль долго.
  4. Нематериальный класс – делаем, но явной прибыли эта работа не несет, стоимость задержки растет медленно. Например, уборка в доме. Можно и не убираться регулярно, но через пол года придется делать генеральную уборку.

10. Что на счет метрик? Как померять эффективность работы сервиса?

У Канбан-метода есть метрики, которые позволяют ответить на вопросы: какие проблемы в потоке работы, какая пропускная способность у сервиса, какое время выполнения, какое время разрешения блокировок, какое время цикла и по каким типам распределяется работа? Все это позволяет менеджеру сервиса принимать решения о развитии и улучшении качества сервиса на основе накопленных данных.

11. С какими проблемами сталкивается Канбан при внедрении?

Основная трудность – это объяснить людям на всех уровнях ценность практик Канбана: визуализации и ограничения незавершенной работы. Из-за того, что люди не видят объем интеллектуального труда, им сложно понять, какой нагрузке они подвергаются. А ведь мозг, к примеру, такая же мышца, как и бицепс. Представьте себе тренажерный зал: вы приходите и видите вес на штанге: “Так, это слишком мало. А сейчас – слишком много. А вот это в самый раз!” С мозгом нужно работать точно также: “Вот эта – большая задача, а эта – маленькая, да и вообще как-то много я на себя взвалил. Ограничу-ка я нагрузку”. Когда на всех уровнях мы делаем сквозную визуализацию потока работы и ограничиваем количество незавершенной работы, мы создаем вытягивающий принцип для интеллектуального труда и делаем равномерный поток его результатов для наших клиентов.   

12. А какие есть программы для Канбан-метода?

Их тоже много. Перечислим только профессиональные, разработанные специально под метод. Наше сердце отдано российской разработке Kaiten. Кроме нее есть еще TargetProcess, SwiftKanban, LeanKit и другие.

13. И в каких компаниях уже используется Канбан-метод?

Среди российских это Альфа-Банк, Хоум Кредит Банк, Почта-Банк, Додо Пицца, HeadHunter, Clever и другие. Из иностранных: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, Tupalo. Этот список можно продолжать долго.

14. Есть еще что-то важное?

Да. Напоследок хотелось бы отметить важность двух ролей в Канбан-методе. Это менеджер сервиса поставки (service delivery manager) и менеджер сервиса запросов (service request manager). Первый отвечает за устранение препятствий в потоке поставки. Второй – за управление потоком запросов к сервису от множества заказчиков. Очень важно, чтобы эти две роли были партнерами и работали в паре.

15. Окей, я понял. С чего начать внедрение Канбана в организации?

Чтобы начать внедрение Канбана в организациях, мы используем инструмент S.T.A.T.I.K. – системный подход к применению Канбана. Подробнее о нем можно почитать в Интернете. Но мы рекомендуем посетить тренинг Kanban System Design, на котором данный инструмент преподается в формате бизнес-игры. На примере своего сервиса (организации) вы можете спроектировать Канбан-систему для последующего применения в боевых условиях.

 

Игорь Филипьев,

Тренер и консультант по гибким методологиям, Скрамтрек.

scrumtrek.ru

Канбан в IT (Kanban Development) / Habr

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.


Для начала напишу про происхождение термина Канбан.

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

Термин Канбан имеет дословный перевод: “Кан” значит видимый, визуальный, и “бан” значит карточка или доска.
На заводах Тойота карточки Канбан используются повсеместно для того, чтобы не загромождать склады и рабочие места заранее созданными запчастями. Например, представьте, что вы ставите двери на Тойоты Короллы. У вас около рабочего места находится пачка из 10 дверей. Вы их ставите одну за другой на новые машины и, когда в пачке остается 5 дверей, то вы знаете, что пора заказать новые двери. Вы берете карточку Канбан, пишете на ней заказ на 10 дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к тому моменту, как у вас закончатся оставшиеся 5 дверей. И именно так и происходит — когда вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так постоянно — вы заказываете новые двери только тогда, когда они вам нужны.
А теперь представьте, что такая система действует на всём заводе. Нигде нет складов, где запчасти лежат неделями и месяцами. Все работают только по запросу и производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало больше или меньше — система сама легко подстраивается под изменения.

Основная задача карт Канбан в этой системе — это уменьшать количество «выполняющейся в данный момент работы» (work in progress).
Например, на всю производственную линию может быть выделено ровно 10 карточек для дверей. Это значит, что в каждый момент времени на линии не будет больше 10 готовых дверей. Когда заказывать новые двери и сколько — это задача для того, кто их устанавливает. Только он знает свои потребности, и только он может помещать заказы производителю дверей, но он всегда ограничен числом 10.
Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойоте и сейчас многие производственные компании по всему миру его внедряют или уже внедрили.

Но это всё относится к производству, а не к разработке программного обеспечения.
А что же такое Канбан разработка применительно к ПО, и чем она отличается от других гибких методологий, буть то SCRUM или XP?

Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Во-вторых, весь Канбан можно описать одной простой фразой — «Уменьшение выполняющейся в данный момент работы (work in progress)».
В-третьих, Канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.

Разница между Канбан и SCRUM:
— В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
— В Канбан задачи больше и их меньше
— В Канбан оценки сроков на задачу опциональные или вообще их нет
— В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

А теперь посмотрите на этот список и задумайтесь — что остается от гибкой методологии, если мы удаляем спринты, увеличиваем размеры задач и перестаем мерять скорость работы команды? Ничего?
Как вообще можно говорить о контроле за разработкой, если мы убираем основные инструменты контроля — сроки, скорость работы и спринты? Для меня этот вопрос является чуть ли не самым важным.
менеджеры всегда думают о контроле и пытаются его получить, хотя на самом деле никогда его не имеют. Контроль разработки со стороны менеджера — это фикция. Если команда не хочет работать, то как ее не контролируй, она провалит проект.
Если команда получает фан от работы и работает с полной отдачей, то никакой контроль и не нужен, а только мешает, увеличивает издержки.
Например, общеизвестная проблема SCRUM — это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт — 2 недели, то 2 дня из 2 недель — это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса — на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды — это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.
Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы — тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале.
Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера — это создать приоритизированный пул задач, а задача команды — выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера — это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.

Команда для работы использует Канбан-доску. Например, она может выглядеть так (взял тут):

Столбцы слева направо:

Цели проекта:
Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, «Увеличить скорость работы на 20%» или «Добавить поддержку Windows 7».

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

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

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

Тестирование:
В этом столбце задача находится, пока она тестируется. Если найдены ошибки — возвращается в Разработку. Если нет — передвигается дальше.

Деплоймент:
У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то — просто закомитить код в репозиторий.

Закончено:
Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью.

В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как «Expedite»). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна — она должна быть добавлена в «Очередь задач».

А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Например, если вы имеете 8 программистов в команде, то в строку «Разработка» вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, а значит у них будет много причин для общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача Канбан — это уменьшение времени прохождения задачи от начала до стадии готовности.
Никто не даст точный ответ, какие должны быть эти лимиты, но попробуйте для начала разделить число разработчиков на 2 и посмотреть, как это работает в вашей команде. Потом эти числа можно подогнать под вашу команду.
Под «разработчиками» я понимаю не только программистов, но и других специалистов. Например, для столбца «Тестирование» разработчики — это тестеры, т.к. тестирование — это их обязаность.

Задачи на такой доске — это не просто задачи, а то, что называется Минимальной Маркетинговой Фичей, то есть фича, которую можно «продать» клиентам.
Хорошая проверка для ММФ — это вопрос себе «А стал бы я писать про эту фичу в блоге компании?». Если нет — это не ММФ.

Что нового и полезного дает такая доска с лимитами?

Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. — делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце «очередь задач», а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться.

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

В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.

Весь Канбан можно описать всего тремя основными правилами:
1. Визуализируйте производство
— Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.
— Используйте названные столбцы, чтобы показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.
3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.

Всего 3 правила!
Например, в SCRUM — 9 базовых правил. В XP — 13, а в классическом RUP — аж более 120. Почувствуйте разницу.

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

Дополнительные ссылки (к сожалению всё только по-английски):

habr.com

что такое, с чего начать, как внедрить, главные принципы

Менеджмент Камбан в экономической практике означает такую организацию предпринимательской деятельности — будь то производство, логистика или розничная торговля — которую можно охарактеризовать как система «точно в срок». В самом термине «Kanban», который переводится с японского как «видимая карточка», заложен подход к оптимизации бизнеса за счет деления на операции и визуализации рабочего процесса. И хотя философию Kanban впервые применили в фирме «Toyota» более полувека назад, этот метод в современном понимании был разработан и предложен экономистом Дэвидом Андерсоном.

Что представляет собой система Канбан?

Экономист Дэвид Андерсон, будучи весной 2005 года в Токио, во время прогулки в Восточных садах Императорского дворца пришел к выводу, что многоразовые разноцветные пластиковые билеты для туристов, называемые Kanban могут стать инструментом экономической деятельности в условиях неопределенности. Совершив прогулку и сдав Канбан, он, по сути, завершил «условную работу». Отметки о выдаче карточек посетителям и получении их обратно контроллёры делали на специальной доске с колонками.

Андерсон пришёл к выводу, что посредством карточек и колонок можно, например, контролировать запасы на складе или поставки товаров. За счет концепции «точно в срок» удастся минимизировать материальные издержки и оптимизировать продажи. Нечто подобное еще в конце 60-х годов прошлого века использовалось в машиностроительном производстве Toyota, однако тогда количество одновременно выполняемых задач было минимальным, работы осуществлялись в соответствии со строгим алгоритмом.

Итак, Андерсон увидел в доске Канбан ценный производственный инструмент, о котором рассказал в книге «Kanban: успешные эволюционные изменения для вашего технологического бизнеса».

Что дает Канбан для производства?

Таким образом, сформулированная Дэвидом Андерсоном методология Канбан являет собой эволюционный процесс управления задачами, предполагающий точную организацию работ (поставок).

«Главный принцип заключается в том, чтобы любой труд был не напрасным, — рассказывает экономист Максим Юркин. – Канбан дает возможность бизнесмену оптимизировать этапы проекта еще до его старта на основании имеющейся у него визуальной информации о выполнении аналогичных работ. Именно на этом строится «бережливое производство».

Если сравнивать производственные процессы до и после внедрения методологии Андерсона, то видно, как день за днем снижаются материальные издержки. При этом сотрудники ориентируются на запись в карточке Канбан «Done» («сделано») «точно в срок». Предприниматели, внедрившие метод Андерсона, сообщили о росте рентабельности своего бизнеса на 25-30% — причем без каких-либо серьезных инвестиций. Со временем метод Канбан становится все более распространённым и востребованным в среднем и малом бизнесе.

Как ввести Канбан в компании?

Анализ публикаций в российских СМИ показывает, что во многих случаях под внедрением Канбан подразумевается интеграция системы поставок «точно в срок», в которой используются специальные доски с колонками “to do” (начал работу), “in progress” (работаю), ”review” (пересмотр работы), ”test” (результат), “done” (завершено). Таким образом, контролируются действия всех сотрудников и не допускается возникновение такой ситуации, когда у одного сотрудника накопилось огромное количество невыполненных задач, а другой сидит без дела.

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

4 принципа Канбан

Чтобы понять и успешно применять в своем бизнесе систему «точно в срок», нужно обратить внимание на девять фундаментальных вещей Канбан: 4 принципа и 5 правил. Начнем с принципов:

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

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

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

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

5 правил Канбан

Помимо 4 принципов Дэвид Андерсон в своей книге «Kanban: успешные эволюционные изменения для вашего технологического бизнеса» описал 5 базовых правил, которых придерживаются успешные бизнесмены:

  • Визуализация рабочего процесса.
  • Ограничение незавершенных производств (WIP — Work-In-Progress).
  • Управление потоком работ.
  • Понятность и прозрачность изменений.
  • Улучшение совместной работы (с использованием моделей и научного метода).

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

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

«Способы визуализации столь же разнообразны, как и оптимизируемые рабочие процессы, — поясняет Максим Юркин. – При классификации операций помимо потока работ и времени их исполнения могут использоваться другие критерии, такие как рыночный риск и стоимость задержек».

Если грамотно визуализировать рабочий процесс, то легко найти фрагменты WIP, которые называют «убийцами бизнеса».

«Значит, борьба с незавершенным производством должна идти в течение всего рабочего процесса, — пишет Дэвид Андерсон. – Ибо вовремя не сделанная работа «переносит» негатив на следующий шаг, а потом удвоенный негатив – на последующий шаг. И это похоже на снежный ком. Снижение WIP до нуля является краеугольным камнем Канбан».

Очень важна обратная связь. Внеся изменения, следует убедиться, что и впрямь произошло улучшение.

«Метод Канбан – это увлекательное путешествие, когда не знаешь, куда придешь, — напоминает Дэвид Андерсон. – Решение одной проблемы может вызвать усугубление другой».

Чтобы процесс внедрения изменений не «зашёл в тупик», он должен быть понятен всем участникам проекта. В этой связи логично привести еще одну цитату Андерсона: «Без четкого понимания того, как все должно работать, любое обсуждение проблем имеет тенденцию быть эмоциональным, анекдотическим и субъективным. Это верно, как реакция коленного рефлекса».

В методе Канбан ключевым является понятие Кайдзен, означающее непрерывные, инкрементные и позитивные изменения.

«Бизнесмен, интегрирующий метод «точно в срок», должен понимать, что такое Кайдзен, — считает Андерсон. — Если вы не стремитесь к совершенствованию, внедрять Канбан не имеет смысла».

Kanban vs. Agile

Понятно, что у Канбан есть противники, утверждающие, что другие концепции лучше. Между тем, эксперты призывают не путать метод Андерсона с другими признанными системами менеджмента — мол, это все равно, что сравнивать яблоки с апельсинами. Чаще всего, концепции Канбан противопоставляют:

  • Agile;
  • Scrum;
  • Lean;
  • Six Sigma;
  • PRINCE2.

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

Если Канбан предполагает непримиримую борьбу с незавершенным производством, то философия Agile в этом плане либеральнее, так как ставит во главу угла гибкость — готовность к изменениям, которые «важнее первоначального плана».

Программисты проще смотрят на «заброшенные подпроекты», если найдена более оптимальная архитектура программного обеспечения. О том, что Канбан в России является действенным методом, могут рассказать компании Dostаевский, Chernika, uKit Group и другие.

Заключение

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

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

www.equipnet.ru

Методология Kanban

канбан

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

История

Канбан впервые появилась в Японии. Там это слово переводится как «рекламный щит» или «рекламная вывеска» («кан» — видимый, визуальный, «бан» — карточка). Сам термин на японском читается «камбан», но на Западе почему-то стал записываться и произноситься с согласной «н».

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

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

Принципы Kanban

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

Временные рамки

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

Бережливое производство и уменьшение количества задач

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

Продукт таким образом собирается как бы по конвейеру. Однако элементы этого конвейера работают, когда необходимо, избавляя себя от лишнего и ненужного труда: задача выполняется не заранее, а когда появляется. Это очень легко проиллюстрировать на примере «Тойоты»: можно произвести 15 левых и пять правых дверей для машины, в итоге десять дверей останутся лишними и будут пылиться на складе. Такого не произойдёт, если делать двери по запросу сборщика автомобиля.

Визуализация

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

канбан доска

Канбан-доска — это таблица с несколькими столбцами. Внутри столбцов находятся стикеры с задачами. Рассмотрим каждый из них, а также другие важные элементы.

  • Глобальные цели. Столбец стоит в самом начале, благодаря нему команда видит, каким должен стать продукт за этот год, полгода или несколько месяцев. Например, повышение производительности на 30%.
  • Задачи в очереди. Здесь располагаются те задачи, которые можно начать выполнять.  Чем выше в столбце задача, тем выше её приоритет, начинать нужно с самой верхней.
  • Колонки с этапами работы над задачей. Задача перемещается по ним, пока не дойдёт до завершающего столбца. Их количество зависит от типа работы, иногда можно обойтись и одной–двумя. Стикер переходит как вперёд, если очередной этап выполнен успешно, так и назад, если были обнаружены дефекты на предыдущей стадии.
  • Последний столбец содержит стикеры с выполненными задачами. Перед ним полезно ставить колонку «Тест» или «Проверка». Причём не только для разработчиков ПО, но и в других сферах, чтобы перед завершением убедиться в качестве выполнения.
  • На Канбан-доске будет нелишним выделить область для срочных задач. Им будет сразу же выделяться приоритет у всей команды. При этом не может быть более одной неотложной задачи одновременно — тогда остальные тоже стоят в очереди.
  • Максимальное количество задач. Это цифра, которая ставится под каждой колонкой кроме «Целей» и «Выполнено». Исходя из численности команды, определяется, над сколькими задачами они могут трудиться одновременно. Нельзя перенести стикер в следующий столбец, если под ним стоит цифра «3», а их там уже три. Так, если члены команды обнаруживают, что рабочий процесс встал, они приходят на помощь своим товарищам, чтобы те быстрее отправили задачу на следующий этап.
  • Цвета карточек. Цвет каждого стикера тоже может нести дополнтельную информацию. Например, степень важности или срочности или необходимость пропустить несколько этапов, попав лишь в один–два определённых.

Другой инструмент визуализации — карточки Канбан. Их впервые начали использовать на заводах Toyota.

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

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

Преимущества и недостатки Kanban в сравнении со Scrum

Канбан часто сравнивают со Scrum и причисляют к Agile-методологиям. Методику можно назвать гибкой, если говорить о разработке ПО, но сама по себе Канбан лишь частично соблюдает принципы гибких методологий. Если сравнивать со «Скрамом»: в Kanban отсутствуют спринты, роли, пользовательские истории необязательны. При этом методологию часто считают более «гибкой», так как рабочий процесс практически не управляется, мало регламентируется, и результат на 90% зависит от команды и сообщения внутри неё, а не от менеджера.

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

Следует понимать, что Канбан — скорее не методология, а набор принципов. Одни считают, что легче начинать с более жёсткого Scrum, постепенно переходя к Kanban, другие же делают наоборот или сразу вводят эту методику.

Применение

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

Kanban сейчас применяется многими IT-стартапами, а также частично реализуется в ряде крупных компаний, таких как Microsoft. Методика приживается в России в ряде «околоавтомобильных» производств: «Ярославский шинный завод», на предприятии «Аком» для производства комплектующих аккумуляторов. Множество новых маркетинговых и IT компаний используют элементы методологии — Kanban-доску.

Канбан можно внедрять не только в компании или их отделы. Начинать стоит с рядовых сотрудников или с себя, если вы являетесь фрилансером или частным предпринимателем. Можно сделать персональную Kanban-доску и по ней ориентироваться в выполнении персональных рабочих задач или задач в бизнесе.

Книги о Канбан

Лучше понять суть методологии и научиться внедрять её в работу коллектива или свой бизнес поможет литература по Канбан.

  1. «Производственная система Тойоты», Тайити Оно. История о том, как методологию начали применять в Toyota. Эти практики дали старт распространению Канбан в том виде, в котором она сейчас.
  2. «10 канбан досок и их контекст», Маттиас Скарин. Статья с подборкой примеров Kanban-досок в разных сферах: разработка ПО, продажи, маркетинг.  Этот же автор написал полезную книгу «Scrum и Kanban: выжимаем максимум» о переходе от одной Agile-методологии к другой.
  3. «Канбан. Альтернативный путь в Agile», Дэвид Андерсон. Автор впервые применил Kanban в разработке ПО и рассказывает о том, как эффективно внедрять методологию в IT-сфере.

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

kogio.ru

Что такое канбан и чем он полезен?

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

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

Происхождение

Как и концепция бережливого производства (Lean), система канбан была разработана менеджерами Toyota. Автора системы, японского инженера Тайити Оно, вдохновил принцип работы американских супермаркетов, где покупатель сам выбирал нужные себе товары. Роль “супермаркета” в корпорации Toyota выполнил склад.

Там сигнальными карточками — а именно так дословно с японского языка переводится “канбан” — обменивались работники, собственноручно регулируя производственный процесс.

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

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

Производственный “канбан” заменялся на “канбан” с запросом для склада и отправлялся на производственную линию запчастей — верхний поток. Поэтому производилось именно то количество деталей, которое указывалось в карточке. Тара с новыми запчастями относилась транспортировщикам на монтажную линию.

производственный канбан

Принципы канбана

Менеджеры Toyota сформулировали 6 системообразующих правил:

  1. Исполнители из нижнего потока изымают ровно столько деталей из склада, сколько указано в канбане.
  2. Представители верхнего потока тоже поставляют запчасти строго в соответствии с карточками.
  3. Ничто не производится или не перемещается без канбана.
  4. Канбан должен быть всегда прикреплен к деталям.
  5. Бракованные запчасти не используются в системе.
  6. Уменьшение количества карточек канбан делает управление более чувствительным к переменам. Но без крайней необходимости менять устоявшееся количество карточек не стоит.

Канбан — это “вытягивающая” система. В ней создается баланс между постоянным потоком, который устраняет затраты на ожидание, и минимальным количеством работы в процессе (РВП), что снижает риски перепроизводства. РВП регулируется с помощью карточек: их количество зафиксировано, а инструкции в них направляют исполнителей нижнего потока.

Правило обязательно прикрепленной бирки работает как закон сохранения энергии.
Лимит РВП составляется в пропорции к количеству канбан-карточек, которое рассчитывается в зависимости от уровня продаж и статистической вариантности в текущих процессах. Максимальное количество бирок — та самая “энергия” в системе — закрепляет верхний уровень РВП в любое заданное время. РВП также ограничивается принципом вытягивания: скорость производства верхнего потока зависит от скорости работы нижнего.

канбан

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

Применение канбан в IT

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

Только карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, теперь прикрепляются не к таре с запчастями, а к доске с расчерченными колонками:

  • Бэклог — задачи, которые надо выполнить
  • Задачи, которые в данный момент разрабатываются
  • Задачи, которые выполнены, но еще не переданные тестировщикам
  • Задачи, готовы к передаче отделу тестирования
  • Задачи, которые проходят проверку проект-менеджером (ПМ)
  • Выполненные задачи

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

канбан в бизнесе

Структура выше не является строгой — в зависимости от специфики проекта могут быть добавлены импровизированные колонки. Нередко встречается канбан система, в которой требуется определить критерии готовности задачи перед ее выполнением. Тогда появляются две колонки, которые в английском языке называются specify (уточнить параметры) и execute (взяться за работу).

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

почему используют канбан

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

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

Kanban имеет такие достоинства:

  1. Гибкость планирования. Команда концентрируется только на текущей работе, приоритет задачи выставляется менеджером.
  2. Высокое вовлечение команды в процесс разработки. Благодаря постоянным собраниям, прозрачности процессов и возможностям самоорганизации работники сплачиваются и проявляют искренний интерес.
  3. Меньшая продолжительность цикла. Если несколько человек обладает схожими навыками, продолжительность сокращается, если же только один — появляется узкое место. Поэтому сотрудники должны делиться знаниями и тем самым оптимизировать продолжительность цикла. Тогда вся команда сможет взяться за работу, которую забуксовала,и восстановить плавный поток.
  4. Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и проблемные места, которые появились из-за дефицита внимания, людей или навыков.
  5. Наглядность. Когда все исполнители имеют доступ к данным, то узкие места легче заметить. Kanban-команды, помимо самих карточек, обычно используют два общих отчета: графики управления и совокупного потока.

На практике система отлично себя показывает в сферах неосновного производства:

  • группы поддержки программного обеспечения или службы поддержки.
  • Канбан хорошо работает при управлении стартапами без четкого плана, но где активно продвигается разработка.

Канбан имеет и недостатки:

  1. система плохо работает с командами численностью более 5 человек
  2. он не предназначен для долгосрочного планирования.

Отличия от Скрама

Скрам, как и agile kanban, является гибкой методикой и тоже часто применяется в IT-сфере. Различия между ними не очевидны на первый взгляд. Существует много схожестей, например, наличие бэклога в обоих подходах.

Скрам Канбан
Темп Повторяемые спринты фиксированной продолжительности Непрерывный процесс
Выпуск релиза В конце каждого спринта после одобрения проектным менеджером (владельцем продукта) Поток продолжается без перерывов или на усмотрение команды
Роли Владелец продукта, Scrum-мастер, команда разработчиков Команда под руководством ПМ, в некоторых случаях привлекаются тренеры по agile kanban
Главные показатели Скорость команды Ведущее время
Приемлемость изменений В ходе спринта изменения нежелательны, так как могут привести к неверной оценке задач Изменение могут случиться в любой момент

Примеры применения в IT

Сразу с Microsoft: Дебют Канбан в сфере программных разработок
Использование принципов канбана в сфере информационных технологий началось чуть более 10 лет назад. Дэвид Андерсон, один из главных популяризаторов канбана для программных разработчиков, консультировал в 2005 году компанию Microsoft. Там были недовольны работой своего отдела — XIT Sustained Engineering, который устранял ошибки во внутренних приложениях. К началу отчетного года этот отдел был худшим в своем департаменте. Бэклог превысил допустимый размер в 5 раз, а время на обработку одного запроса — ведущее время — обычно занимало 5 месяцев.

Новый ПМ с помощью консультаций Андерсона за 9 месяцев повысил продуктивность проблемного отдела на 155%. Ведущее время теперь составляло 5 недель, бэклог вернулся к нормальному размеру, а своевременное выполнение задач утвердилось на уровне 90%. Все эти результаты были достигнуты с минимальным привлечением новых работников, персонал продолжал теми же методами исправлять программные ошибки — поменялись лишь подходы к организации работы.

Интересный факт: программный менеджер Драгос Думитриу, который взялся переломить ситуацию в XIT, как раз был увлечен книгой Андерсона. К своему удивлению, он встретил идеолога программного канбана в самой компании Microsoft, куда тот накануне устроился. Думитриу попросил Андерсона помочь со своей задачей, и последний согласился применить принципы своей книги на практике.

Думитриу застал отдел, состоявший из трех разработчиков и трех тестировщиков, у которых в бэклоге накопилось 80 запросов. Сам ПМ был назначен временно, так как требования к вакансии включали умение работы с технологией ASP, администрирование с помощью SQL Server и знание MS Project Server. Начальство видело на этой должности “технаря”, который умеет программировать, должен составлять отчеты и прогнозировать загрузку бэклога. Как считалось тогда, проблема отдела будет выявлена, если собрать внушительный массив данных. Думитриу же таким “технарем” не был.

Однако начав вместе с Андерсоном анализировать работу XIT, он быстро выявил ключевые факторы, которые негативно влияли на скорость отдела:

  • На прогнозирование последствий (ROM), к которым приведет исполнение запроса, уходило слишком много времени. И разработчику, и тестировщику приходилось тратить полный рабочий день, чтобы провести необходимые вычисления, проверку кода и заполнить документацию. В среднем ежедневно приходил один запрос. По подсчетам ПМ, на ROM уходило 40% от производительности отдела;
  • Приоритет отдавался запросам с большей стоимостью. XIT получал финансирование за счет стоимости заказа. Приоритетность запросов обсуждалась каждый месяц на встрече менеджеров отдела с заказчиками — менеджерами других отделов. При распирающем бэклоге при текущий скорости, когда за месяц обрабатывались лишь 6-7 запросов, постоянно менялись приоритеты других заявок из-за проходящего времени. Многие из них были отложены на внушительное “потом”, не равное даже следующему месяцу.
  • На стадии ROM отсеивалась половина запросов. Часть из них были слишком большие и переквалифицировались в проекты с передачей другим отделам, другие являлись слишком дорогими и попросту отменялись. Некоторые запросы не брались в разработку из-за того, что их внедрение оказалось бы слишком долгим. Таким образом, 40% производительности отдела уходило на анализ запросов, 50% из которых были забракованы. Около 15-20% рабочих ресурсов тратилось впустую.
  • Подготовительная работа по запросу могла длиться месяцами, прежде чем начиналось внедрение. Вычисления на стадии ROM могли за это время затеряться или забыться. Особенно, если внедрением занимался не тот разработчик, который начинал анализ.

Канбан-решения для проблемного отдела Microsoft

  1. Думитриу и Андерсон настояли в беседе с руководством и менеджерами-заказчиками на отказе от стадии ROM. Расчеты производились непосредственно перед внедрением и тем же исполнителем, то есть оставались “свежими”.
  2. Приоритизация запросов проводилась не в ходе ежемесячных совещаний, а по ситуации, посредством телефонных звонков или электронных писем. 80 задач в бэклоге рассортировали в зависимости от заказчиков. Последних попросили выделить главные запросы, которые нужно выполнить в первую очередь.
  3. Финансирование XIT стало фиксированным.
  4. Стоимость запросов перестала браться в расчет.
  5. ПМ ввел буферы на канбан-доске. Разработчики брали работу из двух зон: одобренные и выполненные задачи. В буфере находились 6 запросов, 5 брались в работу. Тестировщики выбирали из буфера “ожидает тестирования”. Некоторые задачи, которые не требовали изменений в коде, попадали туда, минуя разработчиков. Разбив запросы на однозадачные процессы, ПМ мог лучше контролировать ситуацию, а также обеспечить прозрачность для заказчиков. Введение буферов уменьшило ведущее время. Заказчики в условиях предсказуемой системы стали лучше определять, чей запрос должен попасть в буфер следующим.
  6. По слишком большим или дорогим запросам решение принималось сразу. Если разработчик подтверждал, что он готов выполнить задачу в течение 15 дней или изменения стоят того, то запрос брался в работу вне зависимости от размера или стоимости.
  7. Понаблюдав за потоком в отделе, ПМ пришел к выводу, что структуру штата стоит изменить в пользу разработчиков, которые были больше загружены работой. Изменения проводились в соотношении 2:1: в XIT стали работать 4 разработчика и 2 тестировщика.

Канбан-решения для проблемного отдела

По итогу 2005 года производительность отдела выросла на 155%. Чтобы еще улучшить работу XIT, туда привлекли двух сотрудников: одного разработчика и одного тестировщика. Количество запросов в бэклоге снизилось до 10, а один разработчик стал стабильно обрабатывать 11 заявок за квартал. В среднем за квартал завершались 56 запросов против 11 ранее. Стоимость запросов упала с $7500 до $2900.

Применение в компании Corbis

Добившись успеха в Microsoft, Андерсон в 2006 году приступил к решению новой сложной задачи. Теперь он работал в Corbis — другой компании Билла Гейтса, который тогда еще не покинул MS. Одним из видов деятельности Corbis было лицензирование фотографий. На тот момент это был второй крупнейший в мире фотосток с базой около 3,5 тыс. снимков.

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

В офисе Corbis появилась канбан-доска, у которой Андерсон ежедневно беседовал с коллективом. Целью ПМ было улучшить визуальный контроль над процессами, способствовать самоорганизации и большей персональной ответственности исполнителей. Также система канбан была направлена на уменьшение надзора со стороны менеджеров и увеличение производительности.

канбан доска

Кроме разноцветных карточек и графиков, на доске появилась “мусорная корзина” — в нее отправлялись задачи слишком большого размера.

канбан доска

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

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

Лимиты для канбан-карточек дважды устанавливались эмпирическим путем. В колонке “готово для разработки” лимиты были увеличены. Также появилась новая колонка — “готово для тестирования”. Многие запросы для нижнего потока были некорректно сформулированы, вызывая лишние затраты времени. Поэтому ПМ исследовал работу верхнего потока и нашел ошибки.

Обработка запросов могла занимать 100 дней, но релизы все равно стали выходить раз в две недели, как и планировалось. Решение по содержимому выпуска принималось за 5 дней до публикации. Практика подсчетов, как и в случае с отделом XIT Microsoft, была отброшена в пользу продуктивности. Приоритет задачам расставлялся согласно “стоимости задержек” или готовности ресурсов.

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

Приложения и программы для Канбана

Trello

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

Kanbantool

Бесплатная доска для двух пользователей. Поддержка API и touch-интерфейсов.

Lean Kit Kanban

Бесплатная доска для пяти пользователей с хорошей реализацией совместной работы. Поддержка API и возможность импорта/экспорта, широкая статистика.

Kanbanize

Полностью бесплатный сервис с достойной функциональностью. Его владельцы гарантируют прирост в производительности на 300% при использовании их приложения.

Worksection

Украинское saas-приложение для быстрого отслеживания и управления проектами. Сейчас в функциях кроме учета финансов, сроков и диаграммы Ганта есть настраиваемая канбан-доска.

Вердикт

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

Однако успешные изменения требуют времени. Они проходят постепенно, при этом сопротивление команды новшествам — минимальное. Канбан система мотивирует персонал совершенствоваться без изменений в инженерных методах.

Автор: Е. Федченков

Источник: материалы сайта worksection.com

blog.iteam.ru

Канбан «на пальцах» | Статья | dev.by

Agile разработка — это система ценностей, а не процесс

Agile-манифест — это короткий набор из четырех фраз, которые показывают, что на самом деле важно (http://en.wikipedia.org/wiki/Values ) для практиков Agile. Эти фразы аналогичны словам «За Родину! За Сталина!», с которыми советские солдаты шли в бой. В них не определены конкретные процессы, но общего призыва было достаточно, чтобы сообщество само выработало определенные практики. (Для более детального обзора культуры и системы ценностей мира agile, читайте Agile is Culture, Not Process.

Agile практики берут лучшее из… фуршетов

Некоторые процессы считаются «Agile», если системы ценностей, лежащие в их основе, близки к системе ценностей Agile. Scrum и экстремальное программирование – яркие и наиболее распространенные примеры таких процессов. Куда менее известные, но не менее важные – Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD). Каждый из этих процессов объединяет несколько хороших практик и описание составляющих фаз процесса. Если бы вы выписали все хорошие практики из этих процессов, вы бы получили фуршетный стол, заставленный очень хорошими практиками, которые можно использовать для создания собственного процесса. И это именно то, чем занимается большинство организаций. Обычно люди проходят курс Certified Scrum Master, где узнают про роль Scrum Мастера в Scrum, но сегодня вы освоите основы Scrum, все его роли и составные фазы, а в довесок узнаете много дополнительных практик, которые не были упомянуты в первоначальном описании Scrum Кена Швабера и Майка Бидла. Чаще всего начинают с пары практик экстремального программирования: управления требованиями через пользовательские истории (user stories) и способом планирования релизов. Нормальным считается сокращение длины спринта в Scrum с одного месяца до пары недель, использование способа эстимирования из экстремального программирования, завершение каждой фазы ретроспективным митингом наподобие оного из Crystal или DSDM. Я лично добавляю такие практики, как дизайн и тестирование пользовательского интерфейса, визуализация пользовательских историй и более формализованные роли продукт оунера (Product Owner) и заказчика. Изначально простой Scrum рискует стать большим неповоротливым монстром. Сегодняшний типичный Agile процесс, вне зависимости от того, как вы его называете, берет лучшее с фуршетного стола Agile практик, чтобы сформировать такой процесс, где:

  1. Нужды и требования проекта выражаются в виде пользовательских историй, помещенных в беклог. В идеале эти истории формируются продукт оунером (в SCRUM) или заказчиком (в экстремальном программировании) совместно с командой.
  2. Разработчики дают высокоуровневые оценки на время разработки пользовательских историй.
  3. Продукт оунеры группируют пользовательские истории в последовательные релизы (итерации, спринты и т.д.), каждый из которых длится от шести недель до шести месяцев.
  4. Продукт оунеры выбирают следующие истории для каждой фазы, начиная с приносящих наибольшую пользу. Выбранные истории должны «вписываться» в заданные временные рамки.
  5. К концу каждой фазы команда успевает инкрементально увеличить ценность продукта. Итоговый продукт демонстрируется продукт оунеру и другим стейкхолдерам.
  6. Команда сохраняет оценки времени для каждой истории. Они используются в будущем для рассчитывания числа историй, которые можно добавить в следующую фазу.
  7. Команда проводит ретроспективные митинги, чтобы проанализировать свою работу в ходе фазы и понять, что можно сделать лучше в следующей фазе.
  8. Пофазная разработка длится вплоть до выпуска финальной версии продукта

Конечно, есть и другие общепринятые практики, такие как ежедневные stand-up митинги для синхронизации статусов членов команды и burn-down диаграммы для отображения прогресса разработки, но и приведенных достаточно, чтобы выразить мою мысль: сегодняшний типичный Agile процесс представляет собой разнообразнейшую смесь хороших идей, взятых из различных источников.

Медленные изменения общепринятых практик приводят к проблемам

Во многих организациях типичный Agile процесс работает вполне успешно. Однако есть некоторые часто встречающиеся проблемы. Лично я сталкивался с теми, что так или иначе связаны с размером: размер всегда имеет значение (Далее по теме — Тайна уменьшающейся истории)

Уменьшение историй облегчает Agile разработку

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

Уменьшение историй усложняет Agile разработку

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

Короткие фазы облегчают Agile разработку

Планирование короткой фазы занимает меньше времени. Изначально взятые из экстремального программирования, фазы (или итерации) должны были длиться по 2-4 недели. Первоначальная концепция Scrum предполагала, что спринт должен длиться один календарный месяц, так что разработку было легче синхронизировать с бизнес месяцами и квартальными циклами. Каждый, кто хоть раз посещал Agile митинги по планированию фаз, знает, что они часто длятся ровно на час больше того времени, что вы готовы вытерпеть. Короткие итерации — например на неделю-две — позволяют планированию проходить быстрее. В наши дни типичная продолжительность Agile фазы сократилась до двух недель. Мы быстрее получаем обратную связь при коротких фазах разработки. В конце Agile фазы у нас есть возможность просмотреть финальную версию продукта и внести соответствующие изменения в продукт беклог. Также мы можем измерить скорость разработки команды, а на ретроспективном митинге можно предложить и воплотить в реальность улучшения процесса. Такие частые возможности оценки продукта по скорости разработки и используемому процессу позволяют быстро реагировать на проблемы и делать Agile собственно Agile’ом.

Короткие фазы усложняют Agile разработку

Короткие фазы перегружают. Проработка деталей пользовательской истории выходит за рамки фазы: Идеальная Agile фаза отличается частым общением между разработчиками, тестировщиками и командой продукт оунера — бизнес аналитиками, UX специалистами и, собственно, представителями бизнеса. Это делается для четкого понимания того, что необходимо создать, и детального описания того, что необходимо проверить при готовности. Короткие фазы оставляют меньше времени для общения. Обычно уточняющие историю и ее прием митинги проводятся за фазу до фазы реализации этой истории. Некоторые практики Scrum начинают задумываться над определением готовности истории к реализации: что именно должно быть сделано для того, чтобы историю можно было начинать реализовывать. Тестирование не вкладывается во временные рамки фазы: при короткой фазе сложно полностью проверить готовность истории. Так часто тестирование не вкладывается в одну фазу и переносится на следующую, что влечет за собой цепочку багов из предыдущей фазы, которые «внезапно» проявляются в текущей фазе. Как результат, эти не вкладывающиеся в одну фазу активности обычно занимают в 3-4 раза больше, чем одна фаза. Фактически, приходится выделять одну фазу на подготовку к истории, одну на разработку, одну на тестирование и еще одну на устранение найденных дефектов. Уровень общения в команде снижается, а параллельно приходит усталость. При уменьшении фаз и члены команды продукт оунера, и тестировщики внезапно оказываются в жестких временных рамках: им надо одновременно чинить баги с прошлой фазы и готовиться к следующей. Они много работают, посещают кучу митингов и, как результат, не могут уделять достаточно времени разработчикам, работающим над текущей фазой. Поскольку они сфокусированы не на текущей фазе, любые вопросы по ней воспринимаются как отвлечение. Взаимодействие в команде снижается, а вместо него приходит напряженность в отношениях. Члены команды перегружены, раздражены и не могут спокойно работать.

Вписывается ли бережливое мышление в Agile?

В течение последних нескольких лет много практиков Agile начали внедрять принципы бережливой разработки в свои Agile методы. Принципы, изначально изложенные Томом и Мери Поппендиками в их книге Lean Software Development , теперь широко используются по всему миру как в чистом виде, так и в комбинации с Agile методами. Недавно я заметил большое количество обсуждений разработки в стиле Канбан — подходе, который нарушает основное правило Agile разработки — наличие временного ограничения на разработку одной фазы. Несмотря на то, что про Канбан говорят и пишут многие, Девид Андерсон одним из первых осваивал эту тематику и до сих пор является евангелистом Канбан.

Канбан в бережливом производстве

Бережливая разработка ПО позаимствовала много терминов из японского языка и из системы производства Toyota в частности. Слово «Канбан» состоит из двух частей: «Кан» означает «визуальный, видимый», а «бан» означает карточку или доску. Представьте себя на производственной линии Тойота. Вы вставляете двери в Приусы. У вас есть стопка из 10 или около того дверей. Вы постепенно вставляете двери в корпуса, уменьшая вашу стопку. Когда вы убираете шестую дверь, оставляя ровно пять дверей, на верхней двери обнаруживается карточка Канбан, на которой написано «установите 10 дверей». Ну, может, надпись немного другая, но смысл такой — вам надо установить еще 10 дверей на эти Приусы. Вы берете эту карточку и бежите с ней к товарищу, который занимается производством дверей и уже ждет вас. Он занимался другими делами, чтобы не скучать, ожидая вас. Что важно, он НЕ делал двери для Приусов. Он берет вашу карточку и начинает делать двери. Вы идете обратно на ваше рабочее место и ровно тогда, когда ваша стопка кончается, «дверной» товарищ приходит с новой стопкой из 10 дверей. Вы знаете, что между пятой и шестой дверями уже лежит следующая Канбан карточка на вставку еще 10 дверей в Приусы. Ну а эти двери пришли как раз вовремя. Весь этот процесс отработал на «ура». Эх, если бы вы занимались производством дверей. У «дверного» товарища, судя по всему, куча свободного времени. Карточки Канбан используются для ограничения количества производимых фабрикой деталей. Тойоте невыгодно производить двери быстрее, чем осуществляется сборка машин. При таком подходе деньги тратятся на избыточные двери и их компоненты. Избыточная работа, осуществляемая в процессе производства, воспринимается как потери в бережливом производстве (да и не в бережливом производстве избыточная работа – это тоже траты). В примере выше (полностью, кстати, выдуманном) у вас никогда не будет больше 15 дверей на установку. («Муда» – «потери» по-японски. Используйте это слово, чтобы удивить ваших бережливых друзей). Используя Канбан карточки, мы поставили лимит в 15 дверей. В этом аспекте можно провести параллели между Канбан карточками и бумажными деньгами. Как и в денежной системе присутствует четко ограниченное количество напечатанных денег, в системе бережливого производства присутствует четко ограниченное количество деталей, ограниченное Канбан карточками. Если призадуматься, это достаточно простой способ ведения дел. Кори Ладас хорошо разъясняет этот принцип в своих статье и книге.

Разработка с Канбан ограничивает количество незаконченной работы

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

  • Отменяется разработка по фазам с четкими временными границами
  • Пользовательские истории больше, а их самих меньше
  • Оценка (estimation) сводится к минимуму или убирается насовсем
  • Внимание переходит со скорости разработки на продолжительность цикла

Теперь вы наверняка чешете себе затылок: а что вообще тогда остается от Agile, если мы отказывается от фаз с четкими временными границами, меняем значение и размер пользовательских историй и перестаем замерять скорость разработки? И, собственно, какое отношение имеют двери Приусов и Канбан карточки к разработке ПО? Не зацикливайтесь на процессе, помните: Agile разработка — это не процесс.

Канбан разработка как она есть

Канбан разработка крутится вокруг визуальной доски, которую мы используем для управления незаконченной работой. (Неудивительно, учитывая перевод слова «Канбан»). В Agile пользовательские истории часто располагают на доске с колонками, представляющими собой стадии, через которые проходит история, например, «разработка» или «тестирование». Канбан доска похожа на эту доску, но при этом добавляет некоторое количество других правил. Эта доска была создана на основе досок, фотографии которых я нашел в Yahoo Основной идеей является то, что истории стартуют с левого края доски и проезжают всю доску слева направо, попутно проходя через те фазы разработки, без которых эти истории нельзя будет назвать завершенными. Завершенные истории, готовые к запуску в продакшн окружении, копятся на правом краю доски. И, поскольку это Канбан доска и мы собираемся ограничивать количество незавершенной работы, мы ограничим количество пользовательских историй, одновременно находящихся на доске. Числа, написанные снизу каждой колонки, представляют собой максимальное количество историй, допустимое в данной конкретной колонке. Этот пример Канбан доски был сделан на уайтборде с помощью стикеров, маркеров и синей изоленты.

Канбан доска — слева направо

1. Goals — цели

С самого левого края Канбан доски расположена колонка целей. Здесь мы найдем глобальные цели – крупные вещи, к которым мы стремимся и под которые поднастраиваем наше программное обеспечение. Оставляя цели на самом краю доски, мы фокусируем всех членов команды на одном: на достижении этих целей. Эта идея была взята у Арло Белши, который опытным путем определил, что размещение целей на левой стороне доски Канбан существенно снижает объем «мусора» на доске. Под «мусором» здесь понимается частое изменение приоритетов отдельных Канбан карточек.

2. Stories queue — очередь историй

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

3. Стадии разработки истории

Справа от очереди историй расположены колонки со стадиями разработки, через которые должна пройти история, чтобы считаться выполненной. Первая колонка часто используется для стадии прорабатывания истории. В командах разработки Yahoo она помечается как UED — user experience design. История должна находиться в этой колонке, если в данный момент осуществляется прототипирование UI или описание истории расширяется до необходимого для разработки уровня. У вас же может быть отдельная колонка для стадии, когда бизнес аналитики аккумулируют необходимые для разработки доменные знания. Следующая колонка часто используется для собственно разработки, а следующая за ней — для тестирования. Эти колонки не фиксированы. Вы должны обсудить с вашей командой те стадии, через которые проходит история, прежде чем помечаться как «выполненная». В некоторых компаниях отдельные колонки могут выделяться под написание документации или под подготовку инженеров поддержки для выпускаемой функциональности. Колонки — не роли в команде. Пускай часто и совпадает, что в отдельной колонке работают люди одной роли в команде, фокус должен делаться не на этом, а на выполнении истории и на том, что ей необходимо для выполнения. Например, если в вашей компании не используются бизнес-аналитики или дизайнеры пользовательского взаимодействия, используйте первую колонку для совместной проработки историй разработчиками и представителями бизнеса. Здесь же стоит определить критерии «готовности» истории. Просто взять и начать писать код (следующая стадия) — плохой ход, особенно если у вас нет критериев, по которым вы сможете оценивать готовность вашей работы. Каждая стадия разделена на две части: верх используется для историй, находящихся в разработке, а низ — для буфера историй. Когда

dev.by

Отправить ответ

avatar
  Подписаться  
Уведомление о