Канбан. Альтернативный путь в Agile - Дэвид Андерсон

Кан-бан – японское слово, которое дословно переводится как «сигнальная доска». В производстве такая доска используется для визуализации нарастающего темпа производства, что позволяет давать больше продукции. Сотрудники на каждом этапе процесса не могут перейти к следующей фазе работы, пока посредством канбан-доски не будет дан соответствующий сигнал. Хотя я знал о существовании этого механизма, я не был убежден, что он полезен или даже жизнеспособен применительно к интеллектуальной работе, особенно к разработке ПО. Я понимал, что канбан обеспечивает оптимальный темп, но не знал о его хорошей репутации в качестве метода стимулирования пошагового улучшения процессов. Я не знал, что Тайити Оно, один из создателей производственной системы Toyota, говорил: «Два основных принципа системы производства Toyota – это “точно-в-срок” и автоматизация с участием человека, или автономизация. Для управления системой используется инструмент – это и есть канбан». Иными словами, канбан жизненно важен для процесса кайдзен («непрерывное улучшение»), применяемого в Toyota. Это механизм, который заставляет систему работать. Сейчас, имея за плечами пятилетний опыт, я принимаю это как абсолютную истину.

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

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

Я стал предпочитать этому сложному словосочетанию термин «канбан». Он используется в бережливом производстве (то же, что производственная система Toyota). Эта совокупность знаний получила гораздо большее распространение и признание, чем теория ограничений. Канбан, несмотря на свое японское происхождение, менее метафоричен, чем барабан, буфер и канат, вместе взятые. Это слово легче произносить, объяснять и, как оказалось впоследствии, преподавать и внедрять. Вот оно и закрепилось.

Возникновение канбан-метода

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

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

Принятие канбана в сообществе

В мае 2007 года Рик Гарбер и я представили первые результаты работы в Corbis на конференции по бережливой разработке новых продуктов в Чикаго. Доклад слушали примерно 55 человек. Летом того же года на конференции Agile 2007 в Вашингтоне я предложил провести круглый стол по обсуждению системы канбан – на него пришло человек двадцать пять. Через два дня один из присутствовавших, Арло Бельши, произнес краткую речь, в которой рассказывал о своем методе «обнаженного планирования»{6}. Оказалось, что и другие компании внедряют у себя вытягивающие системы. Так, в Yahoo! была создана дискуссионная группа, которая быстро набрала сотню членов. А сейчас в нее входит уже более 1000 человек. Некоторые из участников моего круглого стола решили попробовать Канбан на своем рабочем месте – нередко с командами, которые безуспешно боролись со Scrum. Самые известные из моих ранних последователей – Карл Скотланд, Аарон Сандерс и Джо Арнольд, все из Yahoo!. Эта компания быстро внедрила Канбан в более чем десяток команд на трех континентах. Еще один заметный участник круглого стола, Кендзи Хиранабе, разрабатывал канбан-решения в Японии. Вскоре после конференции он написал на эту тему две статьи для InfoQ{7},{8}, которые вызвали большой интерес. Осенью 2007 года Санджив Огастайн, автор Managing Agile Projects{9} и основатель Организации руководителей гибких проектов (Agile Project Leadership Network, APLN), посетил Corbis в Сиэтле и описал наши канбан-системы как «первый новый agile-метод, который я увидел за пять лет».

На следующий год на конференции Agile 2008 в Торонто состоялось шесть презентаций решений канбан разного формата. Одна из них была проведена Джошуа Кериевски из Industrial Logic – компании по обучению и консалтингу в области экстремального программирования. В ней он продемонстрировал, как пришел к похожим идеям по взятию на вооружение принципов экстремального программирования и их улучшению в контексте его бизнеса. В тот год Agile Alliance вручил приз Гордона Паска Арло Бельши и Кендзи Хиранабе за их вклад в agile-сообщество. Как я понял, он состоял в одном случае во внедрении Канбана, а в другом – в разработке и пропаганде на удивление схожих идей.

Ценность канбана неочевидна

Во многих отношениях интеллектуальная деятельность противоположна идее массового производства. И уж совершенно точно разработка ПО не похожа на промышленное производство. У этих отраслей промышленности совершенно разные свойства. Для производства характерна низкая вариативность, а разработка ПО в основном вариативна. Более того – она стремится использовать эту вариативность, чтобы благодаря новинкам дизайна получить больше доходов. Неслучайно в английском названии программного обеспечения – software – есть элемент soft («мягкий»): ПО можно легко и безболезненно трансформировать, а производство концентрируется на «жестких» вещах, менять которые тяжело. Вполне естественно поэтому выглядит скептицизм по поводу ценности канбан-систем в разработке ПО и других IT-сферах. Большая часть из того, что наше сообщество за последние несколько лет усвоило о Канбане, противоречит интуиции. Никто не мог предсказать того эффекта, который Канбан оказал на корпоративную культуру и на улучшение межфункционального сотрудничества в Corbis (см. главу 5). Я надеюсь доказать вам, что Канбан способен на многое. Хочу убедить вас, что, внедрив простые правила Канбана, вы сможете повысить производительность, предсказуемость и удовлетворенность пользователей, а также сократить срок работы. Благодаря этому изменится культура вашей организации, поскольку рост объемов совместной работы позволит установить лучшие, более функциональные отношения.

Выводы

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

• Применение Элияху Голдраттом теории ограничений, известной как «барабан-буфер-канат», является альтернативным способом внедрения вытягивающей системы.

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

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

• Первая виртуальная канбан-система для программирования внедрялась в Microsoft с 2004 года.

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

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

• В этой книге термин «канбан» (с маленькой буквы) относится к сигнальным доскам, а «канбан-система» (с маленькой буквы) – к вытягивающей системе, использующей (виртуальные) сигнальные доски.

• Слово «Канбан» (с большой буквы) относится к методологии эволюционного пошагового улучшения процесса, которая зародилась в Corbis в 2006–2008 годах и продолжала развиваться в более широком сообществе разработчиков, связанных с бережливым программированием.