Текст книги "Искусство Agile-разработки. Теория и практика гибкой разработки ПО"

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

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

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

В результате, хотя в идеале каждая команда владела бы долей продукта, вам почти всегда придется вводить в работу и менее идеальные типы команд. В книге Team Topologies [Skelton2019] они разделены на четыре категории.

• Поточно-ориентированные команды. Это идеальный вариант. Они сфокусированы на определенном продукте, его доле, обращенной к заказчику или группе заказчиков.

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

 Вспомогательные или помогающие команды. Фокусируются на предоставлении специализированных экспертных знаний другим командам, например UX, эксплуатации или безопасности. Вместо того чтобы выполнять работу за другие команды, что сделало бы их узким местом, они помогают командам учиться делать эту работу самостоятельно. Иногда это подразумевает предоставление ресурсов, помогающих в решении комплексных проблем, например чек-листов по безопасности или рекомендаций по UX-дизайну.

• Команды платформ. Похожи на вспомогательные команды, за исключением того, что предлагают скорее инструментарий, чем прямую помощь. Равно как и вспомогательные команды, не решают проблемы за другие команды; вместо этого их инструменты помогают командам самостоятельно справляться со своими проблемами. Например, команды платформ могут предоставлять инструментарий для развертывания программного обеспечения.

Секрет успеха горизонтального планирования – в правильном распределении ответственности среди команд. Чем меньше перекрестных зависимостей между командами, тем лучше. Это фундаментальный вопрос архитектуры, поскольку зоны ответственности ваших команд должны имитировать желаемую системную архитектуру. (Это также называется обратным маневром Конвея (Inverse Conway Maneuver).)

Горизонтальное масштабирование работает наилучшим образом, когда у вас всего несколько команд. Когда их количество невелико, легко понять, как все они сочетаются друг с другом, и координировать их работу. Если есть проблема, то представители команд могут собраться вместе и все урегулировать.

Такой принцип координации по необходимости (ad-hoc coordination) перестает работать при наличии примерно 5–10 команд. Начинают формироваться узкие места, одни команды почти останавливают работу, а другие оказываются перегружены ею. Чтобы сохранять команды как можно более независимыми друг от друга, вам нужно уделять особое внимание их структуре. Каждая команда, особенно те, которые не относятся к типу поточно-ориентированных команд, должна рассматривать автономию тех, кто от нее зависит, как свой высочайший приоритет. А продакт-менеджеры должны тщательно координировать действия всех участников, обеспечивая общую согласованность работы.

Когда вы достигаете уровня 30–100 команд, даже этот подход начинает сбоить. Чаще происходят различные изменения, и зоны ответственности команд нужно корректировать, чтобы не отставать от изменений в бизнес-приоритетах. Вам уже требуется многоуровневая система координации и управления. Люди перестают понимать, как работает система в целом.

Хотя горизонтальное масштабирование может продолжаться до бесконечности, на практике по мере роста количества команд управлять им становится все труднее. Вертикальное масштабирование является более гибким, но не может масштабироваться до такой степени. К счастью, можно получать преимущества обоих вариантов, комбинируя два подхода.

Я работал со стартапом, в котором участниками команд стали 300 человек и который застопорился на этом. (Вся организация насчитывала более 1000 человек, а в командах разработки продукта состояло около 300 человек.) Все команды работали над разными аспектами одного и того же продукта, и кросс-командные зависимости просто блокировали их деятельность.

Я подошел к задаче со стороны горизонтального масштабирования и помог им реструктурировать зоны ответственности команд так, чтобы минимизировать зависимости и максимизировать изоляцию. В итоге они достигли уровня 40 команд (почти то же, что и раньше), но были гораздо более независимыми. Это разблокировало их попытки развития, и они продолжили рост. Они выросли до 80 команд, прежде чем столкнулись с новым препятствием.

Все были довольны результатом. Однако если бы я мог сделать это еще раз, то внедрил бы и вертикальное масштабирование. Вместо 40 команд они могли бы сформировать шесть групп по 50 человек в каждой. Координировать шесть вертикально масштабированных групп значительно легче, чем 40 маленьких команд, и у них не было бы проблем при дальнейшем масштабировании. Даже когда они бы начали сталкиваться с проблемами координации, техники горизонтального масштабирования помогли бы им вырасти на порядок.

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

