Читаем Человеческий фактор в программировании полностью

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

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

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

Совместная работа и общение

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

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

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

Отдельная «ситуационная комната» достаточных размеров особенно важна для команд, которые ведут «архивирование системных документов» (Zahniser 1990 [71], 1993 [72]) и применяют другие методы группового анализа и разработки. Настенные доски командной штаб-квартиры становятся архивом групповой работы, ее видимой, внешней «групповой памятью», в которой хранятся важные элементы рабочего продукта и информация о процессе его создания. На стены командной штаб-квартиры можно поместить все, что угодно, начиная от командного флага и изложения целей проекта и заканчивая основными документами, связанными с разработкой. Само помещение и его оформление становятся частью командной культуры и способствуют тому, что каждая личность ощущает себя частью целого. Это помогает членам команды успешно и эффективно работать вместе.

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

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT