Стивен Деннинг - Эпоха Agile

«Моя задача, – объясняет он, – выслушивать потребителей и следить за тем, чтобы мы создавали востребованный ими продукт, который они будут покупать. Также моя обязанность – проводить различие между желаниями и потребностями и при необходимости извиняться за то, что мы не в состоянии сделать».

Трансформация Microsoft заняла изрядный период времени. Со своей предыдущей командой Аарон начал экспериментировать с Agile и Scrum в 2008 году. Примерно через год Scrum внедрили еще несколько команд, и в различных частях Microsoft возникли новые центры Agile. В 2010 году решение «стать гибкой» приняла группа Team Foundation Server. Все ее команды применяли практики и роли Scrum и работали трехнедельными спринтами в едином темпе. Благодаря этим успехам в июле 2011 года Брайан Харри публично объявил в своем блоге о приверженности Agile и Scrum в группе Visual Studio. Позже в том же году «стать гибким» решило все подразделение разработки.

В июле 2015 года, когда мы впервые посетили Microsoft, группа Visual Studio Team Services вошла в первую неделю 87-го спринта. В мае 2016 года мы попали на вторую неделю 101-го спринта. Трехнедельные спринты продолжаются в стабильном ритме, несмотря на праздники и преобразования в компании. (Правда, на время праздников спринт «облегчается».) Командам нравится этот ритм и упорядоченность, которую он дает.

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

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

«Изначально было очень тяжело. Прошло много времени, прежде чем мы cумели успешно завершить трехнедельный спринт, – продолжает Бьйорк. – В реальности мы работали не спринтами, а этапами. По его завершении команда заявляла о готовности новой функции и устраивала праздник. Затем я пробовал эту функцию, и она не работала. Команда сокрушалась: “Ой, мы не провели настройку и не апгрейдили продукт под нее”. Я уточнял: “Но вы же сказали, что все сделали!”. Команда отвечала: “Ну да, мы все сделали. Мы просто не провели настройку и апгрейд”. Лишь со временем люди поняли, что следует полностью выполнять работу в течение каждого спринта. На осознание этого ушел год».

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

Ниже представлены ключевые аспекты, которые, по мнению Бьйорка, необходимы для внедрения Agile в глобальном масштабе.

Цель Microsoft – обеспечить согласованность наверху и автономность внизу. «Последняя очень нужна командам, – настаивает Бьйорк. – Именно она окрыляет их и наделяет желанием создавать б о льшую ценность для клиентов. Но в то же время их работа должна быть согласована с руководством. Излишний контроль мало кому приятен, однако его недостаток ведет к хаосу. Представьте себе: каждый делает что хочет; нет никаких общих сценариев; клиенты разочарованы; работа теряет смысл. Менеджеры всегда стремятся найти баланс».

Руководство устанавливает правила. К ним относятся разъяснение ролей команд, ритма, терминология и допустимое количество ошибок и недочетов, то есть багов.

Команда автономна в вопросах планирования и выполнения своей работы и может применять разный подход в общих рамках. Она сама выбирает конкретные практики разработки – например, самостоятельно решает, применять ли парное программирование (для сравнения: в Menlo Innovations, о которой мы говорили в главе 2, программирование в парах обязательно).

«Роль руководства похожа на определение правил дорожного движения, – разъясняет Бьйорк. – Фактически трасса помогает вам ехать быстро и вы можете гнать по ней с бешеной скоростью. Но есть определенные правила. Вы должны включать поворотник, когда пересекаете полосу, и в определенные моменты сбавлять скорость. Ответственные лица могут сделать трассу гораздо безопаснее, установив дополнительных “лежачих полицейских” и светофоры через каждые полтора километра. Но тогда движение на трассе замедлится. В Microsoft мы применяем тот же подход. Мы определяем для команд минимальные правила дорожного движения. При этом мы должны быть уверены в том, что они помогают командам быстрее двигаться и достигать желаемой цели, а не замедляют темп».

Конечно, когда Бьйорк спрашивает команду разработчиков «Какие указания руководства затрудняют ваше движение?», на него обрушивается целый град жалоб. «Они предъявляют массу претензий! Они ждут этого момента! Они пользуются случаем высказать все, что я делаю не так. И мы обсуждаем все, что у них накипело. Самое главное – разговор происходит, и это разговор без отрицательных последствий для кого-либо».

Что происходит, когда команде не удается выполнить все необходимое за один спринт, притом что никакой менеджер не отслеживает ход выполнения задач? «Командам необходим график сгорания задач, – говорит Бьйорк. – Но знаете, что происходит, когда они отстают? Мы обсуждаем то, что нужно сделать, и все равно добиваемся результата, поскольку именно такое поведение предписывает наша корпоративная культура. Что я выиграю, если буду кричать на людей или следить за графиком сгорания задач? Я должен решить, что мне важнее – идеальный график сгорания или откровенный разговор? В конечном счете нужно выбирать второе».

В этом и заключается различие между мышлением и практиками. Важно, чтобы люди понимали, почему они следуют практикам и несут ответственность за созданную ими ценность. Если ежедневные стендапы не работают, не прячьте голову в песок – сделайте что-нибудь! Именно здесь возникает автономность. Как говорит Бьйорк: «Ты контролируешь ситуацию! Ты отвечаешь за все!».

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