Легко понять, что команда, исповедующая Scrum, использует систему. Но что если ваша команда не применяет подобные методы? Может быть, вы просто погружаетесь в работу над программным обеспечением? Выглядит все так, будто вы каждый раз запускаете проекты по-разному. Поэтому вы не имеете системы, правда?

Но самое забавное, что люди – особенно команды – всегда стремятся следовать правилам. Они могут быть не записаны, и мы нередко придумываем их, если они не существуют. Но правила существуют на интуитивном уровне, и если они засели в голове, то от них трудно избавиться. Даже когда вам кажется, что вы действуете спонтанно, появление нового человека в команде все расставит на свои места: вы очень быстро обнаружите, что он нарушает привычные для вас правила.

Lean предлагает инструмент, чтобы принять неписаные правила и превратить их в систему: систематизирование потока создания ценности.

Когда вы берете ММФ (минимальную маркетинговую функцию, о которой мы узнали в главе 8, – например, историю, требование или пользовательский запрос) и выявляете систематизированный поток ценности, ведущий к написанию кода, вы должны записать путь через вашу систему.

Если вы работаете в команде, которая придерживается неписаных правил, то вполне вероятно, что одна ММФ сильно отличается от другой. Но поскольку люди интуитивно следуют правилам, довольно вероятно, что вы можете наметить небольшое количество потоков создания ценности, охватывающих основные ММФ, которые ваша команда превращает в код. Если вам удастся сделать это, то вы сможете создать очень точное описание системы, которой следует ваша команда. Прежде всего система решает, какой поток создания ценности MMФ будет из нее вытекать.

Полезно иметь систему, которая работает одинаково для всех, даже если есть много различных путей для ММФ. Как только вы поймете, как работает система (то есть увидите целое), вы сможете принимать решения о том, какие пути расточительные, и заниматься постепенными изменениями подхода к разработке.

Канбан – это не методология разработки программного обеспечения и не система управления проектами

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