Перевод статьи «Dependency Management in a Large Agile Environment».
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
1 Введение
В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.
Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.
2 Структура команды
Разработка продукта в salesforce.com состоит из трех подразделений: Applications, Platform и Core Infrastructure. Эти три подразделения суммарно содержат более 30 Scrum-команд. В каждой Scrum-команде есть разработчики, тестировщики и Product Owner, а также Scrum Master (обычно это руководитель разработчиков или тестировщиков либо Program Manager). Для сложных фич Scrum-команды также привлекают представителей других функциональных команд, например System Testing, Documentation, UI Design, Usability, Technology Operations, Release Engineering.
Обычно все Scrum-команды работают над одним и тем же релизом в одной и той же ветке кода. Наши продукты связаны между собой, поэтому фичи разных команд могут очень тесно переплетаться — как функционально, так и технически. С точки зрения технической реализации многие команды используют общий код. С точки зрения функциональности команды, работающие над фичами для одного и того же конечного пользователя, должны тесно сотрудничать, чтоб создать гармоничный и согласованный user experience.
3 Почему управлять зависимостями трудно?
Когда столько команд работают над одним релизом, внедряя общие фичи и меняя общий код, невозможно предвидеть все проблемы, неожиданности, изменения, провалы и успехи, которые встретятся в процессе разработки. Такая непредсказуемость — одна из причин, почему управлять зависимостями так трудно. Далее в этом разделе мы отметим еще несколько причин. Любые решения должны быть направлены на эти основополагающие конфликты и вызовы.
3.1 Сложность системы
Выявление зависимостей — первый шаг к управлению ими. Подобно многим зрелым продуктам, системы salesforce.com слишком сложны, чтобы один человек или команда были способны знать и помнить все взаимосвязи. Чтобы выявить и осознать зависимости, нам все чаще приходится полагаться на коллективные знания множества людей. Крайне важно объединять такие знания и связывать людей, обладающих информацией, с людьми, нуждающимися в ней. Ключевую роль в определении зависимостей и последствий предлагаемых изменений играют эксперты с широким пониманием системы. Однако по мере роста и усложнения системы трудно избежать специализации и дробления знаний. К тому же при текущем количестве изменений нецелесообразно просить экспертов проверять детали каждой новой фичи. Нужен способ выявлять изменения, с высокой вероятностью влияющие на (или зависящие от) работу других команд, чтобы уделить таким изменениям особое внимание. Конечно, сделать это не так просто, поскольку порой сравнительно небольшие изменения серьёзно влияют на всю систему.
3.2 Конфликт приоритетов
Зависимости могут приводить к конфликтам между командами. Если одна команда хочет, чтоб другая команда что-то сделала, то Product Owner'ы этих команд обсуждают и определяют приоритет этой работы. Если по итогам обсуждения удается договориться о сроках выполнения, то в дальнейшем управлять этой зависимостью довольно просто. Если внятное соглашение не достигнуто, или если приоритет работы все еще низок, то неопределённость и уровень рисков вокруг данной зависимости возрастают.
Также конфликты возникают, когда одна команда вносит изменение, добавляющее работу другой команде. Например, когда одна команда изменяет архитектуру, так что остальным надо приспособиться к этим изменениям. Изменение не всегда приносит очевидную пользу другим командам, так что иногда люди обижаются и возмущаются появлением дополнительной работы, особенно когда она появляется внезапно. Мы стараемся выявлять такие зависимости на ранних этапах, но некоторые из них неизбежно появляются позже — вследствие уже внесенных изменений либо после пересмотра приоритетов.
3.3 Изменения в планах
Одно из преимуществ Scrum — возможность менять приоритеты команды для каждого спринта. Однако, это усложняет работу с зависимостями. Нельзя просто выявить и продумать все зависимости в самом начале релиз-цикла. Анализ взаимосвязей скорее похож на непрерывный постоянный процесс. По мере работы зависимости появляются и исчезают, пока команды уточняют детали того, что должно быть сделано. Поэтому процесс управления такими зависимостями должен быть динамичным и активным.
3.4 Короткие и пересекающиеся релиз-циклы
В коротких релиз-циклах меньше времени на координацию между командами, поэтому взаимосвязи и их влияние нужно выявлять на ранних этапах. В salesforce.com релиз-циклы пересекаются, в том смысле, что планирование нового релиза начинается до завершения предыдущего. Это сделано намерено, поскольку некоторые команды уже освободились и могут начинать работу над новым релизом. Однако остальные команды могут запаздывать с планированием и пропускать обсуждение зависимостей для следующего релиза. Это серьёзная проблема, учитывая важность коллективного знания для прояснения взаимосвязей.
4 Специальные подходы
В этом разделе мы обсудим конкретные подходы, которые мы используем, чтобы управлять зависимостями и справляться с вышеперечисленными проблемами. Общие стратегии, используемые в этих подходах:
- Сделать общеизвестным — планы на релиз, взаимосвязи, проекты, статус билдов, и т.д.;
- Организовать площадки для обсуждений и обмена знаниями между командами;
- Поощрять самоорганизацию и децентрализованное управление взаимосвязями;
- Автоматизация, автоматизация и еще раз автоматизация.
4.1 Старт релиза
Примерно за месяц до выпуска текущего мажорного релиза мы устраиваем стартовое собрание для следующего релиза. На собрании присутствуют все сотрудники компании. Вице-президенты бизнес-подразделений рассказывают в общих чертах, над какими фичами планирует работать каждая команда в новом релизе. Это собрание заметно помогает управлять взаимосвязями. Прежде всего, оно побуждает команды подготовить их начальные планы на релиз к намеченной дате. Если у какой-то команды остается незавершенная работа из текущего релиза, то эта команда начинает задерживать планирование следующего релиза; в этом случае собрание помогает выполнить планирование к сроку. Трудно выявлять зависимости и обсуждать обязательства с командой, которая понятия не имеет, что она будет делать. Стартовое собрание служит точкой синхронизации команд и помогает обеспечить продуктивное обсуждение межкомандных взаимосвязей.
Кроме того, после собрания планы команды на релиз становятся общеизвестными. Мы стремимся добиться высокой осведомленности о том, чем занимаются все команды, поскольку верим, что это заставляет людей обдумывать и обсуждать взаимосвязи. В стартовом собрании участвуют все руководители R&D, что помогает привлечь людей и сосредоточить внимание на планировании релиза. Высокий уровень участия помогает согласовать ожидания и информировать правление о планах на релиз.
Конечно, планы могу меняться и меняются в процессе работы. Не так давно мы начали проводить обзор обновленной презентации стартового собрания во время ежемесячных обзоров спринтов. Обновленная презентация показывает, какие фичи были исключены или добавлены, и очень помогает поддерживать ясность и публичность планов в течение релиза.
4.2 Сессия выявления взаимосвязей
Приготовив начальные планы на релиз, команды могут более предметно обсуждать взаимосвязи, и множество таких обсуждений возникает спонтанно. В дополнение к этому мы сочли весьма ценным проведение более формальной сессии выявления взаимосвязей, когда совместно работают представители всех команд. Полезней всего проводить такую сессию незадолго до стартового собрания релиза, чтобы повысить качество планов, анонсируемых на этом собрании.
Сессия выявления взаимосвязей устроена довольно просто. Представители (чаще всего Scrum Master или Product Owner) всех Scrum-команд собираются в комнате с большой доской. В первой части сессии все участники одновременно рисуют на доске две диаграммы зависимостей между командами. Одна диаграмма изображает команды, которым нужно, чтоб другая команда сделала что-то для них. Вторая диаграмма изображает команды, делающие нечто, что повлияет на работу других команд. Мы используем несколько простых правил для этих диаграмм:
- Круг обозначает команду;
- Стрелка между кругами обозначает зависимость. На первой диаграмме стрелка проводится от команды, выполняющей работу, к команде, которой нужен результат этой работы. На второй стрелка указывает на команду, на которую влияет чужая работа;
- Метка на стрелке описывает суть зависимости;
- Если зависимость согласована (то есть другая команда согласна выполнить свою часть работы), мы рисуем рамку вокруг метки.
Поначалу царит неразбериха, пока каждый рисует свои взаимосвязи, а наблюдатели задают вопросы и указывают на дополнительные зависимости. Минут через двадцать диаграмма стабилизируется, а комментарии иссякают. После этого мы просим представителя каждой команды коротко рассказать об их зависимостях.
За очень короткое время мы создаем полную картину взаимосвязей в релизе. На рис. 1 показан типичный результат сессии после приведения в более читабельный вид. Сразу выявляются горячие точки (то есть команды с большим количеством зависимостей). Также видны команды, имеющие несогласованные зависимости. Такие команды больше всех рискуют не достичь своих планов, пока их взаимосвязи не согласованы.
Рис.1. Пример диаграммы межкомандных зависимостей
4.3 Открытые обсуждения
С недавних пор в течение недели после стартового собрания мы проводим открытые встречи, главная цель которых — создать площадку для обсуждения вопросов и проблем, связанных с планами команды на релиз. Мы просим, чтоб на этих встречах был хотя бы один представитель от каждой Scrum-команды, в остальном они необязательны для посещения. Обычно в начале открытой встречи участники предлагают темы для обсуждения. Далее в течение 45 минут проходят обсуждения тем в группах, а затем группы рассказывают остальным о результатах обсуждения. Чаще всего участники хотят узнать детали новой и полезной функциональности, а также об изменениях, которых повлияют на другие команды. Участники открытых встреч отметили поучительность таких обсуждений, кроме того людям оказалось интересно общаться с коллегами из других команд, с которыми они не взаимодействуют в обычной работе. Открытые встречи пока что новый формат для нас, так что мы пробуем разные варианты, чтоб понять, что работает лучше, например:
- Предлагать идеи тем до начала встречи;
- Привлекать к участию высокое начальство;
- Менять количество и длительность дискуссий.
4.4 Обзор дизайна
Основная цель собраний по обзору дизайна функциональности — повысить общий уровень качества и удобства наших продуктов, с помощью:
- коллективной мудрости и творчества наших продуктовых команд;
- улучшенной согласованности дизайна между нашими продуктами;
- синергии, возникающей при обмене знаниями между командами.
Эти межкомандные собрания сосредоточены на дизайне функциональности и пользовательского взаимодействия для фич, которые мы считаем ключевыми, наиболее сложными или особо подверженными рискам. На таких собраниях мы стремимся проанализировать и выявить ранее незамеченные несоответствия и зависимости.
Существует два основных типа таких собраний. На ранних этапах релиз-цикла участники фокусируются на концепциях дизайна и стремятся достичь согласованности и эффективного взаимодействия между существующими и новыми фичами. На этой стадии в собраниях обычно участвуют Product Owner’ы и дизайнеры пользовательского интерфейса (UI), и изредка представители других функциональных команд, таких как разработка и QA.
Примерно в середине релиз-цикла состав участников меняется: теперь это в основном представители QA и отчасти разработки, а обсуждения сосредоточены на деталях реализации. Эти встречи обеспечивают понимание и ясность относительно:
- Дополнительных взаимосвязей между командами;
- Дополнительного интеграционного тестирования, которое нужно включить в планы;
- Рисков отдельных фич, а иногда — необходимости ограничить доступ к фиче;
- Специфических задач деплоймента.
4.5 Виртуальная команда архитектуры
Виртуальная команда архитектуры (Virtual Architecture Team, VAT) — «виртуальна», поскольку включает в себя разработчиков из всех Scrum-команд. Члены команды работают в VAT без отрыва от основных обязанностей в рамках Scrum-команды из бизнес-подразделений Applications, Platform или Core Infrastructure.
VAT отвечает за поддержку и развитие архитектуры нашего ПО. Команда определяет дорожную карту (road map) развития архитектуры, проводит обзор серьезных изменений с точки зрения архитектуры, определяет стандарты кодирования, чтобы обеспечить совместимость и поддерживаемость кода.
VAT управляет бэклогом важных архитектурных проектов и необходимого рефакторинга. По мере развития продукта нам приходится перепроектировать фичи и избавляться от старого неоптимального кода. Порой разработчики не хотят менять уже работающие программы, даже когда они понимают, что код программы оставляет желать лучшего. Product Owner’ы предпочитают видеть, как разрабатываются новые фичи, а не как переделывается нечто уже работающее. Чтобы противостоять таким настроениям, каждое наше бизнес-подразделение обязано запланировать не меньше 20% времени в каждом релизе на изменения рекомендованные VAT.
VAT собирается дважды в неделю на два часа для обзора технической реализации продуктов и фич, создаваемых Scrum-командами. Команды, работающие над наиболее сложными фичами релиза обязаны представить их VAT. VAT дает Scrum-команде обратную связь о том, как их технические решения затронут остальные команды, и какие разработки других команд могут повлиять на фичу. VAT сосредоточена прежде всего на технической реализации, особенно на аспектах масштабируемости и производительности. Если дизайн фичи требует серьезных изменений, то Scrum-команда обязана повторно представить фичу в том же релиз-цикле и показать VAT, как они изменили свой дизайн.
4.6 Непрерывная интеграция
Наша веб-инфраструктура автоматизированной сборки, тестирования и сортировки (triage) обеспечивает непрерывную интеграцию билд-системы и позволяет отслеживать состояние каждой строчки кода. Эта инфраструктура — ключевой аспект, позволяющий всем разработчикам и QA инженерам работать с общей базой кода.
Главный набор тестов построенный на расширении JUnit дает возможность создавать функциональные тесты с помощью API Force.com. Кроме того, у нас есть фреймворк для тестирования пользовательского интерфейса, использующий Selenium для автоматизации тест кейсов, которые нужно выполнять через UI.
Вот несколько фундаментальных принципов, определяющих наш подход к автоматизации:
- Давать разработчикам быструю обратную связь, чтобы они видели результаты своих изменений. Каждый коммит запускает сборку билда и выполнение набора тестов. В случае ошибки ответственные инженеры сразу же получают сообщение о сбое. Базовый набор тестов выполняется за полчаса, и разработчик получает результаты проверки внесенных им изменений. Периодически в течение дня выполняется расширенный набор тестов;
- Быстро чинить сборку и сбои тестов. Для этого у нас есть роль «мастера сборки», меняющая владельцев каждую неделю. Обычно эту роль выполняют два тесно взаимодействующих человека — менеджер разработки и старший разработчик. Мастер сборки отвечает за проверку результатов сборки, отслеживание тестовой истории и сбоев на различных строчках кода, а также назначение багов конкретным разработчикам для починки. У нас есть специальная панель, отображающая различные метрики исходя из собранных в базе данных результатов тестов (доля успешных тестов, время сборки, количество сбоев и т.д.). Мастер сборки использует эти данные при подготовке отчета о состоянии сборки;
- Поддерживать высокий уровень покрытия автоматизированными тестами. Обычно Scrum-команды стремятся покрыть автоматизированными тестами 70-80% кода. Один из наших важнейших активов — большой набор автотестов, играющий ключевую роль в поставке качественных релизов в срок каждые 3-4 месяца.
4.7 Scrum-of-Scrums
В каждом бизнес-подразделении еженедельно проводится собрание Scrum-of-Scrums, существует и " Scrum-of-Scrum-of-Scrums". Иногда мы организуем дополнительный Scrum-of-Scrums для группы команд, тесно взаимодействующих при работе над общей целью. Мы опробовали несколько различных форматов проведения Scrum-of-Scrums. Мы начали со стандартного формата «4 вопроса», когда команды сообщали, что они сделали, что собираются делать, что их блокирует, и делают ли они что-то влияющее на работу других команд. Поначалу это работало, но вскоре стало утомительным и скучным из-за большого количества команд. Тогда мы перешли к более открытому формату самоорганизации, когда участники предлагали темы для обсуждения, выписывая их на доске в начале собрания. Это заставило участников взять на себя ответственность за содержание митинга и привело к более продуктивным обсуждениям. Вопрос межкомандных зависимостей часто поднимается во время Scrum-of-Scrums, особенно на ранних стадиях разработки. Сессия распознавания взаимосвязей проводится во время Scrum-of-Scrums, и в последующие две-три недели на этом собрании часто обсуждаются изменения в межкомандных зависимостях.
4.8 Отчеты о состоянии
Когда команда переходит на Scrum, письменные отчеты часто становятся не нужны, поскольку ясность состояния теперь обеспечивается за счет других вещей (обзоры спринтов, burndown chart, ежедневные стендап-митинги). Когда мы перешли на Scrum, то решили сохранить облегченные еженедельные отчеты о статусе, которые готовит каждый Scrum мастер. Это выглядело избыточно пока мы использовали формат «4 вопроса» для Scrum-of-Scrums. Однако при нынешнем открытом формате Scrum-of-Scrums еженедельные отчеты стали важным дополнением к этому собранию. Мы не обсуждаем состояние каждой команды во время Scrum-of-Scrums, если только это не вынесено как отдельный вопрос, однако этот статус всегда доступен в еженедельном отчете. В отчете обозначены все зависимости, блокеры и риски. Конечно, такие отчеты требуют немного дополнительных усилий от Scrum мастеров, но ясность, которую они обеспечивают, оправдывает затраты на их создание.
5 Заключение
Salesforce.com доказала, что масштабирование Scrum осуществимо, и мы уверены, что сможем продолжать такое масштабирование по мере роста компании. По мере роста количества команд, управление взаимосвязями и межкомандная координация становятся непростой задачей. Критически необходима надежная инфраструктура сборки и автоматизированного тестирования. Очень помогает повышение осведомленности и синхронизация с помощью стартового собрания, сессии выявления взаимосвязей, Scrum-of-Scrums и облегченных отчетов о состоянии. В конечном итоге это приводит к эффективному общению, взаимодействию и обмену знаниями между командами. Такие подходы, как виртуальная команда архитектуры, открытые обсуждения и Scrum-of-Scrums призваны помочь общению и поддержать взаимодействие.
Автор: notsocritical
