Персональный канбан: как научиться выполнять работу точно в срок

The 6 Practices of Kanban

When aiming to implement the Kanban method, every organization must be careful with the practical steps. There are six core practices as identified by David Anderson that need to be present for successful implementation.

1. Visualize the Workflow

A simple Kanban Board

To visualize your process with a Kanban system, you will need a board with cards and columns. Each column on the board represents a step in your workflow. Each Kanban card represents a work item.

The first and most important thing for you is understanding what it takes to get an item from a request to a deliverable product. Only after understanding how the flow of work currently functions can you aspire to improve it by making the necessary adjustments.

When you start working on item X, you pull it from the “To Do” column, and when it is completed, you move it to “Done”. This way, you can easily track progress and spot bottlenecks.

2. Limit Work in Progress

Digital Kanban Board with WIP Limits

One of Kanban’s primary functions is to ensure a manageable number of active items in progress at any one time. If there are no work-in-progress limits, you are not doing Kanban. Switching a team’s focus halfway through will generally harm the process, and multitasking is a sure route to generating waste and inefficiency.

Limiting WIP means implementing a pull system on parts or the complete workflow. Setting maximum items per stage ensures that a card is only “pulled” into the next step when there is available capacity. Such constraints will quickly illuminate problem areas in your flow so you can identify and resolve them.

3. Manage Flow

Managing the flow is about managing the work but not the people. By flow, we mean the movement of work items through the production process.

One of the main goals when implementing a Kanban system is to create a smooth, healthy flow. Instead of micro-managing people and trying to keep them busy all the time, we should focus on managing the work processes and understanding how to get that work faster through the system. This would mean that our Kanban system is creating value more quickly.

4. Make Process Policies Explicit

You can’t improve something you don’t understand. This is why your process should be clearly defined, published, and socialized.  People would not associate and participate in something they do not believe would be useful.

When everyone is familiar with the common goal, they would be able to work and make decisions regarding a positive impact.

5. Feedback Loops

For teams and companies that want to be more agile, implementing feedback loops is a mandatory step. They ensure that organizations are adequately responding to potential changes and enable knowledge transfer between stakeholders. An example of such a feedback loop is the daily stand up meeting for team synchronization. It takes place in front of the Kanban board, and every member tells the others what they did the previous day and what they will be doing today.

There are also the service delivery review, the operations review, strategy review, and the risk review meetings. The frequency depends on many factors, but the idea is that they are regular, at a strictly fixed hour, straight to the point, and never unnecessarily long.

The ideal average length of a stand up should be between 10-15 minutes, and others may reach up to an hour or more depending on the team size and topics.

6. Improve Collaboratively (using models & the scientific method)

The way to achieve continuous improvement and sustainable change within an organization is through a shared vision of a better future and a collective understanding of the issues that need fixing.

Teams with a shared understanding of their goals, workflow, process, and risks are more likely to build a shared comprehension of a problem and work together towards improvement.

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

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

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

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

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

Проведя утро на солнышке, мы направились на выход, где стояла очередь к киоску. Когда она немного продвинулась вперед, я понял, что это люди возвращают пластиковые карточки, которые были входными билетами. Я залез в карман и вынул наши карточки. В киоске находилась японка в униформе. Между нами была стеклянная перегородка с полукруглым вырезом у стойки, как в кассе кинотеатра или парка развлечений. Я передал наши карточки. Дама взяла их руками в белых перчатках и положила в стопку к другим. Никаких денег не требовалось. Никакого объяснения, зачем я два часа с момента входа в парк носил с собой белые пластиковые карточки, дано не было.

Что же это за входные билеты? Зачем их выдавать, если они бесплатные? Сначала я предположил, что это связано с безопасностью. Подсчитав все возвращенные карточки, администрация могла убедиться, что внутри не осталось никого постороннего после закрытия парка на ночь. Однако затем я понял, что если речь идет о безопасности, то это какая-то очень сомнительная схема. Как они могут знать, что мне дали не одну карточку, а две? Моя трехмесячная дочь — это посетитель или багаж? Система казалась слишком вариативной. Чересчур много возможностей для ошибки! Если бы это действительно была схема безопасности, то она была обречена на провал и ежедневно давала бы ошибки первого рода.

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

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

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

