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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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