Гибкий 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 и руководству. В них сообщается о том, что она выполнила за этот спринт и что планирует выполнить в течение следующего спринта. Члены команды записывают видео на три-пять минут, которое заменяет присутствие на демо.

Следить за техническим долгом

«Раньше, — рассказывает Бьи?орк, — написав код, команда устраивала вечеринку и отмечала успех — как потом выяснялось, преждевременныи?: в реальности они тонули в багах, которые после праздника приходилось искать и исправлять. Таким образом, до поставки ПО команду по-прежнему отделяли многие месяцы. Это был кошмар».

«Сегодня предельное количество багов установлено официально, — продолжает Бьи?орк. — Это ограничение рассчитывается как количество разработчиков в команде, умноженное на четыре. То есть у 10 разработчиков ограничение составляет 40. Достигнув лимита, команда прекращает работать над новыми функциями и следующим спринтом и занимается устранением багов. Таким образом мы можем поставлять продукт бесперебои?но».

Внедрить DEVOPS и постоянную поставку

При методе DevOps разработка и эксплуатация объединяются. Команды занимаются планированием, выполнением, поставкои? и рабочими процессами для каждои? новои? функции.

«Если сервис перестает работать, — объясняет Бьи?орк, — команда должна сделать остановку и решить проблему. Многие привыкли, что этим занимается отдельная служба поддержки. Но кому приятно тратить свое время на исправление чужих ошибок? Сквозная ответственность за качество улучшает результат. Команды управляют жизненным циклом каждои? функции. Если сервис часто выходит из строя, значит, возникла проблема с качеством кода. Необходимость остановки мотивирует людеи? писать отличныи? код. Между тем винить в проблемах некого: команды сами являются владельцами созданных функции?. Сотрудники поэтапно выполняют работу и решают проблемы по мере их появления».

«Постановка новых сроков кардинально изменила ситуацию. Теперь работу нужно выполнять за три недели, — продолжает Бьи?орк. — Три недели — это нормально. Раньше у сотрудников было лишь две возможности. Тем, кто их упускал, приходилось ждать два года. Теперь все происходит иначе. Если инкремент недостаточного качества, то вы его не выпускаете. Команда разочаровывается и обсуждает проблемы на ретроспективе. Сделала ли она что-то неправильно? Или недостаточно оценила уровень сложности? Или что-то упустила? Лучше провести конструктивныи? разговор, чем устраивать тревогу, наказывать команду за то, что она не выполнила обещанное или, что еще хуже, выпустила некачественныи? продукт. Раньше на виновника багов указывали пальцем. Теперь команда сама обнаруживает их, исправляет и забывает о них. Срок корректировки багов сократился»…

Постоянно отслеживать прогресс

Команды постоянно отслеживают, как функции используются в данныи? момент. Результаты отражаются в бэклогах, которые называются сценариями. Каждыи? месяц программныи? менеджер готовит отчет, оценивая различные метрики и аспекты сервиса. Группа учится использовать данные отчета, но не ставит их во главу угла, а ориентируется на общую картину, задеи?ствуя мозги и интуицию сотрудников. Однако это не означает, что данные отходят на второи? план — они зачастую являются пред метом обсуждения.

Само определение «готовности» подразумевает корректные данные измерении?. Команды отслеживают их как при тестировании, так и после релиза. Это один из критериев приемки при поставке кода.

Сразу после поставки команда интересуется использованием функциональности. Затягивает ли она посетителеи? в нашу воронку конверсии? Переходят ли они в разряд постоянных клиентов или остаются обычными пользователями? Полученные данные помогают компании в дальнеи?шем развитии.

Прислушиваться к желаниям пользователей, но удовлетворять их потребности

Программные менеджеры изучают своих пользователеи? всевозможными способами. На самом высоком уровне, в исполнительном брифинг-центре в Microsoft, где разрабатывается стратегия, проводятся так называемые советы потребителеи?. Кроме того, менеджеры группы проектов постоянно общаются с последними в Twitter.

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

Справляться с поручениями сверху

Никто из руководства ни разу не предлагал Бьи?орку отказаться от Agile-управления. Одна из причин — огромныи? успех, которыи? сопутствует Agile-командам.

«Конечно, мы следим за их деятельностью и, если есть необходимость, перераспределяем нагрузку, — признается Бьи?орк. — Если команда отстает, мы не разбиваем ее, чтобы устранить проблему, а просим самих членов команды принять решение. Мы стараемся сохранять состав команды в течение 12–18 месяцев. Наша цель — дать людям возможность преуспеть в совместнои? разработке ПО. Если менять состав команд или задачи каждые три спринта, им будет сложно добиться хороших результатов. Компания вкладывается в команду как минимум на девять месяцев или год».

Использовать самоформирующиеся команды, чтобы вдохновить людей на коллективную ответственность

