Гибкий Microsoft: как знаменитая корпорация использует Agile
От редакции. Мы публикуем фрагменты из книги Стивена Деннинга «Эпоха Agile. Как умные компании меняются и достигают результатов», русский перевод которой выходит этой весной в издательстве «Манн, Иванов и Фербер».
Не так давно Брайан Харри, корпоративный вице-президент Microsoft, увидел в своем блоге неожиданный комментарий. «Вполне очевидно, — писал читатель с ником Kasper, — что последние полгода вы применяли Agile-инструменты… Интересно, как долго вы будете уделять внимание этой области?»
Кого-то удивит тот факт, что Microsoft в принципе следует Agile. В 2016 году прибыль этой гигантской корпорации составила $850 млрд, а число сотрудников — 114 тысяч человек. Во всем мире к Microsoft относятся как к огромному линкору, сильному и мощному, но тяжелому в маневрировании и не всегда удобному для пользователей.
Именно этот образ пришел мне в голову, когда Аарон Бьйорк, менеджер группы проектов в подразделении разработки Microsoft, связался со мной и предложил поделиться историей об Agile-трансформации Microsoft…
Подразделение разработки включает в себя около четырех тысяч человек. Всего в нем сотни команд, каждая из которых состоит из 10–12 членов. Команды работают в трехнедельных спринтах. Бьйорк руководит группой Visual Studio Team Services. Эта группа включает в себя 40 команд и в общей сложности около 500 сотрудников. Сам Бьйорк отвечает за деятельность семи команд.
Подразделение разработки создает ряд продуктов и услуг, среди которых Visual Studio, Visual Studio Team Services, Team Foundation Server и TypeScript. Подразделение разработки стоит во главе движения за достижение компанией большей гибкости… Другие группы Microsoft, например Windows, Office и Bing, отделены друг от друга, но все находятся на разных стадиях Agile-трансформации. Руководители ежемесячно оценивают, как крупные подразделения внедряют новые процессы.
Мы провели несколько рабочих выездов и обнаружили, что теперь Microsoft похожа не на гигантский линкор, а на флотилию скоростных катеров, которым удается синхронно маневрировать…
Трансформация 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 — планирование спринтов, бэклоги, ежедневные стендапы, ретроспективы — лишь часть задачи. Самое главным — и сложным — оказалось изменение мышления всех участников.
Это бесконечный путь. «Трансформация, — говорит Бьйорк, — не похожа ни на сплошной кошмар, ни на историю триумфа. В ней есть взлеты и падения. Одни вещи мы делаем хорошо, другие плохо. Есть области, которые мы усовершенствовали».
«Изначально было очень тяжело. Прошло много времени, прежде чем мы сумели успешно завершить трехнедельный спринт, — продолжает Бьйорк. — В реальности мы работали не спринтами, а этапами. По его завершении команда заявляла о готовности новой функции и устраивала праздник. Затем я пробовал эту функцию, и она не работала. Команда сокрушалась: „Ой, мы не провели настройку и не апгрейдили продукт под нее». Я уточнял: „Но вы же сказали, что все сделали!». Команда отвечала: „Ну да, мы все сделали. Мы просто не провели настройку и апгрейд». Лишь со временем люди поняли, что следует полностью выполнять работу в течение каждого спринта. На осознание этого ушел год»…
Ниже представлены ключевые аспекты, которые, по мнению Бьйорка, необходимы для внедрения Agile в глобальном масштабе.
Найти баланс между согласованностью и автономностью
Цель Microsoft — обеспечить согласованность наверху и автономность внизу. «Последняя очень нужна командам, — настаивает Бьйорк. — Именно она окрыляет их и наделяет желанием создавать большую ценность для клиентов. Но в то же время их работа должна быть согласована с руководством. Излишний контроль мало кому приятен, однако его недостаток ведет к хаосу. Представьте себе: каждый делает что хочет; нет никаких общих сценариев; клиенты разочарованы; работа теряет смысл. Менеджеры всегда стремятся найти баланс».
Руководство устанавливает правила. К ним относятся разъяснение ролей команд, ритма, терминология и допустимое количество ошибок и недочетов, то есть багов.
Команда автономна в вопросах планирования и выполнения своей работы и может применять разный подход в общих рамках. Она сама выбирает конкретные практики разработки — например, самостоятельно решает, применять ли парное программирование…
«Роль руководства похожа на определение правил дорожного движения, — разъясняет Бьйорк. — Фактически трасса помогает вам ехать быстро и вы можете гнать по ней с бешеной скоростью. Но есть определенные правила. Вы должны включать поворотник, когда пересекаете полосу, и в определенные моменты сбавлять скорость. Ответственные лица могут сделать трассу гораздо безопаснее, установив дополнительных „лежачих полицейских» и светофоры через каждые полтора километра. Но тогда движение на трассе замедлится. В Microsoft мы применяем тот же подход. Мы определяем для команд минимальные правила дорожного движения. При этом мы должны быть уверены в том, что они помогают командам быстрее двигаться и достигать желаемой цели, а не замедляют темп».
Конечно, когда Бьйорк спрашивает команду разработчиков «Какие указания руководства затрудняют ваше движение?», на него обрушивается целый град жалоб. «Они предъявляют массу претензий! Они ждут этого момента! Они пользуются случаем высказать все, что я делаю не так. И мы обсуждаем все, что у них накипело. Самое главное — разговор происходит, и это разговор без отрицательных последствий для кого-либо».
Освоить роль Agile-менеджера
Что происходит, когда команде не удается выполнить все необходимое за один спринт, притом что никакой менеджер не отслеживает ход выполнения задач? «Командам необходим график сгорания задач, — говорит Бьйорк. — Но знаете, что происходит, когда они отстают? Мы обсуждаем то, что нужно сделать, и все равно добиваемся результата, поскольку именно такое поведение предписывает наша корпоративная культура. Что я выиграю, если буду кричать на людей или следить за графиком сгорания задач? Я должен решить, что мне важнее — идеальный график сгорания или откровенный разговор? В конечном счете нужно выбирать второе».
В этом и заключается различие между мышлением и практиками. Важно, чтобы люди понимали, почему они следуют практикам и несут ответственность за созданную ими ценность. Если ежедневные стендапы не работают, не прячьте голову в песок — сделайте что-нибудь! Именно здесь возникает автономность. Как говорит Бьйорк: «Ты контролируешь ситуацию! Ты отвечаешь за все!».
Управлять отношениями на уровне команды
В подразделении разработки Microsoft внутренние отношения регулируются самими командами настолько, насколько это возможно. Каждая знает, чем занимаются остальные. Они в одной упряжке и вместе трудятся над качеством продукта в целом. Если работа одной команды зависит от другой, она не будет ждать следующего совещания, чтобы заявить об этом, — программные менеджеры и менеджеры по разработке сами договариваются между собой.
Разумеется, неожиданности происходят и на совещаниях: «О, так вы уже начали работать над этим? Мы не знали! Надо обсудить нюансы». Задача менеджеров — убедиться в том, что команды встретились, пообщались и разобрались в ситуации.
Ожидается, что в план трех спринтов будут включены все взаимоотношения. Бьйорк работает с семью командами. То же самое происходит в других шести группах. Менеджеры действуют в одном пространстве. Общение происходит постоянно.
Каждые три месяца проходит стендап под названием «Встреча функциональных команд», во время которого каждая делится своими планами. Подопечным Бьйорка отводится 90 минут на выступления, то есть каждая команда должна уложиться в 10–15 минут. В этом мероприятии участвуют все «боевые единицы». Эта регулярная «церемония» предоставляет руководству подразделения разработки возможность вникнуть в текущую ситуацию и подстроиться под нее.
Обеспечить постоянную интеграцию
Когда подразделение только приступило к работе, каждая команда работала в своей ветке кода в течение трехнедельного спринта. В конце спринта полученные результаты объединяли, и возникал хаос. Фактически команды создавали слишком большой интеграционный долг. Эта модель оказалась нежизнеспособной. Для завершения каждого спринта команды должны были осуществить фундаментальные изменения…
Но нельзя работать автономно в течение трех недель в надежде объединить результаты позже — необходимо ежедневное сотрудничество. Допустив нарушения в текущем варианте программы, команда должна моментально его исправлять. Чем дольше команде приходится ждать объединения кода, тем выше риск технической и интеграционной задолженности — и катастрофы.
Команды используют так называемые функциональные флажки. При новой разработке они первым делом изолируют код, который необходимо менять, и делают переключатель к нему. В базе данных он отмечается флажком, что означает изменение конфигурации. Команда пишет новый код за пределами версии, зафиксированной флажком. Предполагая, что работа завершена, она переключает код только для себя. Этот переключатель не глобальный. Он служит своего рода демонстрацией в системе и действует только «для своих». Если все идет хорошо, команда активирует его для конкретных пользователей, чтобы его протестировали и таким образом помогли выявить баги и проблемы. По окончательном завершении задания команда готовит анонс выпуска и объявляет о переходе на новую версию для всех пользователей…
В конце каждого спринта команда рассылает электронные письма всем 500 сотрудникам группы Visual Studio Team Services и руководству. В них сообщается о том, что она выполнила за этот спринт и что планирует выполнить в течение следующего спринта. Члены команды записывают видео на три-пять минут, которое заменяет присутствие на демо.
Следить за техническим долгом
«Раньше, — рассказывает Бьйорк, — написав код, команда устраивала вечеринку и отмечала успех — как потом выяснялось, преждевременный: в реальности они тонули в багах, которые после праздника приходилось искать и исправлять. Таким образом, до поставки ПО команду по-прежнему отделяли многие месяцы. Это был кошмар».