Групповая разработка и организация

Терехов Андрей Николаевич, Интернет-Университет Информационных Технологий, INTUIT.ru

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

Process model имеет три основные особенности: разбиение всего процесса на фазы;введение опорных точек;итеративность.

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

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

Envisioning – выработка единого понимания проекта всеми членами коллектива. Эта фаза заканчивается разработкой формализованного документа: problem statement — описание задачи объемом не более одной страницы;vision statement — от чего хотим уйти, чего хотим добиться;solution concept — что хотим внедрить и как; user profiles — кто будет этим пользоваться;business goals — возврат инвестиций;design goals — конкретные цели и ограничения продукта, его конкретные свойства.

Planning — планирование очередного цикла разработки: функциональные спецификации;план-график работ;оценка рисков.

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

Stabilizing — создание стабильной версии, готовой к использованию.

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

Каждая фаза процесса разработки завершается главной опорной точкой (major milestone). Характеризующие ее результаты видны не только коллективу разработчиков, но и заказчику. Главная опорная точка – это момент, когда все члены коллектива синхронизируют полученные результаты. Назначение таких точек в том, что они позволяют оценить жизнеспособность проекта. После анализа результатов коллектив разработчиков и заказчик совместно решают, можно ли переходить на следующую фазу. Таким образом, главные опорные точки – это критерии перехода с одной фазы проекта на другую.

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

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

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

Терехов Андрей Николаевич, Интернет-Университет Информационных Технологий, INTUIT.ru

Групповая разработка, управление версиями

Один из департаментов нашего коллектива разрабатывает ПО телефонных станций, которое включает в себя следующие компоненты: ОС реального времени;драйверы телефонного оборудования;функциональное ПО;программы рабочих мест операторов (РМО);БД конкретного экземпляра АТС.

Каждый компонент разрабатывается отдельным коллективом разработчиков, но все компоненты тесно связаны друг с другом. Более того, каждый компонент (кроме, пожалуй, драйверов) состоит из большого числа модулей, разрабатываемых разными специалистами. Таким образом, налицо проблема взаимодействия большого количества разработчиков, каждый из которых может находиться в своей фазе разработки, может внести в свою программу такие изменения, которые не позволят другому разработчику отлаживать его программу и т.д. К сожалению, и в нашем коллективе, в котором слово "технология" царит уже более 20 лет, нередки случаи, когда при выезде на объект БД не соответствует ФПО или версия РМО уже устарела. Наша техническая вооруженность позволяет быстро справляться с этими трудностями, но свести проблемы к нулю можно лишь жесткими организационными мерами, прежде всего, требуется преодолеть многие советские привычки и особенности нашего менталитета.

Еще 20 лет назад у нас в коллективе сложилась трехуровневая система версий, которая в том или ином виде актуальна до сих пор. Разработчик действует в своем файловом пространстве (раньше мы говорили "библиотека разработчика"), делает там, что хочет, и ни с кем ничего не согласовывает. Когда группа разработчиков решает, что какие-то модули отлажены (или когда их руководитель решает, что ждать больше нельзя, cроки поджимают), исходные тексты модулей передаются в библиотеку тестирования. Система или какой-то ее компонент проверяется на всех существующих тестах, причем библиотека тестирования остается фиксированной, все найденные ошибки заносятся в базу данных ошибок и исправляются в библиотеках разработчиков. Когда все тесты пропущены, библиотека тестирования вместе со списком найденных ошибок копируется в библиотеку предъявления, а библиотека тестирования готова к приему новой версии из библиотек разработчиков.

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

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

Описанная выше трехуровневая система версий является слишком крупноблочной. В современных технологиях используются специальные инструментальные средства, позволяющие фиксировать каждое изменение и откатываться к нужной точке, например, Visual Source Safe или PVCS. Обычно такие системы версионирования устанавливаются на сервере, разработчики играют роль клиентов (тем самым автоматически решаются технические проблемы, например, разрешение конфликтов при одновременном обращении, вопросы back-up и др.), а система предоставляет следующие методы: Check-out: взять текст на исправление;Check-in: вернуть обратно;Undo check-in: отмена всех изменений, сделанных во время последней сессии;Get latest version: берется один файл или файлы целого проекта в том состоянии, в котором их застал последний check-in.

Последняя версия обычно хранится отдельно.

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