Описание процесса

1. Вся команда собирается вокруг доски. Если команда распределенная и доска электронная, то все открывают и созваниваются.
2. Желательно назначить того, кто будет ведущим. Это может быть кто-то из команды или любой другой человек, кто умеет проводить открытые обсуждения.
3. Идем по колонкам справа налево и по задачам сверху вниз. Суть в том, что самая правая колонка означает завершение работы, поэтому задачи, которые стоят ближе всех к завершению, имеют высокую ценность. Чем быстрее мы переведем задачу в самую правую колонку, тем меньше будет Lead Time.
4. В нашем примере самая правая User Story 754. Ведущий спрашивает: «Что мешает нам переместить задачу 754 в колонку Deployed?». Несколько человек могут сказать причину и объяснить, что мы ждем подтверждения от руководителя компании. В этом случае задача явно помечается стикером или комментарием, что она заблокирована по причине такой-то.
5. Следующая User Story 75. Ведущий задает тот же вопрос. Например, один из членов команды, кто отвечает за тестирование на Pre-Production среде, говорит, что берет эту задачу себе в работу. Он берет карточку с задачей и «тянет» ее в колонку Test on Pre-Production System. На этой задаче отмечаем, кто взял ее в работу стикером.
6. Дальше идем по всем задачам, которые есть на доске, пока ресурсы команды не закончатся. Каждый возьмет себе задачи в работу, чтобы на следующем стендапе перенести задачи в следующие колонки или рассказать, что блокирует работу.

1. Что мешает движению задачи?
2. Как задача двигается по потоку?
3. Что можно улучшить?

Определение канбана

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

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

Канбан-доска

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

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

• задачи, которые нужно выполнить,

• задачи, над которыми уже ведется работа,

• выполненные задачи. 

Это базовая модель, но ее можно дополнить, добавив туда группы, актуальные для вашего продукта/компании (код на стадии тестирования, идеи в разработке, планы и т.п.). 

Канбан-карточка

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

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

А что насчет ограничений в других колонках?

Колонка «Готово» свободна от лимитов — чем больше работы сделано, тем лучше!

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

И все-таки иметь небольшой «буфер» задач полезно. У них может быть разный приоритет и сложность

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

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

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

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

Стратегия внедрения системы

Стратегия внедрения предполагает осуществления 6 шагов:

1. Обеспечение следующих процессов от поставок предыдущих процессов.
2. Изготовление на предыдущих стадиях только того, что изъято для последующих.
3. Обеспечение перемещения только качественных изделий без дефектов.
4. Создание выровненного производства.
5. Закрепление за каждой деталью канбана.
6. Снижение со временем числа канбанов.

Все этапы внедрения можно разделить на 3 фазы:

№ 1. Планирование в рамках системы

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

№ 2. Циркуляция канбанов

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

№ 3. Усовершенствование производства

• Уменьшается количество канбанов, что позволяет осуществить тонкую настройку, поскольку пи этом проявляются скрытые проблемы.
• Задействуются средства визуального управления:
  • маркировка мест хранения деталей между процессами,
  • установка сигнальных ламп для оповещения о процессах на конвейере (дефектах, проблемах на линии, нехватке запасов и др.),
  • размещение канбанов над линией для отслеживания статуса детали.
• Удобное размещение карт так, чтобы сразу были видны время цикла, запасы, порядок обработки.

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

Источник

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

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