Менеджеры позволяют сотрудникам периодически выбирать команду для работы3. Примерно две трети предпочитают оставаться на нынешнем месте, поэтому новые команды возникают редко (скорее для работников важна сама возможность выбора). В результате компания делает серьезные инвестиции в постоянные команды, которые повышают и их благосостояние, и эффективность.

Команда владеет бэклогом своих задач. «Разумеется, — говорит Бьи?орк, — мы часто обсуждаем приоритеты. Но менеджер не указывает команде, что следует делать. В свою очередь, команда тоже не диктует свои правила менеджеру. Они находятся в постоянном диалоге: „Эи?, нужно ли нам делать это? Как ты думаешь, мы уже достаточно вложили сюда? Должны ли мы пересмотреть все здесь?». Будучи программным менеджером, я точно так же общаюсь со своеи? командои?. Такое общение требует огромного взаимного доверия. Как менеджер вы не можете заниматься всем и знать все. Происходит обмен мнениями».

Признать, что команда — это продукт

В сфере разработки ПО жизненныи? цикл продукта сокращается. «В традиционном бухгалтерском учете, — говорит Бьи?орк, — продукт является производственным активом. На практике же активом все чаще и чаще является команда, способная поставлять программные продукты. Раньше команда создавала ценность дольше, чем компания. Теперь приоритеты изменились».

«Microsoft обладает преимуществом. Она создала команды задолго до того, как приняла Agile, — продолжает он. — В неи? уже деи?ствовала устои?чивая командная культура. Организациям гораздо сложнее стать гибкими, если они никогда не создавали команд».

Microsoft инвестирует в своих сотрудников — в противоположность компаниям, которые считают своих работников «сменным ресурсом».

Создавать качество с самого начала

В процессе Agile-трансформации сотрудникам Microsoft приходилось многому учиться. «В самом начале, — рассказывает Бьи?орк, — мы решили проводить трехнедельные спринты. Руководство одобрило идею Agile, но беспокоилось о том, будет ли все работать. В итоге было запланировано после пяти спринтов провести „стабилизирующии? спринт». Узнав об этом, некоторые махнули рукои?: „Нет причин волноваться о багах, потому что у нас будет стабилизирующии? спринт!». В результате появилось так много багов, что командам пришлось помогать друг другу исправлять их».

«На самом деле, — продолжает Бьи?орк, — мы призывали людеи? делать одно, но создали среду, которая побуждала некоторых делать противоположное. Их нельзя было винить в этом. После истории со „стабилизирующим спринтом» сотрудники просили нас: „Никогда так больше не делаи?те!». Это было примером непреднамеренных последствии?».

Главная цель — избежать нежелательнои? последовательности: писать код в течение первого спринта, тестировать — в течение второго, исправлять баги — в течение третьего. «Дорожные правила» предписывают: поставлять готовыи? продукт после каждого спринта.

Такова концепция автономности. Если команды не контролируют качество собственнои? работы, не стоит удивляться негативным последствиям — например, авралам по выходным. Команды сами планируют свои? график и могут не подчиняться процессам, которые не в силах контролировать.

Использовать коучинг с осторожностью

В самом начале компания проводила коучинг и базовое обучение Scrum. Но вскоре группа просто начала учиться самостоятельно. В процессе работы люди выявляли наиболее эффективные практики и применяли их чаще, отказываясь от неэффективных. В итоге некоторые сотрудники и менеджеры Microsoft фактически сами стали аgile- или scrum-коучами. Но в целом группа просто поставила перед собои? цель и с энтузиазмом взялась за дело.

Позже выяснилось, что многие новички не проходили базового обучения, поэтому было решено проводить его. К этому моменту стало понятно, что стандартнои? образовательнои? программы нет и то, что работает в других компаниях, может не подои?ти культуре Microsoft.

Обеспечивать первоклассную поддержку

Изначально высшее руководство Microsoft с опаскои? относилось к Аgile. Но вскоре его отношение изменилось. «Теперь топ-менеджмент признает Agile современным способом разработки ПО, — радуется Бьи?орк. — На уровне команды внедрять его несложно. Вы берете десять человек, проводите обучение и приступаете к делу. Но как синхронизировать деятельность четырех тысяч сотрудников? Это вопрос».

Непростую задачу удалось реализовать при поддержке корпоративного вице-президента Браи?ана Харри. Преимущество Бьи?орка заключалась в том, что до перехода на нынешнюю должность он трудился в подразделении разработки, в котором практики Scrum и Agile закрепились с давних времен. «Наши клиенты писали нам свои пользовательские истории еще до того, как мы узнали, что это такое, — говорит Бьи?орк. — Мы уже семь лет как применяем Agile. Компания не осуществляла все перемены одномоментно. Дольше всего менялось физическое пространство. Если бы все команды сразу собрались вместе, объединили бы свои направления и попытались работать в трехнедельных спринтах, ничего бы не получилось. Agile нужно развивать. Вы не можете внедрить его за один день».