Отчасти причина того, что в работе начались сбои, когда этот стартап разросся до 80 команд, – в том, что организация не поддерживала в актуальном состоянии зоны ответственности команд. Мы спроектировали механизм пересмотра и обновления обязанностей команд (это была работа команды архитекторов), но, как это часто случается, о нем забыли на фоне выполнения других обязанностей. А вертикально масштабированные группы не нуждаются в таком же объеме сопровождения. Они могут намного легче адаптироваться к меняющимся условиям бизнеса.

Другими словами, вы можете комбинировать вертикальное и горизонтальное масштабирование, представляя себе свои вертикально масштабированные группы как одну «команду» с точки зрения горизонтального масштабирования. При этом почти каждая может быть поточно-ориентированной, возможно, за исключением группы, занятой вашей операционной платформой.

Резюмируем: как вам масштабировать вашу Agile-организацию?

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

Делайте вертикальное масштабирование прежде, чем горизонтальное. В большинстве случаев лучшим выбором является LeSS. Если у вас есть опыт и вы хотите экспериментировать, то попробуйте FAST.

Если вы достигли пределов вертикального масштабирования (вероятно, около 60–70 человек, хотя FAST, возможно, способен и на дальнейшее масштабирование), то разделитесь на множество вертикально масштабированных групп. Каждая должна быть поточно-ориентированной. Вам вряд ли понадобится команда сложных подсистем или вспомогательная команда, поскольку ваши группы будут достаточно велики, чтобы иметь все необходимые знания. В некоторых случаях вы можете захотеть сформировать отдельную группу платформ, чтобы заботиться об общей инфраструктуре – обычно о платформе эксплуатации или развертывания.

Если вы используете LeSS, то LeSS Huge описывает этот тип разделения при горизонтальном масштабировании, хотя и с небольшими различиями. Он сохраняет присущий LeSS акцент на коллективном владении кодом, даже двумя группами (которые LeSS называет «областями»). Однако в действительности группы склоняются к специализации.

Но помните: успех масштабирования зависит от свободного владения навыками команд. Этому посвящена вся оставшаяся часть книги. Мы начнем со свободного владения навыками на уровне фокусировки.

Несколько слов о SAFe

SAFe (Scaled Agile Framework), масштабированный гибкий фреймворк, представляет собой популярный подход к Agile-масштабированию. К сожалению, я пока еще не видел его хорошо работающим. Как правило, компании принимают его с большой помпой, но через несколько лет тихо избавляются от него.

Я не знаю точно, почему это так. Критики SAFe заявляют, что это не совсем Agile и что ему свойствен характерный оттенок преобладания «процессов над людьми» и «предиктивности над адаптивностью».

Я подозреваю, что настоящих причин неудач SAFe две. Во-первых, SAFe подчеркивает, что «он дружествен для предприятий», что в организациях, которые я видел, приводит к недостаточным инвестициям в идеи Agile. Организации склонны придерживаться привычного предиктивного мышления в стиле управления сверху вниз и «командуй-и-контролируй».

Во-вторых, SAFe мало что предлагает для координации команд – самой сложной и критически важной проблемы масштабирования. До SAFe 5 он предлагал делить команды по функциональностям (то же, что и LeSS), но это было крайне невыгодно и не включало элементы, с помощью которых LeSS обеспечивает работу команд[26]26
  См. https://www.scaledagileframework.com/features-and-components по состоянию на 30 июня 2021 года.


[Закрыть]. SAFe 5, появившийся в феврале 2021 года, заменил функциональные команды дискуссией о топологиях команд, которая хотя бы содержит больше деталей. Но это подход горизонтального масштабирования, что является шагом назад. Он требует обращать пристальное внимание на структуру обязанностей команд, которую SAFe опять-таки даже не упоминает, не говоря о том, чтобы помочь с этим разобраться.

Небольшим вкладом SAFe в координацию команд может считаться сессия планирования инкремента программы (Program Increment (PI) Planning) каждые несколько месяцев, также известная как «планирование в большой комнате». Эта сессия предиктивная, не адаптивная; чрезвычайно трудоемкая и изнурительная; плохо работающая с удаленными командами. Хотя некоторые команды и ценят ее за возможность привести команды к общему пониманию, по моему опыту, это первое, от чего избавляются компании. К сожалению, в SAFe больше нет ничего особенного, и как только из него исчезает PI Planning, вы остаетесь с группой команд и ограниченными возможностями их координации.

В общем и целом SAFe на словах поддерживает идеи Agile, однако не понимает их по-настоящему. Я его не рекомендую.

II
Фокус на ценность

Вы приходите на работу прохладным октябрьским утром. Ваша предыдущая команда работала полностью удаленно, но нынешняя предпочитает работать в офисе. Стили общения – абсолютно разные, размышляете вы, но Agile – тот же самый.

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

