Совершенствование процесса с Канбаном

Мы уже знаем, что Канбан – это метод, который направлен на улучшение процесса, базируется на ценностях Lean и бережливого мышления. Он был разработан Дэвидом Андерсоном, который первым начал экспериментировать с идеями Lean во время работы в Microsoft и Corbis. Так же как Lean, название «канбан» связано с идеями разработки на автомобильных производствах в Японии. Но что делает Канбан гибким? Чем он отличается от традиционного процесса улучшения?

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

Если вы разработчик, уже переживший типичную попытку усовершенствования процессов, то, скорее всего, поспешите отложить книгу в сторону, прочитав это описание.

Термин «усовершенствование процесса» часто вызывает в воображении образ героя комиксов по имени Дилберт. Он ассоциируется с бесконечными совещаниями и процессами, полными технологической документации, потому что типичное улучшение процесса сильно отличается от идеального. В случае типичного процесса совершенствования крупная компания решает, что их программисты производят программное обеспечение недостаточно эффективно (или что они нуждаются в сертификации процесса для заключения контрактов либо для маркетинговых целей), поэтому нанимают консалтинговые компании, тратят много времени (и денег) на создание блок-схем существующих и желаемых процессов развития и обучают команды использовать новые процессы. Затем команды тратят около 10 минут, чтобы опробовать один из новых процессов, выясняют, что он им не подходит, и отказываются от него. Но поскольку топ-менеджеры проспонсировали весь процесс усовершенствования усилий, команда вынуждена делать вид, что использует нововведения, поэтому усердно заполняет любые документы по новым требованиям (например, область применения документа и техническое задание) и создает обязательные артефакты (протоколы собраний для просмотра кода и отчеты о тестировании, которые, как правило, пусты и шаблонны). Для каждого успешного процесса совершенствования усилий (их несколько) есть много ничего не дающих или вовсе неудачных попыток приложения усилий, побочный продукт которых – глубокая неприязнь к термину «улучшение процесса».

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

Как Канбан помогает команде улучшить собственный процесс?

Визуализация рабочего процесса

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

Представьте, что вы программист, а ваш руководитель приходит к вам и спрашивает: «Как ты ведешь разработку программного обеспечения?» Ваша задача – написать, как вы делаете свою работу. Поэтому вы запускаете Visio (Omnigraffie или другое приложение диаграмм) и начинаете создавать блок-схему, показывающую все то, что вы делаете каждый день. Иногда будет обнаруживаться, что замечательные практики, такие как обзор кода (или тестирование кода, прежде чем его выпустить, и т. д.), вы действительно применяете, но не каждый раз. Полагая, что это надо делать всегда, и вы наверняка иногда так делаете, вы добавляете этот элемент в свою схему. Такова человеческая природа. Легко найти оправдание собственным поступкам – если это хорошая идея, значит, можно создать уверенность в том, что все это время вы применяете такие практики.

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