ПО	Лучше всего для
JIRA	Для разработки программного обеспечения Agile-командами. Не лучший вариант для нетехнических команд и процессов вне системы Agile. Идеальный вариант – для IT компаний с большим штатом разработчиков.
Trello	Для частного и командного использования в разных областях (маркетинг, продажи, HR, и т.д.) которым необходим функционал Kanban. Не лучший вариант для Agile-разработчиков. Идеальный вариант – индивидуальное использование Канбан-досок.
Hygger	Преимущественно для Agile-команд разработчиков. Поддерживает Kanban и Scrum, estimations, Burndowns, Swimlanes и WIP limits. Предлагает качественную приоритизацию бэклога. Идеальный случай – любая Agile-ориентированная команда.
MeisterTask	Для тех же потребностей, что и Trello, но с улучшенной интеграцией с MindMeister.
Favro	Для мелких и средних команд разработчиков. Поддерживает Kanban и Scrum процессы.
Asana	Для персонального использования и для небольших команд, которым преимущественно нужны to-do листы и базовый функционал Канбан доски.
Kanbanchi	Для персонального использования Канбан досок с тесной интеграцией с G Suite.
Paymo	Для агентств и команд, которым нужно автоматически отслеживать время, приоритизировать задачи и следить за рабочим временем.
Breeze	Для команд, которым нужна усовершенствованная версия Basecamp с базовым Kanban-функционалом.
Blossom	Лучше всего для распределенных команд. Минималистичный инструмент для управления проектами, построенный на основе Kanban-досок.
ProofHub	Для команд, которым необходимо полноценное решение с Kanban-досками, диаграммами Ганта, календарем, заметками, обсуждениями, листами задач. Это своеобразный Basecamp «на стероидах».
ZenHub	Это плагин для GitHub, который добавляет поддержку Multi-repo Boards, Epics, индивидуальных рабочих пространств и улучшенный репортинг.
Taiga	Опен-соурс программа для разработчиков, которым нужно проверять задачи и пользоваться стандартным набором для управления проектами.
Leankit	Для создания кастомизированных досок с детальным потоком задач.

LeanKit

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

Истории должны быть «минимальными доставляемыми функциональностями»

Термин «минимальная доставляемая функциональность» (minimal marketable feature — МДФ) был впервые использован в книге Программное обеспечение в числах. Акцент в этой книге ставится на самый маленький объем работы, который можно запустить в продакшн и принести тем самым пользу конечным пользователям. Чтобы стать «минимальной доставляемой функциональностью», функциональность должна быть достаточно велика, чтобы быть полезной. Очевидно, при таком определении МДФ изначально больше тех мелких историй, которым требуется не больше пары дней на реализацию и которые представляют собой основную массу историй в Agile беклогах наших дней. МДФ же может разрабатываться по несколько недель. Однако, здесь важна не продолжительность разработки истории, а то, будет ли она понятной и полезной конечным пользователям. Некоторые личности используют следующий вопрос для определения МДФ: «Упомяну ли я об этой функциональности в блоге моей компании?». Если эта функциональность слишком мала, чтобы упоминать о ней в корпоративном блоге — это не МДФ. Фокус на увеличении ценности выпускаемого продукта — одна из важнейших концепций Канбан разработке. Каждая функциональность должна быть ценна сама по себе.

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

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

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

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

Распределение Lead Time

Но самое интересное начинает происходить, когда мы начинаем собирать статистику Lead Time  по рабочим элементам. Тут-то и раскрывается вся сила и мощь Канбан-метода. Мы получаем в свои руки объективные данные, которые однозначно указывают на характеристики и проблемы в рабочем процессе, и диктуют правильные решения. У менеджера появляется козырь при разговоре с руководством, так как его прогнозы по срокам зиждутся на статистических данных, а не ощущениях или «экспертных оценках».

Собрав нужные данные, менеджер сможет с вероятностью 80-90% предсказывать точный срок завершения той или иной задачи. И это будет не гадание на кофейной гуще, а научно обоснованный подход к проблеме.

На диаграммах ниже собрана статистика по времени выполнения задач (Lead Time) по разным типам работ. Диаграмма «Распределение 1» показывает статистику для задач типа «мелкий дефект», а диаграмма «Распределение 2» — для задач типа «средней сложности дефект».
Такая диаграмма распределения показывает, сколько задач выполнялось за то или иное время. По горизонтальной оси откладывается количество дней, за которые завершилась задача, а по вертикальной оси — количество задач, которые были завершены за то или иное количество дней.

Видно, что в «Распределении 1» разброс значений меньше, и сама диаграмма уже. Это означает, что основная масса задач типа “мелкие дефекты” завершается за 10 дней, и есть лишь редкие задачи этого типа, которые завершаются либо быстрее, либо медленнее.