Насколько хорошо у нас поставлена система версионного контроля, как-то раз я убедился лично. Однажды поздно вечером я зашел за своей женой, которая также работает на нашем предприятии, и говорю: "Пошли домой, устал до смерти, больше не могу работать". Она мне: "Пока check-in не сделаю, уйти не могу, иначе меня завтра ждут большие неприятности". Это меня позабавило – я же генеральный директор, какие могут быть неприятности, если я сам о чем-то прошу? Она мне спокойно объясняет, что в данном случае никакой роли не играет, кто я и кто она. Каждую ночь у нас идет автоматическая сборка разрабатываемого продукта, затем автоматическое тестирование. Сборка начинается с перетрансляции абсолютно всех модулей (чтобы исходные тексты не разошлись с объектными модулями). Если в текстах есть формальные ошибки, трансляция завершится с аварийным кодом возврата, сборка выполняться не будет, а утром как виноватые исполнители, так и их руководители получат автоматически сгенерированные сообщения с исчерпывающим объяснением ситуации. Это какой-то страшный бездушный молох, машина, в которую даже генеральный директор влезть не может.

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

Организация коллектива разработчиков

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

Проблема интерфейсов – главная проблема в организации коллектива. Если есть n сотрудников, то имеется Cn2 = n*(n-1)/2 парных интерфейсов, а ведь иногда надо обсудить проблему и втроем, и вчетвером. Таким образом, с ростом коллектива быстро растет количество интерфейсов внутри него, при каждом взаимодействии могут возникнуть споры, непонимание, разночтение и другие конфликты. Как же с этим бороться?

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

Основная идея состоит в построении иерархии подчиненности. Есть руководитель темы или отдела, у него в подчинении несколько руководителей групп, у каждого руководителя группы в подчинении несколько специалистов. Разумеется, уровней иерархии может быть и 2, и 3, и 4, но все-таки не 15 и не 20. Каждый руководитель должен сформулировать задачу своим подчиненным так, чтобы минимизировать интерфейсы между ними, т.е. максимально локализовать решаемые ими задачи. Это не всегда возможно, не у всех руководителей получается, но так и различаются руководители и их команды.

В незапамятные времена многие верили в закон Конвея: "Каждая система структурно подобна коллективу, ее разработавшему". В 1976 году мне пришлось довольно долго беседовать с руководителем разработки трансляторов с языка ПЛ1 для IBM/360 по фамилии Маркс. Родился он в тот же год, что и я, закончил университет тогда же, когда и я, занимался очень похожей работой (в то время я был одним из руководителей разработки транслятора с языка Алгол 68), в общем, нам было интересно побеседовать. Я его спросил: "Почему РL1/F имеет 51 просмотр, когда с Алголом 68 мы справляемся за 6?". Он отвечает: "А что тут понимать, у меня в подчинении был 51 программист. К тому времени, когда мы начали реализовывать оптимизирующий транслятор с ПЛ1, у меня было 100 человек, поэтому PL1/ opt имеет 100 просмотров". Я и тогда понимал, что это глупо. Между каждой парой просмотров нужно организовывать файл на промежуточном языке; один просмотр – пишет, другой – читает, добавьте разные упаковки и распаковки, другие служебные действия – и вы поймете, почему трансляторы с ПЛ1 работали так медленно.

Но не все так просто в этом мире. Мы делали транслятор чуть ли не 10 лет, а они "слепили" свой транслятор за два года. Тот же Маркс позавидовал мне, что у нас есть такая замечательная возможность заниматься любимой наукой, не торопясь, исследовать разные варианты, придумывать новые методы, публиковать монографии и т.д. C понятием рынка ПО в те годы мы были совершенно не знакомы, да и сейчас, через 30 лет, далеко не все наши программисты понимают законы рынка: как важно первым выдать на рынок пусть не самый лучший, но работающий продукт, соответствующий определенным потребностям рынка. Таким образом, если вы проектируете систему в соответствии с законом Конвея и при этом вам легче уложиться в сроки и средства, значит, так и нужно, а всякие изыски оставьте университетским "яйцеголовым" (так в Америке обзывают нас и наших коллег из университетов всего мира).

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

Итак, пусть у нас есть n специалистов и m однотипных заказов. Строим матрицу из n строк и m столбцов. Элемент в i-ой строке из j-ого столбца обозначает работу i-ого специалиста для j-ого заказа. Например, один специалист хорошо делает синтаксические анализаторы, другой – оптимизаторы, третий – генераторы и т.д., а однотипные заказы – это трансляторы с разных языков для разных платформ. Тем самым каждый специалист подчинен двум руководителям – административному (он же принадлежит какой-то группе, отделу) и руководителю проекта, в котором он принимает участие в данный момент.

