Постигая Agile

Попробуйте поставить себя на место такого менеджера. Взгляните на команду как на своего рода «черный ящик», создающий программное обеспечение. Вы говорите программистам, что хотите получить, ждете несколько дней, и программное обеспечение появляется на свет. Если один из разработчиков готов трудиться допоздна и в выходные, то он сразу привлечет к себе ваше внимание своим энтузиазмом. Это подарок для вас как для руководителя: сваливайте всю работу на него, и она будет сделана. Затем воздайте этому человеку должное, и, возможно, другим придется начать работать таким же образом.

Похоже, чем сильнее ваше давление на команду, тем выше отдача от нее. Чем щедрее вы вознаграждаете «полуночников» и тех, кто может быстрее других продраться через хаос, тем больше программ они создают. А как вы оказываете влияние на людей? Вы убеждаетесь: они знают, что им всегда предстоит сделать еще больше работы, а то, что в настоящее время ими дорабатывается, должно быть как можно быстрее «вытолкнуто» к потребителю.

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

Такой менеджер использует магическое мышление.

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

Но дело тут не только в менеджерах с магическим мышлением. Здесь имеет место симбиоз с героем – герой готов работать сверхурочно, творить «чудеса» ради признания, лидерства и, возможно, более высокой зарплаты. Он становится эталоном, с которым сравнивают всех других членов команды. Руководитель не хочет разбираться в том, как фактически спроектировано и написано программное обеспечение или сколько плохо проработанных временных заплаток превратились в долгосрочные решения. Таким образом, главным мерилом того, кто является наиболее ценным членом команды, становится количество отработанных часов в неделю.

Магическое мышление воспринимается хорошо. Неважно, кто вы: менеджер, «мотивировавший» команду, или «герой», который очень много работал, чтобы получить готовое программное обеспечение, – вам кажется, что вы решили серьезную проблему. Но программа, разработанная под воздействием магического мышления, вызывает больше вопросов, чем решает их: технический долг накапливается, ПО никогда не достигает состояния «полностью завершено», а качество и тестирование не всегда являются «желательными». Слишком часто появляются ошибки, которые, как правило, обнаруживают пользователи уже после выпуска продукта. В итоге команда серьезно замедляется, потому что тратит основное время на исправление этих ошибок, поддержание плохого кода, а не на создание новых объектов.

Описывая Scrum и XP, мы уже говорили о том, насколько быстро может производиться лучшее программное обеспечение теми командами, которые уделяют достаточно времени выполнению работы (через ограниченные временные итерации), проявляют способность сосредоточиться на одной задаче и создают атмосферу, в которой члены команды помогают друг другу преодолевать препятствия. Разумеется, Agile не уживается с магическим мышлением или героями-разработчиками.

Так как же избежать магического мышления?

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

Ликвидируйте потери