Гибкий 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 нужно развивать. Вы не можете внедрить его за один день».