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

The Wisdom of Teams: Creating the High Performance Organization[32]32
  Катценбах Дж., Смит Д. Командный подход: Создание высокоэффективной организации.


[Закрыть] [Katzenback2015] – классическое издание о высокоэффективных командах.

Agile Conversations [Squirrel2020] – отличный ресурс для коучей, которые помогают командам и организациям развить культуру Agile.

Аудитория

Вся команда, коучи

Мы взаимодействуем быстро и эффективно.

Карго-культ

Окончание истории

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

Когда вы возвращаетесь, ответа от Линн все еще нет, поэтому вы заглядываете в пару блогов по теме разработки, которые собирались почитать. Через полчаса вы получаете ответ Линн.

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

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

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

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

Чтобы справиться с этой проблемой, многие команды пытаются снизить необходимость прямого общения. Это спорный способ. Если вопросы порождают задержки и ошибки, снизьте необходимость задавать вопросы! Люди тратят больше времени на предварительное выяснение требований и документирование каждой потребности. Согласно этой теории, впоследствии программистам не нужно будет общаться с экспертами; они могут просто посмотреть ответы в документе.

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

См. также

Вся команда (глава 7)

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

См. также

Поэтапные требования (глава 8)

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

Это сто́ит того, чтобы повторить еще раз: команды поставляли ПО за треть обычного времени. После пилотного исследования еще 11 команд достигли того же результата.

Ключевая идея

Личное общение

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее.

Манифест Agile для разработки программного обеспечения

Несмотря на успехи технологий, непосредственное, личное общение остается самым эффективным способом общения. Перефразируя [Cockburn2006] (гл. 3), существует несколько осей эффективности общения. Удаление каждой из них делает его менее эффективным.

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

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

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

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

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

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

См. также

Вся команда (глава 7)

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

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

Всегда просите помощи, всегда помогайте

Если вы зациклились на проблеме, а кто-то в команде знает ответ, попросите его помочь. Нет смысла биться головой о стену. Многие команды заключают рабочее соглашение: «Мы всегда помогаем, когда член команды просит помощи».

Некоторые, услышав это правило, беспокоятся, что не будут продуктивными. И в некоторой степени они правы. Если вы будете проводить много времени, отвечая на вопросы, то вы, возможно, будете не столь продуктивны. Но Agile – это команда. Даже если вам в конечном итоге придется тратить больше времени, команда в целом будет более продуктивной.

А как насчет программирования и другой работы, требующей глубокой сосредоточенности? Согласно [DeMarco2013], у программиста уходит 15 минут и больше на то, чтобы погрузиться в работу после прерывания. Не может ли культура, в которой все время просят о помощи, повредить общей продуктивности программирования?

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

См. также

Парное программирование (глава 12)

Групповое программирование (глава 12)

Лучший способ избежать длительного отвлечения в случае прерываний – использовать парное или групповое программирование. В случае парного программирования, пока один человек отвечает на вопросы, второй может продолжать размышлять над текущей задачей. По завершении прерывания вопрос «На чем мы остановились?» вернет процесс в прежнее русло. В случае группового программирования прерывание становится еще меньшей проблемой; как правило, оно имеет тенденцию вовсе не происходить, поскольку все работают вместе. А когда происходит, тот, кого отвлекли, просто отходит в сторону, а остальные продолжают работать.

См. также

Согласование (глава 7)

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

Легко входите в дискуссии и выходите из них

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

Когда кто-то начинает разговор, вам не обязательно сразу в нем участвовать. Подслушайте, о чем речь, и решите, нужно ли что-либо от вас. Так, если оказывается, что дискуссия не имеет к вам отношения, то не нужно в ней участвовать. Вы можете вернуться к работе. Это называется «закон мобильности», или «закон двух ног» (Law of Mobility, или Law of Two Feet): «В любой момент времени, если вы не учитесь чему-то важному и не вносите какой-либо вклад в общее дело, переместитесь в то место, где вы будете это делать»[33]33
  Закон мобильности, или закон двух ног, пришел из «Технологий открытого пространства» Харрисона Оуэна – прекрасного подхода к организации продуктивных дискуссий в больших группах.


[Закрыть]. И наоборот! Если оказывается, что обсуждение имеет к вам отношение, то присоединитесь к нему.

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

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

Создавайте визуализации

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

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

См. также

Визуальное планирование (глава 8)

Планирование задач (глава 9)

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

Работайте одновременно

