Надо заметить, что название «альтернативный путь в Agile» есть только в русском переводе, и, говорят, появилось по настоянию издательства для лучших продаж книги. Оригинал называется «Kanban. Successful Evolutionary Change for Your Technology Business». И в сообществе периодически возникает дискуссия о том, является ли Kanban Agile-методом. С моей точки зрения, безусловно, является. Во-первых, исторически: Андерсон его именно так и позиционировал в своих ранних работах и выступлениях на Agile-конференциях, например, «Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results» (2003). Кстати, она явно показывает один из основных источников – теорию ограничений. Во-вторых, по содержанию: если посмотреть на набор практик, описанный в книге Андерсона, то в целом он хорошо соответствует набору практик Scrum, а также принципам Agile. Что не удивительно, потому что они в целом отражают эффективные методы для IT-разработки. А, в третьих, на уровне культуры: хотя Kanban стартует от существующего процесса и не предъявляет требования какой-либо особой Agile-культуры, прозрачность потока создания ценности, ориентация на его улучшения и сотрудничество со смежниками неизбежно ведет к изменению культуры как раз в том направлении, в котором это сформулировано в Agile-манифесте.
Отмечу, что книгу Андерсона можно читать на двух уровнях. Первый уровень, находящийся на поверхности, показывает набор различных практик, которые постепенно появлялись в методе. А второй уровень показывает логику, в которой эти практики появлялись. В книге Андерсона два уровня: первый показывает набор практик, а второй – эволюционную логику их появления.
Второй уровень значительно важнее первого, потому что именно он показывает логику разворачивания эволюционного процесса улучшений, который и составляет суть Kanban. В книге Андерсон показывает тут путь, который прошли его команды. Следуя духу Kanban, ваши команды пройдут свой путь в той же логике, но стартовав от других начальных условий, и прийдя, естественно, к другому набору используемых практик, потому что этот набор будет зависеть от специфики и условий вашего проекта. И, вероятно, это будут вовсе не простой набор практик, скорее всего, схема процесса будет сложнее, чем фреймворк Scrum, зато она будет отражать вашу специфику. Во всяком случае, то, что получилось у Андерсона и описано в книге – сложнее, поэтому ее и не рисуют.
Доска и проектирование Kanban-системы
Итак, каким образом работает Kanban? Как уже говорили, все начинается с анализа и визуализации на доске существующего потока работ. Об использовании досок в Agile я писал в главе «Доска – визуализация текущего состояния работы», где как раз достаточно подробно раскрывал их работу на примере Kanban. Я не буду повторяться, однако помещу тут картинку из той статьи с описанием основных элементов и приемов, просто чтобы напомнить. Основным результатом визуализации является эмпатия к доске: сотрудники, глядя на доску, понимают текущую ситуацию с работой, и доверяют этому представлению. Отмечу, что такая визуализация иногда сама по себе дает очень большой эффект, проявляя большое количество скрытых проблем: проявляет скрытую работу, выявляя очереди и зависимость команды от смежников, разбираясь с обязательными и не обязательными этапами, а также их последовательным и параллельным выполнением.
