Вместе мы – сила

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

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

Умение работать в команде – важное качество высококвалифицированного разработчика программного обеспечения.

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

Команды – общий взгляд

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

Оба метода работы знают как крупные успехи, так и крупные прова% лы. В качестве успешных разработок для обоих лагерей можно при% вести IBM OS/360 и ядро Linux соответственно. Легендарной неудачей стал запуск Ariane 5; эта ракета%носитель, совместно разрабатываемая европейскими странами, взорвалась при первом запуске из%за того, что две команды разработчиков неправильно поняли формально опре% деленный интерфейс. В области открытого программного обеспечения любопытным провалом стала Mozilla; когда Netscape сделала откры%

тым свой код, предполагалось, что он начнет быстро разрабатываться дальше и совершенствоваться. Последующие годы развития Mozilla принесли большое разочарование в сравнении с другими проектами open source.

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

•Вы создаете отдельный программный компонент, входящий в более крупный проект. Его разработку вы ведете самостоятельно или в со% ставе группы программистов; это первая команда.

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

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

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

Рис. 17.1. Уровни групповой работы