Kanban. История вопроса. Почему его так любят в ИТ?

 Если вы не слышали об "Scrum", то скорее всего вам попадалось выражение "Канбан" или "Канбан-доска". 
Про "Agile" или на кириллице "Аджайл", вы возможно тоже где-то слышали. 

Но не суть, давайте вернемся в историю и вспомним вехи развития этих ныне модных слов в IT - индустрии и не только. 

Как это не удивительно прозвучит, но понятние "Kanban" на много старше "Agile" и уж тем более понятия "Scrum". (Воу-воу подожди, еще одно не знакомое слово). Об этом чуть позже. 

Как гласит легенда, в 1940 году Таичи Оно (Taiichi Ōno ), молодой и перспективный инженер, тогда еще не известной локальной компании "Toyota", производившей в числе прочего тракторы и другую технику для сельского хозяйства, сформулировал подход: 

Производить только то, что необходимо, когда это необходимо и в необходимом количестве. /To produce only what is needed, when it is needed and in the amount needed. 

Taiichi Ōno

Но, если копнуть в историю еще глубже, оказывается понятие "Kanban" появилось в 16 веке, когда в Японии после войн феодальных войн (если ближе к нашей истории когдаб по нашему князья, боролись за каждый клочек земли), стабилизировалось положение и, начался экономический рост. В торговых кварталах растущих городов, начали активно открываться магазинчики и ремесленными лавки, которым необходимо было привлекать клиентуру. Именно на этих улицах родилось понятие "Kanban".

Так вот слово "КанБан" состоит из двух слов, как это не редко бывает в восточных странах, где в языке используются иероглифы.

«Кан» 看 означает «знак» и «Бан» 板 означает доска.

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

Карточка или вывеска должны четко и лаконично доносить смысл информации размещенной на ней.

И так что же такое "Канбан"?

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

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

Взятая стратегия на исправление ситуации дала шанс таким как инженер Таичи Оно (Taiichi Ōno ) на эксперименты и изменение бизнес-процессов в производстве.

1. Перепроизводство изделий. Требования клиентов меняются
2. Большие складские запасы

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

Помог опыт розничной сети в Америке Piggly Wiggly.

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

Таичи Оно (Taiichi Ōno ) заимстовал этот приницип и теперь на производстве, когда товарный запас был использован в производстве изделия, карточка возвращалась. 

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

Ну ок, а как все это применимо к разработке софта (программного обеспечения) и продуктов, спросите вы?

По мере того, как успехи Toyota на мировом рынке, особенно после топливного кризиса 1976 и успеха на американском рынке (Здесь вам задачка самим понять, почему этот год стал прорывом для компании). Система TPS (Toyota Production System) все больше захватывала умы менеджмента по всему миру. Восьмидесятые стали началом старта выпуска консьюмерской электроники, персональных компьютеров, а их необходимо было наполнять программным обеспечением. А так как это новая инженерная задача. Ну да вы возразите мне, а как же IBM, Xerox и другие глобальные компании к тому времени уже выпускавшие сервера, программы для управления этим хозяйством.

Персонализация и создание продукта для человека с учетом его потребностей, что стало в конечном итоге основным фактором успеха Toyota. 
Как же это может быть применимо в разработке софта?
90-е стали годами, когда с ростом персональных компьютеров, скорости и распространения интернета, растущий спрос со стороны потребителей, необходимо было кормить. 
Во главу угла стала скорость и качество (минимальное кол-во ошибок/багов).
Можно ли было управлять классическим каскадным методом (WaterFall)?
А что по поводу конвейера от компании Ford?
Ну система TPS - это же, что доктор прописал?

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

Примерно в то же время управление проектами в программном обеспечении уже постепенно переходит от громоздких и неэффективных процессов, таких как CMMI, к более легкому, «гибкому» подходу, который был формализован в Agile Manifest, опубликованном в 2001 году.

Манифест Agile и лежащие в его основе принципы содержали общие советы, такие как «Приветствуйте изменяющиеся требования» или «Часто поставляйте работающее программное обеспечение», но не указывали, как этого следует достичь.
Свято место пусто не бывает, несколько систем управления работой быстро развились, чтобы заполнить этот пробел, охватив Манифест и став ядром Agile-разработки программного обеспечения в то время. Наиболее заметными из них были Scrum, eXtreme Programming и чуть позже Lean Software Development.

Элементы Scrum, Lean Software Development и Agile Management оказали значительное влияние на то, что должно было стать методом Канбан.