У матричного метода есть свои плюсы и минусы. С одной стороны, узкая специализация по конкретной теме позволяет надежнее планировать сроки, добиться той самой повторяемости результатов, которой требует CММ уровня 2. С другой стороны, нарушен принцип единоначалия (как когда-то в Красной Армии были командиры и комиссары, причем с одинаковыми правами и ответственностью; жизнь быстро доказала неправильность такого решения). Часто возникает ситуация, когда руководителю проекта нужен какой-то конкретный специалист, а начальник отдела загрузил его работой для другого заказа.

Есть и еще один недостаток матричного метода, не столь очевидный. Конечно, занимаясь годами одним и тем же, специалист оттачивает свое мастерство, но в целом он ограничен, не расширяет свой кругозор и т.п. "Специалист подобен флюсу – полнота его односторонняя". Предположим, некий сотрудник института много лет успешно занимался темой Х, а по прошествии какого-то времени тема Х перестала быть актуальной (такое в нашей науке бывает очень часто). И что он будет делать?

У Брукса описана совершенно другая модель организации коллектива – бригада главного хирурга. Сложные операции всегда делает один человек – главный хирург, но ему помогает целая бригада – кто-то делает надрезы, а потом зашивает, кто-то подает инструменты, следит за показаниями приборов и т.д. Примерно такой же схемой воспользовались Миллз и его коллеги для разработки информационной системы газеты "Нью-Йорк Таймс".

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

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

Эта модель организации коллектива не нашла широкого применения. Во-первых, ее трудно масштабировать. Сколько строк исходного кода может написать один программист? Ну, 50 тысяч, ну, скажем, 100. А если нужно миллион строк? Тогда все проблемы интерфейсов возвращаются, да еще на более сложном уровне, поскольку двум главным программистам договориться гораздо труднее, чем двум рядовым. Во-вторых (или все-таки во-первых?), где вы найдете множество программистов, готовых безропотно подчиняться главному программисту? Наша специальность подразумевает наличие твердого характера, творческого начала, гордости за свое детище.

Организация коллектива разработчиков в компании Microsoft

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

Служба Microsoft Consulting Services провела анализ результатов выполнения большого количества программных проектов. Оказалось, что только 24% проектов можно признать в той или иной степени успешными, 26% не были завершены, а остальные столкнулись с большими проблемами, например, бюджет был превышен вдвое или затрачено в 1,5 раза больше времени.

Основными причинами неудач были признаны следующие: постоянное изменение требований;нечеткие или неполные спецификации;низкое качество кода;слишком широкая постановка задачи;ошибка в подборе кадров;плохая организация работы;нечетко сформулированные цели.

Для преодоления этих трудностей был предложен набор моделей Мicrosoft Solution Framework (MSF), в котором учтен опыт, накопленный группами разработки программных продуктов.

Самыми революционными оказались модель команды разработчиков и модель процесса разработки. Первая модель (team model) описывает, как должны быть организованы коллективы и какими принципами им надо руководствоваться для достижения успеха в разработке программ. Разные коллективы могут по-своему применять на практике различные элементы этой модели – все зависит от масштаба проекта, размера коллектива и квалификации его участников.

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

Этот "бублик" описывает только роли, за ними могут скрываться несколько человек, исполняющих каждую роль. Самое удивительное, что в этой модели не предусмотрено единоначалия – все роли важны, все роли равноправны, поэтому MSF называют моделью равных (team of peers).

Program management – управление программой. Исполнитель этой роли отвечает за организацию (но не руководит!): осуществляет ведение графика работ, утренние 15-минутные совещания, обеспечивает соответствие стандартам и спецификациям, фиксацию нарушений, написание технической документации.

Product management – управление продуктом. Исполнители этой роли отвечают за общение с заказчиком, написание спецификации, разъяснение задач разработчикам.

Development – наиболее традиционная роль – разработка и начальное тестирование продукта.

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

Logistic management – установка, сопровождение и техническая поддержка продукта, а также материально-техническое обеспечение работы коллектива.

Testing – тестирование. Выявление и устранение недоработок, исправление ошибок, другие функции QA.

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

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

Модель процесса определяет, когда и какие работы должны быть выполнены.

Психология программирования

