Постигая Agile

Это очень удобно для старшего разработчика, желающего «выстрелить и забыть». Ведь он уверен: допущенные им погрешности будут устранять другие люди, которых он и знать не желает. В краткосрочном плане это очень неплохой способ работы для одного человека, но с точки зрения команды и в долгосрочной перспективе это неэффективно. Без всякого сомнения, ошибки должен исправлять тот, кто их сделал. Он уже знает детали кода, потому что писал его и хорошо в нем разбирается. Чтобы исправлением занялся кто-то другой, нужно затратить усилия на коммуникацию. Правда, иногда достаточно отправить письмо по электронной почте, но порой необходимы дополнительные документы (например, отчет об ошибке и обновленная спецификация). Человеку, который займется исправлением, потребуется время, чтобы разобраться в коде. Программист, создавший его, исправит погрешность за несколько минут, а другим понадобятся часы или дни (особенно если это новички или недостаточно опытные разработчики).

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

Любая (даже не гибкая) команда может стать высокопроизводительной, если введет правила, запрещающие своим старшим членам передавать «скучные» задачи младшим по должности. Но по-настоящему успешной scrum-команде не нужно создавать специальных правил для подобных ситуаций. Причина в том, что все ее участники наделены подлинным чувством ответственности за каждый аспект проекта. Поэтому старшим членам команды никогда не придет в голову желание «свалить» технические задачи на младших коллег. Они поступят разумно, выполнив ту работу, которая необходима прямо сейчас (вспомните CEO, который пошел за кофе для сотрудников)[38]. Исправление ошибок и другие задачи обслуживания просто добавляются в бэклог спринта, рассматриваются во время ежедневных scrum-митингов и выполняются надлежащими людьми в определенное время. (И последний ответственный момент для исправления ошибок, возможно, как раз именно сейчас, потому что разработчик еще ничего не забыл.)

В успешной scrum-команде все чувствуют свою сопричастность не только к коду, который создают, но и к бэклогу, и каждый старается делать все возможное, чтобы поставить работающее программное обеспечение. Бэклог спринта – это ответственность каждого, даже самый молодой разработчик ощущает, что именно он сделал для пользователей. Вот что подразумевает Кен Швабер под коллективной ответственностью в цитате, приведенной в начале этой главы: каждый член команды разделяет ответственность за бэклог и чувствует персональную ответственность за поставку наиболее ценного работающего программного обеспечения, необходимого пользователям, – включая все функции, а не только те, над которыми работает лично он.

Как же достичь такого чувства командной ответственности, чтобы каждый – от младшего разработчика, старшего технического руководителя, scrum-мастера и до владельца продукта – добровольно взял на себя решение неинтересных задач только потому, что заботится о проекте?

Повышение мотивационных целей каждого члена команды

Вы когда-нибудь были волонтером? Содействовали проекту с открытым исходным кодом? Вступали в клуб, любительскую спортивную команду, рок-группу, церковный хор? Подумайте о том случае, когда вы присоединились к группе, не имеющей отношения к вашей работе или семье. Зачем вы это сделали?

Вы присоединились к группе и, вероятно, отдавали ей немало своего времени и сил, потому что вас интересовала главная цель ее существования. Если это был штаб избирательной кампании, то вас беспокоила явка людей на выборы. Если футбольная команда – то вас волновала победа (и качественная игра). Так почему же на работе должно быть по-другому?

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

Но достаточно ли этого, чтобы нас по-настоящему волновало создание работающего программного обеспечения?