При совместной работе не позволяйте процессу проходить через узкое место, которым может стать, например, единственный специалист. Убедитесь, что все могут вносить свой вклад одновременно. Например, при планировании избегайте того, чтобы один человек сидел за компьютером и вносил все данные в электронную систему планирования. Вместо этого визуализируйте план с помощью индексных карточек или их виртуального эквивалента. Таким образом множество людей могут писать новые карточки одновременно, менять план (и обсуждать изменения), передвигая карточки и указывая на них.

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

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

Примечание

Помните, что критиковать идеи во время мозгового штурма не нужно. И он лучше всего работает, когда состоит из двух частей: первая – генерация идей в свободной форме, где годится все; вторая – уточнение и фильтрация идей.

Иногда я провожу одновременный мозговой штурм, используя сопоставление, или картирование сходства (affinity mapping). Чтобы сделать карту сходства, возьмите все карточки, заполненные командой во время мозгового штурма, и разложите их произвольно на столе или белой доске. Затем переместите их так, чтобы наиболее похожие идеи оказались рядом друг с другом, а наименее похожие – в отдалении. Все участники работают одновременно, передвигая карточки, как только видят нужное направление. В конце концов карточки должны сформировать кластеры, которым можно дать названия.

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

Еще один способ фильтрации ваших идей после мозгового штурма – точечное голосование (dot voting). Каждый имеет определенное количество голосов. (Я умножаю количество вариантов на три, а затем делю на количество участников.) Все голосуют одновременно, ставя точку на вариант, который они предпочитают. Можно голосовать за один вариант несколько раз. Например, если у вас четыре голоса, то вы можете поставить по одной точке на четыре разных варианта, четыре точки на один вариант или сделать что-то среднее. Побеждают варианты, получившие наибольшее количество голосов.

Стремитесь к согласию

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

Вместо всего этого используйте голосование согласием (consent vote). При таком способе голосования кто-то высказывает предложение, и затем все голосуют одним из следующих способов: «Я согласен» (большой палец вверх при личном общении, «+1» – в групповом чате), «Я вместе с группой» (большой палец в сторону или «+0») или «Я не согласен и хочу объяснить почему» (большой палец вниз или «–1»). Чтобы избежать случайного давления друг на друга, вы можете договориться, что каждый раскрывает свой вариант голосования на счет три.

Если никто не выбирает вариант «Я согласен», предложение не принимается из-за отсутствия интереса. И наоборот, если отсутствуют несогласные, оно проходит. Если все же кто-то не согласен, то объясняет свои возражения, и группа корректирует предложение, чтобы устранить их. Предложение не проходит, пока не устранены все возражения.

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

Соглашайтесь на эксперимент

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

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

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

Бьорн Фриман-Бенсон, технологический лидер, имеющий многолетний опыт управления распределенными группами, сказал: «Наши виртуальные команды были гораздо менее креативными. Нам приходилось комплектовать команды с большей численностью персонала, чтобы получать тот же уровень креативности… Ключевой момент любого бизнеса, в котором я был, – это творческий потенциал, в удаленных командах его меньше из-за разногласий. Вы можете даже получить больше единиц работы, но тикеты Jira не оплачивают счета» [Shore2019].

Эффект коктейльной вечеринки

Отчасти причина того, что физические командные комнаты более эффективны, заключается в эффекте коктейльной вечеринки, который [Cockburn2006] называет осмотической коммуникацией. Случалось ли вам разговаривать с кем-либо, стоя посреди переполненной людьми комнаты, и внезапно услышать свое имя? Даже если вы были сконцентрированы на вашей беседе, ваш мозг прислушивался ко всем остальным разговорам. Услышав ваше имя, он воспроизвел эти звуки в вашем сознании. Вы слышите не только ваше имя, но и отрывок обсуждения, в котором оно прозвучало.

Представьте себе команду поставки, которая сидит вместе. Члены команды работают в парах и ведут тихие разговоры. Потом один из программистов упоминает что-то насчет управления соединением с базой данных, и другой оживляется: «О, мы с Кейли на прошлой неделе сделали рефакторинг соединений с базой данных. Больше не нужно управлять соединениями вручную». Когда членам команды удобно разговаривать таким образом, то это происходит часто (по меньшей мере раз в день) и всякий раз экономит время и деньги.

Дизайн вашей командной комнаты

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

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

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

И наконец, уделите внимание человеческому фактору. Людям комфортнее, когда их рабочее место освещается естественным образом, там есть растения и цвета. Оставьте пространство для индивидуальности. Если у людей нет своих постоянных мест, как это обычно бывает при парном и групповом программировании, предоставьте им место для хранения личных вещей. Добавьте книги (например, эту), чтобы их можно было просто полистать или сверить какую-либо информацию.