Некоторые выступают с идеей, чтобы ваша команда взяла на себя полную ответственность как команда оптимизации, но в данный момент ваши приоритеты определяет Ханна, продакт-менеджер из отдела маркетинга. Она очень занята, и ее босс не хочет назначать ее в вашу команду на полный рабочий день.

Кстати, о направлении развития продукта. Сегодня демодень. Каждую неделю ваша команда выпускает новую версию своего ПО, затем составляет план на следующую неделю разработки. Раз в месяц вы встречаетесь с вашими основными стейкхолдерами, показываете, что сделали, и получаете от них обратную связь. Раньше вы делали это чаще, но представителей стейкхолдеров нельзя беспокоить слишком частыми встречами. Так что ваши демо стали реже и короче, и обычно все участники встреч предвкушают что-то новое. Когда нужна более быстрая обратная связь, вы проводите частные демонстрации для отдельных заинтересованных лиц.

Как обычно, демо ведет Ханна. Сначала она хотела, чтобы его вели члены команды, но вы обнаружили, что Ханна уделяет больше внимания тому, что вы создаете, если сама отвечает за демо. Это улучшает результаты и обратную связь от заказчиков. Вдобавок она лучше умеет находить общий язык со стейкхолдерами.

Стейкхолдеры, кажется, довольны вашим прогрессом за этот месяц. Большой интерес вызвала функциональность для немарочного продукта (whitelabel), над которой вы сейчас работаете, и, как обычно, поступило несколько предложений. Ханна принимает их к сведению.

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

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

У вашей команды перерыв после ретроспективы, затем Ханна начинает еженедельную сессию планирования. Она достает доску для визуального планирования. Это большая белая доска с пачкой индексных карточек, прилепленных к ней магнитами. Карточки образуют кластеры, и у каждого из них есть название, например, «реселлеры», «актуарии», «бухгалтеры». Кластеры представляют собой группы ваших заказчиков. Есть и другая большая группа карточек, помеченная словом whitelabel.

«У нас были хорошие идеи во время демо, – говорит Ханна, – но я хочу, чтобы мы продолжили фокусироваться на функциональности для немарочного продукта для реселлеров». Все кивают. Вы работаете над этим уже несколько недель, так что это для вас не является сюрпризом. «Мы близки к завершению самой сути немарочного продукта, поэтому следующий этап – экраны администратора. Перед этим я хотела бы организовать пробный прогон с одним из наших главных реселлеров. Я пришлю подробную информацию по электронной почте».

Ханна делает знак Колтону, UX-дизайнеру команды, и он вступает в разговор. «Мы с Ханной собираемся заняться пробным прогоном и администрированием whitelabel чуть позже сегодня. Приглашаем всех поучаствовать. После этого я хотел бы составить карту историй и провести игру в планирование, чтобы конкретизировать истории. Это не должно быть слишком сложным. Я сообщу вам, когда мы это запланируем».

Ханна берет несколько голубых карточек с историями из раздела доски, подписанного whitelabel. «У нас еще достаточно историй на эту неделю. Наш потенциал все еще составляет 12 пойнтов (point), верно?» Все кивают. «Отлично. Вот 3… 6… 8, 11, 12. Это должно приблизить нас к пробному прогону с реальными заказчиками». Она поднимает первую карточку, на которой написано «цветовая схема whitelabel». «Окей, для этого нам нужна возможность изменить цветовую схему сайта, чтобы она соответствовала фирменным цветам каждого реселлера». Вдобавок Ханна кратко поясняет содержимое остальных карточек. Ей задают несколько уточняющих вопросов, но вообще-то вы все уже видели это раньше, поэтому процесс идет быстро.

«Вот такой план! – заканчивает Ханна. – Колтон сможет ответить на любые вопросы, касающиеся деталей. Сейчас мне нужно заняться электронными письмами, но я буду здесь, – она показывает на угол, – до тех пор, пока вы не закончите планирование. Дайте знать, если от меня понадобятся какие-либо пояснения».

Ханна садится, и Шайна берет инициативу в свои руки. Некоторое время назад вы решили (это был другой эксперимент с ретроспективами), что тот, кто ведет ретроспективу, будет фасилитировать все собрания команды в течение недели. Вы не слышали, чтобы какие-либо другие команды работали подобным образом, но наличие заранее назначенного фасилитатора помогает вам придерживаться выбранного направления, тем более сейчас, когда ваш коуч перешел в другую команду.