Скрам/Scrum

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

Бережливая разработка программного обеспечения

В 2003 году Мэри и Том Поппендик опубликовали ставшую уже классической книгу по разработке программного обеспечения «Бережливая разработка программного обеспечения: набор инструментов Agile». Книга перевела принципы бережливого производства из производственной системы Toyota в область разработки программного обеспечения и знаний. Он сосредоточился на устранении потерь, отображении потока создания ценности и на вытягивающих системах. В 2007 году за ней последовала еще одна книга тех же авторов «Внедрение бережливой разработки программного обеспечения: от концепции до наличных», в которой более подробно изучалось использование теории очередей для сокращения времени доставки программного обеспечения и доски Канбан как элемент визуального рабочего пространства. Кроме того, в 2005 году Джим Саттон и Питер Миддлтон опубликовали «Стратегии бережливого производства программного обеспечения», в которых были определены пять принципов бережливого производства — определение ценности, отображение потока создания ценности, реализация потока, поддержание процесса вытягивания, поиск возможностей улучшения — и применялись они к программному обеспечению. Разработка.

Kanban/Гибкое управление

Помимо Scrum и Lean Software Development, были изучены и другие концепции того, как команды могут стать более гибкими. В 2004 году Дэвид Андерсон опубликовал книгу «Гибкое управление для разработки программного обеспечения: применение теории ограничений для бизнес-результатов», в которой были рассмотрены такие понятия, как поток, узкое место, визуальный контроль и кумулятивная блок-схема, которые он позже включил в метод Канбан. .

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

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

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

В классической методологии Scrum после сеанса планирования спринта бэклог Spring замораживается, в него нельзя внести никакие изменения. Это состояние обычно длится от 7 до 30 дней по мере того, как команда продвигается по бэклогу, и иногда это может разочаровывать как разработчиков, так и конечных пользователей. Что делать, если возникла чрезвычайная ситуация, а конкретную функцию нужно внедрить быстро? Что делать со всеми ошибками, обнаруженными в действующем продукте — конечным клиентам нужно ждать больше месяца, чтобы их исправили? И, наконец, как управлять процессами, которые по своей природе более динамичны, например, маркетинг веб-сайтов или администрирование серверов?

Метод Канбан с его досками Канбан и фокусом на потоке стал ответом на это, предоставив хорошо структурированный, наглядный и гибкий способ управления работой.

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

2009: Канбан набирает обороты

Поистине золотым годом для Канбана был 2009 год.

В январе 2009 года, опираясь на свой опыт работы в Corbis, Кори Ладас опубликовал книгу «Scrumban: очерки канбан-систем для бережливой разработки программного обеспечения», в которой была сделана попытка смешать Scrum, Lean и Kanban.

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

В мае 2009 года в отеле Mandarin Oriental Hotel в Майами состоялась конференция Lean Kanban 2009 года, организованная Дэвидом Андерсоном. На нем были представлены последние разработки в области применения бережливого мышления к разработке программного обеспечения.

После конференции было сформировано неформальное Общество WIP ( Limited WIP Society), задача которого заключалась в объединении и распространении знаний о методе Канбан. Общество предоставило платформу для сбора статей о Канбане, что способствовало дальнейшему распространению информации об этом методе.

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

Также в 2009 году появились первые веб-приложения для управления проектами и бизнес-процессами с помощью метода Канбан, создав основу для более широкого внедрения принципов Канбан за пределами индустрии программного обеспечения: Agile Zen, Kanban Tool и LeanKit Kanban.

2010 год: Канбан для всех

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

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

В марте 2010 года Хенрик Книберг и Маттиас Скарин опубликовали бесплатную мини-книгу «Канбан и Скрам — максимальное использование обоих», которая позже была переведена на 14 языков.

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

В 2011 году Джим Бенсон и Тонианна ДеМария Бэрри опубликовали книгу «Персональный канбан», в которой показано, что канбан можно успешно применять и на личном уровне.

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

Наконец, в 2016 году был опубликован «Essential Kanban Condensed», в котором применение Канбана было разделено на пять практик:

+ Визуализируйте рабочий процесс

+ Ограничить незавершенную работу

+ Измеряйте и управляйте потоком

+ Сделать политики процесса явными

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

Выбор за вами. Подойдет ли вам метод KANBAN управления проектами, процессами, разработкой и развитием продукта.

(Вольный перевод статьи.
Оригинал по ссылке:https://kanbantool.com/kanban-guide/kanban-history)