Сделайте так, чтобы всю мебель можно было передвинуть, вместо того чтобы прикручивать ее к полу. Тогда члены команды смогут настроить свое рабочее место под свои потребности.

Множество команд

Из комнат, где сидят Agile-команды, обычно доносится ровный гул голосов, периодически перекрываемый возгласами торжества. Это вряд ли будет мешать членам вашей команды, но может беспокоить ваших соседей. Убедитесь, что командная комната хорошо шумоизолирована.

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

Личное оборудование и принадлежности

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

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

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

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

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

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

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

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

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

• разноцветные индексные карточки (не менее 2000 штук каждого цвета). Убедитесь, что каждый в команде различает цвета[34]34
  Один из восьми человек имеет ту или иную форму дальтонизма.


[Закрыть];

• стикеры разного цвета, размера и формы;

• карандаши, ручки и маркеры на водной основе для рисования на карточках и стикерах. Избегайте перманентных маркеров; они сильно пахнут, и к тому же кто-нибудь неизбежно испачкает ими белую доску[35]35
  Профессиональный совет: следы от перманентного маркера на белой доске можно удалять, рисуя поверх него маркером для белой доски и немедленно стирая.


[Закрыть];

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

• магнитные кнопки для прикрепления карточек и документов к доске;

• экземпляр этой книги и другие полезные справочные материалы.

Командам, работающим в парном программировании в режиме личного общения, также понадобятся специальные рабочие станции (см. раздел «Парное программирование» главы 12):

• широкие столы, подходящие для работы бок о бок. Некоторые команды предпочитают иметь или оба варианта столов (столы для работы сидя и стоя), или столы с изменяемой высотой;

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

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

• не менее двух мониторов на каждой станции.

Командам, работающим в групповом программировании в режиме личного общения, тоже понадобятся специальные рабочие станции (см. раздел «Групповое программирование» главы 12):

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

• кресло «водителя» – с удобным доступом, мышью, клавиатурой и компьютером уровня разработки;

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

• не менее одного монитора, обычно с диагональю от 60 дюймов, достаточно большого, чтобы его было видно со всех мест. Телевизоры с разрешением 4K тоже вполне пригодны для этой цели. Убедитесь, что всех все устраивает с учетом разницы в зрении.

Не покупайте программное обеспечение для управления жизненным циклом Agile или другие системы отслеживания, если команда не просит именно его, и даже если просит, подождите, пока члены команды сначала наберутся опыта, несколько месяцев работая с практиками планирования, представленными в этой книге. Больше информации можно найти в подразделе «Корпоративные системы отслеживания» главы 10.

Примеры командных помещений

Схема рабочего пространства, представленная на рис. 7.1, основана на командных помещениях, которые я видел в штаб-квартире Spotify в 2015 году. Каждое помещение имело рабочую зону со множеством белых досок, зону для общения и комнату для частных разговоров, вмещающую от трех до пяти человек. За пределами помещения был широкий коридор с уютными диванами и креслами и вешалка для верхней одежды.

Рис. 7.1. План командного помещения, вдохновленный Spotify

Командные помещения Spotify были лучшими из тех, что я видел, но, по словам людей, с которыми я разговаривал, и они имели ряд недостатков. Перегородка между рабочими комнатами команды и коридором изначально должна была быть стеклянной, но вместо этого ее сделали своего рода сетью (видимо, вследствие требований пожарной безопасности), из-за чего шум разговоров в коридоре мешал команде. Кроме того, планировке комнат не хватало гибкости: Spotify имел комнаты разного размера для команд разной численности, но людям не нравилось переезжать из комнаты в комнату, когда команды увеличивались или, наоборот, уменьшались.

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

Рис. 7.2. План бюджетного командного помещения

Это было отличное пространство с одним серьезным недостатком: перегородкой между программистами и продакт-менеджером. (На рисунке я ее удалил.) В результате продакт-менеджер сидел снаружи комнаты и не мог слышать членов команды и участвовать в общих дискуссиях. Команда не получала своевременных ответов на вопросы и часто имела проблемы с требованиями по продукту.

Адаптация к физической командной комнате

Многие люди могут сопротивляться переезду в общую командную комнату. Они обычно опасаются потерять индивидуальность и приватность, предполагаемого понижения статуса из-за потери собственного кабинета и того, что руководители не будут замечать индивидуального вклада.

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

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

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