Распределенный Scrum
Дэвид Старр является главным специалистом по программному обеспечению для сайта Scrum.org, где он направляет свои усилия на профессиональное развитие разработчиков программного обеспечения. Кроме того, он основал сетевое техническое сообщество ElegantCode.com.
Июль 2012
У распределенных команд часто возникают проблемы со стабильностью, своевременностью и эффективностью обмена информацией. Из этой статьи вы узнаете, почему подход Scrum представляет собой "контейнер", позволяющий совершенствоваться и добиваться успеха распределенным командам различных типов.
Концепция Scrum ничего не говорит о распределенных командах разработчиков. Scrum не требует, чтобы всех члены команды Scrum или даже члены команды разработчиков находились в одном кабинете, здании, городе или часовом поясе. Команды Scrum активно выявляют препятствия на пути к повышению производительности, и, когда коммуникация становится таким препятствием, подход Scrum делает это очень наглядным.
Когда члены команды физически не работают в одном месте, взаимодействие внутри команды неизбежно становится более сложным, как и программное обеспечение, создаваемое этой командой. В 1968 году Мелвин Конвей сформулировал это так:
Организации, которые разрабатывают системы, неизбежно создают структуры, воспроизводящие схемы коммуникации внутри самих этих организаций.
Закон Конвея — это больше, чем просто красивая фраза; он нашел свое подтверждение в командах разработчиков программного обеспечения. В одном из исследований действие закона Конвея было продемонстрировано путем измерения влияния распределения команды на архитектуру системы. Когда члены команды распределены, они стремятся создавать в коде больше уровней абстракции, пытаясь изолироваться друг от друга [1].
Обзор
Как команда проявляет себя в коде
Стелла — разработчик в команде Scrum, которая стабильно выполняет работу, прогнозируемую в каждом из спринтов. Ее команда имеет репутацию высококлассных разработчиков ПО, несмотря на то что их код несколько трудно понимать другим разработчикам.
Она работает на дому и в другом часовом поясе по сравнению с остальными членами своей команды. Они используют электронную почту, дорогостоящую систему управления требованиями и время от времени проводят видеоконференции для обсуждения своей работы в рамках каждого спринта. Они используют Scrum согласно инструкциям, подбирая время ежедневного Scrum-собрания в соответствии с расписаниями всех членов команды. Она принимает участие в собраниях по планированию и ежедневных Scrum-собрания по телефону и не видит лиц коллег, когда они выступают. Кроме того, она не слышит их обсуждений, происходящих до ежедневного Scrum-собрания и после него.
Исходя из лучших побуждений Стелла создает в своем коде уровень абстракции, чтобы ее работа была лучше изолирована и протестирована. Эта новая абстракция отделяет его реализацию от интерфейса, который она объявила и предоставила остальным членам команды. Она полагает, что такой подход позволяет создать архитектуру из хорошо разделяемых частей. "Использование интерфейсов в качестве изоляции для реализации — это просто хорошая практика объектно-ориентированного программирования", — напоминает она себе. Ее подключаемая модель позволяет ей работать над своей частью кода, не вмешиваясь в работу коллег.
Основанный на законе Конвея прогноз сбывается: ее код отражает ее способ взаимодействия с командной — слабо связанное взаимодействие. Разрабатываемая ею архитектура заменяет общение с командой, поэтому система становится излишне сложной. Излишняя сложность — это отражение ее отношений с другими членами команды разработчиков. Эти решения в конечном счете будут стоить денег ее компании, так как число строк поддерживаемого кода увеличивается, новым разработчикам приходится разбираться в большем числе ссылок, а для проверки работоспособности абстракции требуется больше тестов.
Стелла не сделала ничего неправильного. На самом деле она успешно применила рекомендуемые практики объектно-ориентированного программирования, чтобы изолировать проблемный участок в системе. К сожалению, проблемой, которую она изолировала, были ее собственные трудности в коммуникации, а найденное решение позволяет ей взаимодействовать с коллегами еще реже. В результате системой, которую она изменила, чтобы решить проблему, стало программное обеспечение. Более эффективным способом разрешения этой ситуации было бы упростить взаимодействие с членами команды разработчиков.
Когда члены команды не сидят рядом, они стремятся заменить вербальную коммуникацию на более сложную и формальную систему взаимодействия. Вместо того чтобы быстро и эффективно обсуждать небольшие тактические решениях, вопросы ставились в очередь для обсуждения в будущем. Зачастую это будущее никогда не наступало. Снижение числа прямых контактов между людьми переводит взаимодействие между ними в другие формы, например в спецификации, списки задач для выполнения и даже в код. Программные интерфейсы прикрывают недостатки создающих их команд.
Непреднамеренная сложность распределения команд
Решения, принимаемые за пределами команды Scrum, являются наиболее вероятной причиной увеличения сложности. Команды разработчиков программного обеспечения редко имеют простую структуру или систему постановки задач, и принципы Scrum задают границы, внутри которых команда Scrum может маневрировать и снижать сложность. Несмотря на это, сложность фактического написания кода и выпуска ПО иногда не идет ни в какое сравнение со сложностью организационной культуры и процессов, лежащих на пути у команды разработчиков.
Решение о формировании команды Scrum из людей, живущих в разных часовых поясах, редко принимается людьми, которые выполняют фактическую работу. Решения о создании распределенных команд Scrum чаще всего исходят от руководителей, которые пытаются собрать команду из высококлассных специалистов или, что более вероятно, пытаются снизить расходы на разработку ПО за счет привлечения удаленных поставщиков. Хотя такие модели позволяют снизить изначальные затраты на разработку ПО, как правило, они не учитывают стоимость текущего обслуживания, а также дополнительную сложность, связанную с затрудненным взаимодействием между членами команды разработчиков.
Независимо от того, как или почему создаются распределенные команды, они являются реальностью, и ничто не указывает на то, что их становится меньше. Но даже в случае распределенных команд Scrum остается превосходной концепцией для управления планированием и реализацией выпуска программных продуктов. Члены команд должны лишь прикладывать больше усилий для улучшения имеющихся каналов коммуникации и бороться с попытками "оптимизации", подобных той, что была описана в примере выше.
Распределенная реальность
Использование распределенных команд позволяет привлекать к работе нужных специалистов, независимо от того где они живут, а для некоторых людей оно дает возможность жить там, где они хотят, а не рядом с офисом своей компании. Хотя критиковать модель распределенных команд очень легко, экономические факторы выбора между сторонними поставщиками, собственными специалистами, людьми, проживающими поблизости или в определенной местности, будут в значительно мере определять решения многих организаций.
Руководство по Scrum, опубликованное на сайте Scrum.org, фиксирует принципы Scrum и задает набор правил по применению методологии Scrum. Хотя в руководстве по Scrum ничего не сказано о распределенных командах и работе с ними, Scrum делает очевидными проблемы коммуникации, характерные для команд, члены которых не могут общаться друг с другом без помощи электронных устройств.
Доверие имеет значение
В общении между людьми большую роль играют жестикуляция и мимика. Информация, которую мы получаем, глядя на поведение человека во время обсуждения решения, не менее ценна, чем информация, записанная на доске. Поэтому при решении проблем взаимодействия внутри распределенных команд большое внимание следует уделять тому, чтобы компенсировать отсутствие невербальной коммуникации.
Стив Макконнелл писал: "Период полураспада доверия составляет 6 недель". [2] Это означает, что у разработчиков, которые каждый день работают вместе и взаимодействуют друг с другом, формируется определенный уровень взаимного доверия. Степень доверия может быть разной, но вероятность высокого уровня доверия будет выше в ситуации, когда члены команды часто видят друг друга и работают вместе.
Когда коллеги перестают видеться каждый день и не работают друг рядом с другом на протяжении примерно шести недель, уровень доверия в отношениях между ними снижается примерно вдвое. Оставшийся запас доверия быстро сокращается с течением времени.
Это не значит, что люди перестают ценить или уважать друг друга, но доверие и эффективность работы в команде исчезают. Без доверия эффективность совместной работы снижается, а границы между товарищами по команде становятся все более плотными. Эти границы часто находят свое отражение в коде.
Камеры, телеконференции, программы-мессенджеры, видеочаты, совместный доступ к экрану и другие инструменты совместной работы помогают наладить взаимодействие между коллегами, и они должны стать неотъемлемой частью рабочей среды распределенных команд, чтобы последние могли поддерживать высокую эффективность работы. Частые сеансы видеосвязи могут сыграть большую роль в деле восстановления запасов доверия.
Какие бы инструменты не использовались распределенными командами, для повышения эффективности важно использовать каналы коммуникации, обеспечивающие максимальную точность воспроизведения. Иными словами, телефонный разговор предпочтительнее обмена сообщениями в мессенджере, а последний лучше, чем электронная почта. Сокращение интервала между взаимодействиями приносит дополнительную пользу.
Степени разделения
Существуют различные сценарии, в которых члены команды оказываются отделены друг от друга, и есть часто встречающиеся модели распределения команд. Как и модели в других ситуациях (например, модели проектирования ПО), модели распределения команд могут возникать случайно или преднамеренно. Случайные модели возникают как неосознанный ответ на существующее давление, а преднамеренные модели реализуются специально для контроля над сложностью.
Описанные ниже модели распределенных команд Scrum могут возникать как преднамеренно, так и случайно. Они могут быть обусловлены решениями, принимаемыми за пределами команды Scrum, или быть результатом самоорганизации команды Scrum вокруг определенной проблемы. Следующие модели распределения являются наиболее распространенными, независимо от причин для их возникновения.
Удаленные команды разработчиков работают вместе, но физически отделены от остальной компании.
В модели удаленного члена команды один член команды работает отдельно от остальных.
В распределенной команде члены команды работают над достижением общей цели, но все они находятся в разных местах.
Удаленная команда разработчиков
Некоторые команды разработчиков оказываются географически отделены от большой головной организации или даже от владельцев продукта. Такая ситуация часто возникает, когда одна компания приобретает другую или когда происходит слияние двух компаний. Если команда разработчиков должна быть удаленной, Scrum является идеальным способом управления работой и взаимодействием этой команды с более крупной организацией. В наше время многие команды успешно работают по этой формуле.
Хотя ситуации бывают разными, удаленные команды разработчиков часто чувствуют себя лишенными влияния, недооцененными и отрезанными от основной организации. Членам удаленной команды может не хватать внимания со стороны родительской копании, которая может (зачастую непреднамеренно) считать эту команду менее важной по сравнению с командами, работающими в офисе компании.
Такие удаленные команды разработчиков постоянно находят причины, оправдания и возможности, чтобы не интегрировать результаты своей работы с другими командами. Они легко могут объяснить, интеграция данного спринта не важна, не нужна или невозможна. Недовольство нарастает, в результате чего команда разработчиков начинает считать запросы на интеграцию кода с другими командами "необоснованными", "оторванными от реальности", "ненужными" или "не учитывающими наших потребностей".
Обоснованность этих суждений перестает иметь значение. Члены удаленной команды разработчиков хотят быть услышанными и понятыми, а также хотят чувствовать собственную ценность в масштабах всей организации. Когда ты существуешь в стороне от остальной организации, легко забыть, что команда является частью чего-то большего.
Координатор Scrum, физически отделенный от команды разработчиков, — верный путь к провалу. Координаторы Scrum не могут эффективно выполнять свои задачи по обучению, проведению эффективных мероприятий Scrum и поддержке процесса Scrum издалека. Расстояние между командой разработчиков и координатором Scrum препятствует взаимодействию и сильно увеличивает риски. Тесный контакт очень важен для установления доверия, а взаимное доверие является ключевым фактором успеха для Scrum.
Координаторы Scrum работают вместе со своими командами.
Чтобы команда разработчиков успешно решала задачи владельца продукта, очень важно обеспечить беспрепятственное и четкое взаимодействие между всеми сторонами. Владелец продукта должен быть доступен для команды в течение каждого спринта для ответа на вопросы и предоставления обратной связи о выполняемой работе. Хотя удаленная работа позволяет обеспечить частый обмен информацией, очень важно установить надежный механизм для поддержания взаимодействия.
Отсутствие владельца продукта является одним из самых разрушительных факторов работы команды Scrum. Оставленная без внимания команда разработчиков вынуждена принимать решения без учета функциональности и приоритетов. Такая команда редко может принимать правильные решения относительно функциональности, поскольку она, как правило, хуже информирована о потребностях клиентов, в отличие от владельца продукта.
Владельцы продукта взаимодействуют с командой разработчиков и обеспечивают обратную связь на протяжении спринта.
К сожалению, отсутствующий или редко доступный владелец продукта — это частая ситуация для команд Scrum, даже если команда работает в том же здании. Чтобы в максимальной степени реализовать потенциал Scrum, команда должна действовать как цельная единица, обеспечивающая высокий уровень доверия и взаимодействия, что требует постоянного внимания со стороны выделенного владельца продукта.
Удаленный член команды
Некоторые разработчики отделены от коллег, которые работают вместе в одном помещении. Классический пример — удаленный разработчик, который исправно работает с командой из дома. Хотя причины для возникновения такой конфигурации могут быть различными, она встречается все более часто.
Алистер Коберн придумал термин осмотическое взаимодействие[3] для описания естественного взаимодействия между членами команды в одной комнате.
Осмотическое взаимодействие означает, что информация распространяется в виде звукового фона для членов команды, и они получают необходимые сведения посредством своего рода осмоса.Обычно для этого достаточно поместить всех разработчиков в одну комнату.В результате, когда один сотрудник задает вопрос, другие присутствующие могут "настроиться" на дискуссию, приняв участие в ней, или наоборот, отключиться, продолжив работу.
Осмотическое взаимодействие может существовать не только в командах разработчиков. В ньюсрумах крупных газет и информационных агентств имеет место такой же процесс. Даже в отделах сыска в отделениях полиции по всеми миру используются общие помещения для формирования коллективного понимания ситуации при расследовании преступлений.
Потеря осмотического взаимодействия означает потерю понимания текущей ситуации членами команды. Если разработчик программного обеспечения не получает оперативную информацию о том, какие изменения вносятся в программное обеспечение его коллегами, нарушается целостность команды и теряется общее понимание контекста. Вся эта ценная информация, витающая в воздухе общей комнате команды, проходит мимо сконцентрированного на своей работе и ни на что не отвлекающегося удаленного сотрудника. Он не участвует в обсуждениях архитектуры продукта и других решений, который постоянно возникают в течение дня.
Тенденция к сокращению сроков выпуска программного обеспечения и интервалов между версиями требует еще большей осведомленности членов команды о текущем положении дел. Удаленный сотрудник, не имеющий возможности находиться в одной комнате с остальными членами команды, лишен этой осведомленности.
Для решения этой проблемы все чаще используются средства для проведения телеконференций. Простую систему для проведения телеконференций можно построить на базе недорого ноутбука, камеры и колонок. Размещение такой системы в комнате, где работает команда, может создать открытый канал коммуникации для удаленного разработчика, который не будет прерывать сеанс связи на протяжении рабочего дня.
Видеосвязь и средства проведения телеконференций помогают решить проблему отсутствия невербального взаимодействия.
К признакам того, что удаленный сотрудник не воспринимает себя как полноценного члена команды, относятся следующие:
использование письменных средств связи, таких как электронная почта и мессенджеры, для обсуждения сложных вопросов;
определение фиксированных интерфейсов в качестве контрактов в коде, вместо того чтобы чаще обсуждать взаимодействие с другими разработчиками;
использование личной ветви кода в системе управления версиями.
Для повышения степени вовлеченности удаленного разработчика в работу команды очень полезными бывают периодические встречи. Видеосвязь следует предпочитать телефонным звонкам. Телефонные звонки лучше, чем текстовые мессенджеры, а использование только электронной почты может привести к катастрофе.
Распределенная команда
В по-настоящему распределенных командах Scrum отдельные члены команды вместе работают над достижением единой цели спринта, но все члены команды находятся в разных местах. Типичный пример — проект с открытым исходным кодом, разработчики которого разбросаны по всему миру. Хотя вопросы взаимодействия имеют большое значение, такая модель продемонстрировала свою применимость на практики. Коммуникация в рамках такой команды вызывает естественные трудности, но данная модель становится все более распространенной по мере того как развиваются технологии, упрощающие невербальное взаимодействие.
Когда члены команды находятся в разных местах, ключевую роль в эффективном обсуждении архитектуры решения и кода начинает играть возможность совместного доступа к экрану. Если оба участника дискуссии не могут видеть один и тот же код, чрезмерно возрастает роль допущений. К счастью, ПО для совместного доступа к экрану широко доступно и весьма эффективно. Члены команды, которые не находятся в одном помещении, должны несколько раз в день общаться с коллегами с использованием демонстрации экрана.
Совместный доступ к экрану может быть очень эффективным инструментов для парного программирования и совместной работы.
Совместная проверка кода, элементов невыполненной работы и артефактов является прекрасным механизмом обеспечения высокого уровня осведомленности распределенных команд о текущем положении дел. Еще один эффективный подход — ввести простое правило проверки для всех элементов, создаваемых в рамках спринта. Правило двойного контроля формулируется следующим образом:
Элемент может считаться завершенным только после проверки в среде интеграции.Разработчик элемента не может выполнять проверку за самим собой.
Команды разработчиков, применяющие это простое правило, добиваются гораздо лучшего совместного понимания хода выполняемых командой работ.
Примечание автора. Мне довелось работать с командой, члены которой находились в одном здании, но в разных кабинетах. Компания очень гордилась тем, что может предоставить каждому сотруднику свой кабинет. В конце концов команда разработчиков решила создать виртуальную комнату, для "присутствия" в которой каждый член команды использовал камеру, микрофон и колонки. Виртуальная комната всегда оставалась открытой, а члены команды заглядывали в нее по мере работы над общим продуктом. Через некоторое время члены команды очень полюбили виртуальную комнату. Они начали использовать ПО для совместного доступа к экрану вместо того чтобы ходить друг к другу по коридору, поскольку так получалось быстрее. Сотрудники стали использовать виртуальную в течение всего дня, хотя они сидели в соседних кабинетах. Наконец, один из членов команды попробовал несколько дней не ходить в офис, а работать из дома. В ходе ретроспективного собрания по спринту члены команды пришли к выводу, что с виртуальной комнатой не имеет значения, где находится сотрудник — дома или в соседнем кабинете. Виртуальная комната команды оказалась удобнее, чем отдельные кабинеты.
Инструменты и практики
В наше время очень много говорят о командах Agile, которые управляют своей работой с помощью низкотехнологичных инструментов, обеспечивающих передачу информации без искажений. Если добавить к этому сложность территориального распределения или взаимодействие нескольких команд разработчиков, придется признать, что бумажные карточки и маркеры не могут составить альтернатив программным решениям. Это привело к появлению огромного количества средств управления работой, предназначенных специально для команд Scrum и Agile, а многие поставщики таких средств даже обещают вам, что именно их продукт сделает вашу команду "гибкой".
Не путайте инструментами и практики
Разумеется, никакой инструмент не сделает команду "гибкой". Подлинная гибкость основана на культуре, отношении и поведении людей, которые создают программное обеспечение. Поэтому в манифесте Agile[4] подчеркивается ценность "людей и взаимодействия по отношению к процессам и инструментам".
В сообществе Agile принято говорить: "люди важнее процессов, процессы важнее инструментов".
Прагматики обычно говорят: "инструменты задают правила".
Оба эти высказывания описывают отношения между людьми и программными обеспечением, используемым для взаимодействия и управления работой. Средства отслеживания работы призваны упростить взаимодействие и добиться лучшего понимания, однако могут привести и к прямо противоположным результатам. Зачастую люди увлекаются излишней регистрацией дефектов, вместо того чтобы просто исправлять их.
Примечание автора. Отличным ресурсом, помогающим найти баланс между инструментами, процессами и практиками, является статья Кента Бека Tools for Agility (Инструменты обеспечения гибкости). Эта статья не потеряла своей актуальности и сегодня, хотя и была написана в 2008 году.
Мы часто слышим от координаторов Scrum и членов команд разработчиков жалобы: "этот инструмент устарел", если данные в их системе отслеживания работы и функций неактуальны. При этом не учитывается очевидное:
мы должны стремиться к актуальности информации у членов команды, а не к актуальности инструмента.Иногда инструменты помогают добиться этого.
Методика Scrum специально разработана таким образом, чтобы повышать осведомленность команды Scrum о текущем положении дел. В Scrum ничего не сказано о формате требований, ведении протоколов собраний, разбиении работ, единицах оценки или отслеживании времени. Если команды считают эти практики полезными, они могут работать в контексте Scrum. Но команды, использующие эти дополнительные практики, делают это в дополнение к Scrum, а не благодаря Scrum.
Поддержка практик с помощью инструментов
Любой инструмент, используемый командой Scrum, вероятнее всего, выбран для поддержки практики, которая была определена до выбора инструмента. Это значит, что эффективные команды Scrum осознанно совершенствуют свою работу. Это предполагает опробование новых практик и подходов, поскольку команда стремится к улучшениям в определенной области. Команда может прийти к поддержке новой практики с помощью определенного инструмента после определения более базовых принципов. Иными словами:
Сначала выберите лучших людей.Как самоорганизующаяся команда они выберут собственные практики, а затем подберут инструменты для поддержки этих практик.Цените людей больше, чем процессы, а процессы — больше, чем инструменты.
(Дополнительные сведения об инструментах для поддержки различных практик, доступных в Microsoft Visual Studio 2012, см. в разделах Совместная работа (изучаем в подробностях) [перенаправление], Совместная работа [перенаправление] и в разделе Изучение портала начала работы с Visual Studio Online.)
Способ совместной работы членов команды оказывает неизбежное и очевидное влияние на создаваемое ими программное обеспечение. Если взаимодействие происходит легко и эффективно, это находит свое отражение и в архитектуре ПО. И наоборот, если членам команды трудно взаимодействовать друг с другом или со своими заказчиками, в полученном продукте будут видны эти проблемы.
Регулярные циклы проверки и адаптации Scrum могут в значительной мере помогать распределенным компаниям. События, обязательные для Scrum, делают взаимодействие неизбежным, но они не всегда влияют на форму такого взаимодействия.
Команда, находящаяся в одной комнате, использует наименее технологичный, но наиболее высокоэффективных способ взаимодействия без искажения информации, позволяющий членам команды совместно создавать сложное программное обеспечение. Но удаленные команды никуда не исчезнут. В силу личных обстоятельств, экономических стимулов или обычной недальновидности все больше и больше команд Scrum оказываются в ситуациях, когда члены команд физически разделены.
Если команды будут уделять должно внимание взаимодействию с учетом физических границ, они добьются более высокого качества работы, лучшего взаимопонимания, более высокой скорости работы и удовлетворенности сотрудников. При тщательном выборе инструментов и практик распределенная команда также может работать хорошо. Даже очень хорошо.
Ссылки
Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond. IEEE Software, 7
McConnell, S. (2009). Travel Restrictions and Offshore Development.
Cockburn, A. (2008). Osmotic Communication.
Коллектив авторов. Манифест Agile.