Часто слышу, что Канбан
- не итеративный процесс. Это утверждение используют как аргумент, демонстрирующий
преимущество над Канбаном Скрама и других фреймворков, методологий,
использующих фиксированные итерации. Другие считают, что это Канбан - «гибкий
фреймворк» или «Аджайл методология». Хочу ответить очень коротко:
- Канбан - НЕ ПРОЦЕСС
- Канбан - НЕ ФРЕЙМВОРК
- Канбан - НЕ МЕТОДОЛОГИЯ
И сравнивать
его со Скрамом или XP имеет
такой же смысл как сравнивать ложку с вилкой.
Scrum и XP описывают жизненный цикл разработки,
в то время как Канбан – техника,
которая предлагает изменения в уже действующий процесс в команде. Это
своеобразная «присадка».
Так позиционирует Канбан его создатель – Дэвид Андерсон.
«Для того, чтобы избежать непониманий,
следует знать, что Канбан не яляется ни процессом, описывающим жизненный цикл
разработки программного обеспечения, ни процессом проектного менеджмента.
Канбан – техника, которая требует изменений в существующий процесс; изменений
вроде ограничения WIP» (“Kanban”, David Anderson, 2010)
В одной из LinkedIn групп я несколько раз замечал, как Дэвид акцентирует внимание
на этом важном концепте и говорит о том, что Книберг неправильно понял
основные концепции Канбана. Он принял его за очередной гибкий процесс, хотя Канбан
не является таковым. Назвать его «гибкой присадкой», как мне кажется, было бы
намного уместнее.
«Гибкий» паразит
Канбан
ОБЯЗАТЕЛЬНО должен базироваться на каком-либо уже существующем в команде
процессе. Им может быть Скрам или XP, а может быть и Водопад. За
сочетание с последним очень часто Канбан критикуют, забывая одну важную, на мой
взгляд, деталь. Она заключается в том, что правильным образом внедренный Канбан
закладывает «бомбу» замедленного действия под Водопад.
Канбан
привносит в родительский процесс культуру Кайзен, стимулирует формирование
самоорганизующихся команд. Должным образом внедренный Канбан, меняет саму
культуру организации и процесса, ведя команды и целые компании к Аджайл.