«Распределение 2» показывает гораздо больший разброс значений, и это означает, что точность предсказания срока выполнения задач типа «средней сложности дефект»  будет ниже, но и тут можно предсказать, что с вероятностью 91% любая задача такого типа будет сделана за 25 дней.

Имея такие данные, можно давать статистически обоснованные обещания, и договариваться об SLA, точность которых будет около 90%. Точность прогноза в 100% требуется редко: в основном, для задач, стоимость задержки которых крайне высока. Точности 80-90% вполне достаточно для обычных задач.

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

Сколько вешать в граммах?

Каким количеством Kanban предлагает ограничивать задачи «в работе», чтобы коллектив справлялся с ними в оптимальные сроки? Универсального ответа нет. Единственный совет — экспериментируйте!

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

Если колонке N скопились задачи, а N+1 почти все время пустует, — это признак перегруженности. Ограничение надо ужесточать.

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

Жизнь МДФ истории на Канбан доске

Этот рассказ начинается с очереди МДФ историй, терпеливо ждущих на левой стороне Канбан доски. Они расположены рядом с целями так, что каждый может видеть, что эти МДФ помогают в достижении целей. Дизайнер пользовательского взаимодействия и бизнес аналитик, работая в паре, берут верхнюю историю из очереди и сдвигают все остальные вверх. Вытянутая история помещается в колонку «проработка в процессе». Они определяют необходимых для проработки стейкхолдеров и обсуждают с ними критерии приема готовности истории. Они встречаются с разработчиками, чтобы убедиться, что определенные ранее критерии понятны и достаточны для начала разработки. Все выражают свое согласие. Бизнес аналитик говорит «Значит я помещаю эту историю в буфер». «Нет нужды, мои активные слоты пусты — я сразу помещу историю в них и начну ей заниматься» — говорит разработчик. Использование системы Канбан вовсе не означает, что мы разрабатываем по модели водопада. Поскольку на доске все истории упорядочены слева направо, многие ошибочно считают, что Канбан исключает совместную работу над историей. Заметьте как бизнес аналитики и дизайнеры поработали вместе со стейкхолдерами и разработчиками. Они были ответственны за выполнение взятой истории, но это вовсе не означало, что они должны сделать все сами и не помогать никому с другими историями. В здоровом Канбан процессе есть множество мест, когда члены команды работают вместе. Продолжая работу над историей, мы видим, что она движется по доске слева направо, как только все, от кого зависит работа над историей на определенной стадии, делают все возможное, чтобы история вышла из этой стадии и пошла дальше. Они никогда не перебрасывают историю на следующую стадию, не выполнив своих обязательств. Они знают, что если перенести незавершенную историю в буфер, ответственные за следующую стадию просто не возьмут эту историю и отправят ее на доработку. Такой подход делает взаимодействие между членами команды и полноценное общение критически важными. Передвижение истории в обратном направлении – слева направо – вполне обычная ситуация. Чаще всего такое происходит, когда кто-то из следующей стадии считает, что качество работы предыдущих стадий можно немного улучшить. Проходит время, истории прорабатываются, перемещаются в разработку, а потом и в тестирование. Но вдруг случается маленький затык. Разработчики только что закончили свою историю и, подойдя к Канбан доске, чтобы перенести выполненную историю в буфер своей колонки, они видят, что в их буфере нет мест и колонка тестировщиков тоже забита под завязку. И что теперь? Разработчики идут к тестировщикам. — «Ребят, мы тут реально на всех фронтах загружены со своими историями. Свободные слоты появятся не раньше завтрашнего утра.» — «Хммммм», – говорят разработчики, – «А мы можем помочь тестировать?» — «Конечно вы можете!», – говорит тестировщик. — «С вашей помощью мы разгребемся уже к сегодняшнему вечеру». – Тестировщик улыбается, – «Только я не дам вам проверять сделанную вами же историю.»

Ограничения выявляют узкие места

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

Задачи, основной метод и принципы работы системы канбан

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

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

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

Основные принципы концепции:

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

Постоянных установок концепция не содержит, эти принципы направляют действия руководителя.

Зачем нужны карточки kanban

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