Шайна переворачивает планировочную доску. На обратной стороне ваш план на неделю. «Окей, вы знаете упражнение, – говорит она, указывая на пять карточек с историями, выбранными Ханной. – Разложите их, и начнем мозговой штурм. Нужно выписать задачи на желтые карточки. Я приготовлю доску».

Члены команды собираются вокруг стола и начинают записывать задачи на желтых карточках. В процессе этого они высказывают свои соображения, что, в свою очередь, вдохновляет всех на дополнительные идеи. «Обновить схему DB так, чтобы она содержала цветовую схему». «Вынести переменные CSS». «Сделать для каждого реселлера отдельный файл CSS». «Добавить CSS-файл реселлера к шаблону верхнего уровня». Вскоре появляется упорядоченная сеть карточек, показывающая все, что команде нужно сделать за эту неделю. Шайна помогает перенести все на белую доску. Вы слышали, что другие команды визуализируют свои планы по-другому, но вам нравится именно этот подход.

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

«Думаю, на этом все», – говорит Шайна. Стендап занял всего несколько минут, а вся сессия планирования продолжалась менее часа. Учитывая ретроспективу и демо, время приближается к полудню. «Кто на обед?»

Добро пожаловать на уровень фокусировки

Свободное владение навыками на уровне фокусировки – для тех команд, которые хотят сконцентрироваться на том, что их компания ценит больше всего. Они тесно сотрудничают со своими бизнес-партнерами, чтобы понимать приоритеты, обеспечивать наглядность и реагировать на обратную связь. В частности, команды, которые свободно владеют навыками на уровне фокусировки[27]27
  Эти списки взяты из [Shore2018b].


[Закрыть]:

• планируют свою работу с точки зрения бизнес-ценности, а не технических задач и согласовывают работу с бизнес-приоритетами компании;

• демонстрируют прогресс по меньшей мере ежемесячно и делают это с точки зрения бизнес-ценности, а не технических задач;

• меняют свое направление, чтобы следовать за изменениями в приоритетах бизнеса;

• обеспечивают наглядность своего прогресса, чтобы руководство могло вмешаться, когда команда создает не то, что нужно, или в ее работе отсутствует прогресс;

• регулярно улучшают свои рабочие привычки, снижая затраты и повышая эффективность;

• поддерживают сотрудничество внутри команды, уменьшая недопонимание и задержки в процессах внутри команды.

Чтобы добиться всех этих преимуществ, командам необходимо развить соответствующие навыки. Это требует инвестиций, описанных в главе 4.

Команда отвечает на потребности бизнеса:

• работает с представителем бизнеса, который обеспечивает ее организационными перспективами и ожиданиями;

• стейкхолдеры от бизнеса могут быть уверены, что команда будет работать над тем, что ее бизнес-представитель называет своим самым важным приоритетом;

• команда планирует свою работу и демонстрирует прогресс поэтапно, чтобы ее бизнес-представитель мог его понять и оценить;

• бизнес-представитель команды видит и может изменить направление работы команды по меньшей мере раз в месяц;

• руководство дает полномочия команде работать в темпе, позволяющем ей реагировать на потребности бизнеса сколь угодно долго.

Команда эффективно работает как команда:

• составляет свои ежедневные задачи и план, основываясь на приоритетах ее бизнес-представителя;

• участники считают план командной работой, а не индивидуальной;

• члены команды разделяют ответственность за выполнение плана;

• руководство считает план командной работой, а не назначает ответственными отдельных исполнителей.

Команда стремится к командным достижениям:

• принимает и постоянно улучшает общий подход к своей работе;

• понимает, как внутрикомандные отношения влияют на ее способность достигать успеха, и своевременно пытается их улучшить;

• понимает, как рабочая атмосфера влияет на способность команды выполнять работу, и своевременно пытается ее улучшить.

Достижение свободного владения навыками на уровне фокусировки

Главы этой части помогут вашей команде достичь свободного владения навыками на уровне фокусировки. Здесь содержатся практики, которые научат вас работать как команда, планировать ценные релизы, управлять своей работой и нести за нее ответственность, а также неуклонно совершенствоваться.

• В главе 7 рассматривается эффективная работа в команде.

• В главе 8 описывается, как планировать и приоритизировать работу в соответствии с бизнес-ценностью.

• В главе 9 рассказывается о том, как взять на себя ответственность за повседневный процесс и планы.

• В главе 10 описывается, как обеспечить наглядность рабочего процесса и завоевать доверие стейкхолдеров.

• В главе 11 представлена информация о том, как улучшать рабочие привычки, отношения и атмосферу в команде.