Я не собираюсь цитировать научные исследования, хотя у меня в запасе найдется немало подходящих цитат. Я не буду рассказывать «случаи из жизни», хотя и их у меня тоже предостаточно. Я даже не собираюсь указывать, какую часть времени следует проводить за парным программированием. Скажу одно –
Профессионалы также объединяются в пары, потому что это лучший способ обмена знаниями. Профессионалы не создают «банки знаний» – вместо этого они изучают разные аспекты системы и бизнеса, объединяясь в пары. Они понимают, что хотя у каждого участника группы имеется своя должность, все участники должны быть готовы моментально переключаться в случае необходимости.
Профессионалы объединяются в пары, потому что это лучший способ рецензирования кода. Ни в одной системе не должно быть кода, который не был прорецензирован другими программистами. Существует много механизмов рецензирования кода; в большинстве своем они ужасающе неэффективны. Самый эффективный и действенный способ рецензирования кода – участие в его написании.
Как работать мозжечком
Однажды утром на самом пике бума интернет-коммерции я приехал на поезде в Чикаго. Когда я ступил на платформу, мне в глаза бросился огромный плакат над выходом. Хорошо известная фирма-разработчик приглашала на работу программистов. На плакате было написано: «Поработайте мозжечком рядом с лучшими!»
Столь выдающаяся глупость меня поразила. Жалкие бестолковые рекламщики пытались произвести впечатление на умных, эрудированных, технически грамотных программистов – на людей, которые плохо переносят глупость. Рекламщики пытались создать впечатление, будто на новой работе вы будете обмениваться знаниями с другими умными людьми. К сожалению, упомянутая в рекламе часть мозга – мозжечок – отвечает за координацию движений, а не за интеллект. И те люди, которых пытались привлечь этой рекламой, только ухмылялись над глупой ошибкой.
Но в этой рекламе меня заинтриговало другое. Я представил себе группу людей, пытающихся «поработать мозжечком». Поскольку мозжечок находится в задней части мозга, я представил себе группу программистов, рассевшихся по кабинкам затылками друг к другу, уставившихся на мониторы и оградившихся от внешних раздражителей наушниками. Это нельзя назвать группой.
Профессионалы работают вместе. Невозможно работать вместе, рассевшись по углам с наушниками. Участники группы должны сидеть за общим столом, повернувшись друг к другу
Возможно, вам кажется, что в одиночку вы будете работать эффективнее. Даже если это и так, отсюда вовсе не следует, что
В одних ситуациях работа в одиночку – именно то, что нужно. Иногда вам просто нужно долго и напряженно думать над задачей. В других случаях задача настолько тривиальна, что привлекать к работе другого человека было бы попросту расточительно. Но в общем случае лучше выделять значительную часть времени на работу в тесном контакте с другими и парное программирование.
Заключение
Возможно, кто-то из нас пришел в программирование не для того, чтобы работать с людьми. Ему не повезло: все программирование неразрывно связано с работой с людьми. Мы должны общаться со стороной бизнеса, и мы должны общаться друг с другом.
Знаю, знаю: мы бы предпочли работать в закрытой комнате с шестью большими экранами, каналом T3, параллельным массивом сверхбыстрых процессоров, неограниченным объемом памяти и дискового пространства, а также бесконечным запасом диетической колы и острых кукурузных чипсов. Увы, так не будет. Если вы хотите заниматься программированием, придется научиться общаться.
13
Группы и проекты
Представьте, что вам нужно выполнить множество мелких проектов. Как распределить их между программистами? А если проект только один, но очень большой?
Формирование группы
За прошедшие годы я консультировал многие банки и страховые компании. Единственное, что у них было общего – странный подход к распределению проектов. Банковский проект часто представляет собой относительно малую задачу, которая может быть выполнена одним или двумя программистами за несколько недель. В проект обычно включался руководитель, который одновременно вел другие проекты. К нему добавлялся бизнес-аналитик, который предоставлял требования для других проектов. Дальше добавлялись программисты, которые также работали над другими проектами. Потом один-два тестера, у которых тоже были другие проекты.