• для производства есть две разновидности. В первых содержится информация о числе деталей, необходимых для следующей ступени. Карточка передается с высшей ступени на низшую, сообщение обрабатывается, дальше отправляются новые карточки с информацией для следующих ступеней, где указано что необходимо от конкретной структуры. Во вторых, указан общий объем производства, информация от низшей ступени к высшей о количестве полученных деталей/продукта;
• для управления, HR, IT и пр. Карточка служит маркером, цвет стикера относится к определенной задаче, которая передается по всем этапам и должна дойти до логического завершения. Отслеживание помогает выявить моменты, где задача или процесс тормозит, почему так происходит и что нужно для того, чтобы завершить начатое. 

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

Что такое доска kanban

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

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

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

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

Что такое Kanban?

Kanban — метод управления разработкой, где во главу угла ставится принцип выпуска продукта в точно установленный срок. Это второй в мире по популярности метод Agile-трансформации после фреймворка Scrum. 

Задачи в рамках проекта визуализируются на доске (само слово «канбан» в переводе с японского означает «доска» или «вывеска») для наглядности прогресса по каждой задаче и проекту в целом. Доски Kanban могут значительно отличаться друг от друга в зависимости от проекта (количество столбцов, их цвета и проч.), однако любое их исполнение всегда направлено на то, чтобы сделать рабочий процесс максимально понятным для всех участников.

Так, в рамках большого исследования эффективности Kanban Journal of Software Engineering Research and Development были установлены такие результаты применения метода, как снижение сроков выпуска программных продуктов на уровне до 78% (с 30,5 до 6,8 рабочих дней), а также ускорение внесения изменений в уже существующие продукты на 73% (с 9,2 до 2,5 рабочих дней). 

Рынок корпоративных услуг по Agile-трансформации к 2026 году достигнет $63,83 млрд при показателе средних годовых темпов роста в 19,5%, говорится в исследовании Allied Market Research. Ускорение разработки цифровых продуктов и сервисов, оптимизация командной работы и качества коммуникаций в рамках ИТ-проектов стимулируют эту динамику.

Сегмент Scrum традиционно доминировал, составляя более половины объема рынка методологий Agile-трансформации. Сегодня его позиции также незыблемы — 58%. Тогда как «чистый» Kanban занимает 7%, добавляя еще 10% за счет гибридного подхода Scrumban. 

По прогнозам аналитиков, именно Kanban ожидают наиболее высокие темпы роста в отрасли.

Базовые принципы 

Существует два типа основополагающих принципов, на которых базируется метод Kanban:

1. Принципы управления изменениями.

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

2. Принципы предоставления сервисов. 

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

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

Инструменты Kanban

Сервисов для ведения Kanban-досок в онлайн достаточно много. Есть универсальные решения, например, Jira от Atlassian или всем знакомый Trello. Однако для серьезных проектов в ИТ стоит использовать специальные, профессиональные инструменты: TargetProcess, SwiftKanban, LeanKit. Самый топ в этом сегменте — это российская разработка Kaiten.

В Kanban используются специфические метрики для измерения потенциала команды и оценки продолжительности проекта.

Командная скорость (team velocity) определяет, сколько задач может выполнить команда в заданный период времени, например, за неделю. Знание скорости команды помогает лучше предсказать, когда будет завершен необходимый объем задач. 

Время выполнения и время цикла (Lead time/Cycle time) определяют среднее время, необходимое для выполнения задачи. Время выполнения вычисляется с момента, когда команда получает запрос от клиента до завершения работ, а время цикла вычисляется с момента начала работы над задачей. 

Показатель времени выполнения используется, чтобы понять, как долго пользователь (клиент) будет ожидать оказание сервиса, а времени цикла — для вычисления, как быстро команда производит продукт

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

Actionable Agile-метрики позволяют использовать время цикла, чтобы лучше предсказать, когда будет закончен каждый отдельный элемент проекта. Созданные Даниэлем С. Ваканти в 2015 году actionable-метрики помогают измерить, сколько времени потребовалось, чтобы закончить определенный объем работ по проекту — 50%, 85% и т.д. Далее эти данные позволяют команде лучше прогнозировать и контролировать сроки выполнения работ.

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