Постигая Agile

Обычно нам не нравится слушать теоретические рассуждения – когда говорят нечто подобное, это обычно признак того, что не видят здесь возможности немедленного практического применения. Однако во многом это на самом деле правда о Lean, так как Lean – это мышление. Оно не включает практик, которые ваша команда могла бы применять ежедневно, как Agile-манифест или Scrum и XP-ценности. Но, как и Agile-манифест, Scrum и XP-ценности, Lean является правильным мышлением, очень ценным для команды, если вы хотите лучше писать программное обеспечение.

В главе 2 мы ввели идею раздробленного видения. На протяжении всей книги вы видели много примеров, как это приводит к тому, что команда либо получает результат «лучше-чем-ничего», либо (в худшем случае) приходит к полному провалу проекта. Бережливое мышление помогает вам взглянуть с высоты птичьего полета не только на проект, но и на всю команду, компанию, ее правила, политику и культуру, которые вызывают у вас серьезные проектные проблемы.

Вернемся в начало этой главы и посмотрим на lean-ценности еще раз. Эти ценности помогут взглянуть на ту работу, которую вы делаете прямо сейчас.

Как только вы начинаете искать потери, вы замечаете их повсюду («устраняйте потери»). Вы перестаете видеть программу как набор отдельных задач и начинаете воспринимать ее как систему («видеть целое»). Вы будете использовать такие инструменты, как «пять “почему”», чтобы выйти за пределы фиксации отдельных проблем в работе, которую сделала команда, и распознать системные проблемы, влияющие на проект снова и снова («усиление обучения»). Каждая lean-ценность изменяет способ, которым вы смотрите на проект, команду и компанию. Это поможет вам увидеть более широкую перспективу.

В главе 9 вы узнаете, как обзавестись этой новой точкой зрения и использовать ее для реальных, постоянных изменений, чтобы улучшить создаваемое вами программное обеспечение.

Вы сказали, что «мури» может переводиться как «невозможно», но разве это не отрицание? Ведь считается, что все возможно при наличии мотивированной команды, верно?

Если бы только это было правдой. Проведем мысленный эксперимент, чтобы показать вам, что некоторые вещи действительно невозможны.

Представьте себе, что CEO вашего небольшого стартапа заходит в офис и говорит, что ваш самый крупный клиент зациклен на Бруклине. Руководитель кладет пакет зубочисток и палочек для мороженого на стол и сообщает: если ваша команда сможет сделать идеальный макет Бруклинского моста из зубочисток и палочек для мороженого к моменту появления клиента, то тот утроит бизнес компании и сделает вас богатыми. Если же работа не будет выполнена на отлично, то он уйдет к конкуренту, и тогда вашей компании конец.

Клиент будет здесь менее чем через час. Все за дело! Нет ничего невозможного! Вы сможете сохранить вашу компанию, верно?

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

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

Это мури. Еще раз прочтем определение, которое мы дали ранее: «неразумность, невозможность, перегруженность, излишняя сложность, пересиливание, принуждение, превышение, чрезмерность».

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

Что вы можете сделать сегодня

Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с вашей командой).

• Определите все ММФ в вашем проекте. Как они достигаются? Вы пишете истории пользователей на карточках или стикерах и помещаете их на доску задач? Есть ли у вас индивидуальные требования в спецификации? Найдите большую функцию или историю и решите, сможете ли вы разбить ее на более мелкие куски.

• Ищите потери в вашем проекте. Запишите примеры муда, мура и мури.