В первый раз я столкнулся со специалистами по инженерной психологии в 1968 году. На мат-мехе была установлена польская ЭВМ ODRA 1204 с хорошей операционной системой и достаточно полной реализацией Алгола 60. На этой ЭВМ мы впервые получили возможность посимвольного ввода/вывода информации, используя телетайп или перфоленту. До этого мы могли работать только с целой колодой перфокарт или с целой перфолентой. Мы реализовали один из первых в СССР (и уж точно – первый в нашем университете) диалоговый корректор текстов (программа dico ). Г.С. Цейтин придумал идею и показал примеры основных операций, я написал на Алголе 60 почти все программы, а С.Н. Баранов подготовил хорошую документацию. Программа быстро стала популярной, после чего Александр Марьяненко (сотрудник института комплексных социальных исследований) попросил разрешения провести некоторые психологические исследования проблем диалогового редактора. Мы, разумеется, согласились, хотя совершенно не верили, что это принесет пользу. Как оказалось – зря не верили. Симпатичная дипломница А. Марьяненко провела 2-3 месяца, наблюдая за нашей работой. Она была тихой и незаметной, мы ее присутствия практически не ощущали. Зато после этого она выдала целый ряд наблюдений и рекомендаций, оказавшихся очень ценными. Например, она заметила, что некоторые часто встречающиеся вместе команды кодируются символами в разных регистрах, из-за чего оператор вынужден чаще нажимать на клавиши, а некоторые команды были названы неудачно, что провоцировало пользователей на ошибки. Но больше всего мы удивились, когда она заметила, что отладка модуля размером в одну страницу может быть не на проценты, а в разы проще отладки модуля размером в одну страницу и еще 4-5 строк на другой странице.

Оказалось, что это связано с принципами организации человеческой памяти. Есть сверхоперативная память, связанная, в основном, со зрением. Эта память имеет очень быстрый доступ, но очень мала – 7-9 позиций. (Говорят, что у профессиональных программистов эта память имеет 20-25 позиций.)

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

С устройством памяти связан принцип "центрального" (в отличие от "периферического") зрения. Человек хорошо воспринимает какую-то точку и то, что ее окружает.

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

Еще один важный принцип инженерной психологии также связан с устройством человеческой памяти – принцип возможно раннего обнаружения ошибок. Если программист написал программу и тут же заметил ошибку, то ее исправить сравнительно просто. Если же ему сообщают о найденной ошибке через полгода, ее исправление превращается в проблему. Именно по этой причине мы являемся сторонниками статических АЯВУ (в которых транслятор в каждой точке программы "знает" виды обрабатываемых значений), а не динамических, в которых типы данных определяются во время счета. В динамических языках простое несовпадение типов может обнаружиться и через полгода, когда сложится "нужное расположение звезд на небе". Словом, в инженерную психологию как в науку мы поверили. Поэтому, когда тот же А. Марьяненко несколькими годами позже предложил провести психологическое обследование нашей лаборатории системного программирования, мы согласились. Поводом послужил тот факт, что в этот момент я оказался самым молодым руководителем лаборатории ЛГУ, и психологам было интересно исследовать взаимоотношения молодого руководителя с его старшими коллегами.

Нам раздали анкеты со множеством странных вопросов типа: "Как ты думаешь, что скажет о тебе такой-то сотрудник?". Содержание каждой анкеты не раскрывалось (таковы правила социологических опросов), но суммарные результаты, полученные, кстати, на ЭВМ (!) нам были представлены. Результаты были интересные, содержательные, многие рекомендации мы использовали. Но один факт меня просто поразил. А. Марьяненко предсказал мне, что два сотрудника не более чем через полгода лабораторию покинут. Как же так? Я же их учил, играл с ними в баскетбол, мы вместе решали трудные задачи, никогда ни одного плохого слова я от них не слышал. Я тогда промолчал о предсказании: если это ошибка, то зачем травмировать хороших людей, а если правда, то что тут поделаешь. Через полгода они ушли с громким скандалом, написав бумагу, в которой обвинили меня во всех смертных грехах. Я был потрясен, но не их уходом, а сбывшимся предсказанием.

Я стал читать книги по психологии, это оказалось не так интересно для математика, но какие-то принципы я запомнил.

Многое в поведении людей объясняет пирамида Маслова :

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

Любой человек принадлежит к одному из трех типов:

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

Технарь. Человек, который получает настоящее удовольствие от самого процесса поиска решения, например, программирования, которому по большому счету наплевать, что есть начальники и подчиненные, что о нем не пишут газеты и т.д. Главное – решить задачу.

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

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

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

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

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