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

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

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

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

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

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

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

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

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

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

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

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

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

Так как же команды визуализируют рабочий процесс?

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

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

Когда команда хочет внедрить Канбан, она прежде всего визуализирует рабочий процесс на канбан-доске. Например, одна из первых канбан-досок в книге Дэвида Андерсона «Канбан. Альтернативный путь в Agile» имеет следующие столбцы: «входящая очередь», «анализ» (в процессе, готово), «готово к разработке», «разработка» (в процессе, готово), «готово к сборке», «тестирование» и «готово к релизу». Эта доска будет использоваться командой, которая следует за процессом, где каждая функция проходит через анализ, развитие, сборку и тестирование. Поэтому она может начать c такого варианта канбан-доски, как показано на рисунке 9.1, на которой есть колонки с текущими рабочими элементами.

Рис. 9.1. Пример того, как рабочие элементы, написанные на бумажках, перемещаются по канбан-доске. Дэвид Андерсон в своей книге «Канбан. Альтернативный путь в Agile» использовал именно такой вариант доски, но названия колонок могут отличаться в зависимости от того, как члены команды выполняют свою работу