По прибытии я обнаружил удручающую картину: у Билла не было никакой команды разработчиков. У него было шесть талантливых, хорошо подготовленных сотрудников, которые не могли вместе работать. Они даже сидели поодаль друг от друга. Ясно было, что особых симпатий между ними пока не возникло.
      "Давайте поговорим о парном программировании. (далее перечисляются все его преимущества). ‹пауза› Парное программирование вводится теперь в обязательном порядке. Весь программный код должен быть написан при участии второго партнера".
      ‹Неловкое молчание. Люди обмениваются неприязненными взглядами›
      "Не думаю, что это сработает. Вот, например, что будет, если мне нужно писать код, а партнера нет рядом?"
      "Тогда найди кого-нибудь еще. Главная цель - работать вместе, чтобы передавать друг другу знания".
      "А если рядом никого не окажется?"
      "Тогда позови меня, я с удовольствием с тобой поработаю. Если же ты и в самом деле не можешь найти ни одного партнера, чтобы писать код вместе, тогда отложи клавиатуру и отдохни."
      ‹Все удивленно смотрят на меня. Гробовая тишина. ›
      Несколько раз парное программирование прошло довольно гладко. Иногда, правда, что-то не получалось. Общались разработчики вяло и редко. Я изо всех сил старался помочь ребятам - старался приучить их думать вслух (то, что Уорд Каннингэм называл рефлективной артикуляцией). И это решило дело! Программисты действительно стали вместе работать, а не просто писать код для одной системы.
      Уже через неделю я начал подмечать существенные изменения в поведении разработчиков. Они начали разговаривать друг с другом. Совершенно нормально, так как говорят между собой обычные люди. Нужно было видеть их в начале проекта, чтобы понять, как сильно изменилось их отношение друг к другу. Они беседовали, шутили, смеялись. Теперь уже они начали понимать, что такое доверять друг другу и получать удовольствие от совместной работы.
      Еще через несколько дней эти разработчики превратились в отличную слаженную команду."
      [из архивов Алистэра Коуберна]
      Несмотря на то, что книги "Психология программирования" ("The Psychology of Computer Programming") и "Кадровое обеспечение" ("Peopleware") были написаны, соответственно, 20 и 30 лет тому назад, никто до сих пор не написал ничего лучшего о командной работе. Уже в наши дни формированию команды и коммуникациям стали уделять внимание новые методологии - eXtreme Programming , семейство Crystal [15] и Adaptive Software Engineering [16]. В статье "Characterizing People as Non-Linear, First-Order Components in Software Development" (Русский перевод: , Алистэр Коуберн вообще ставит человеческий фактор в деле разработки ПО на первое место, утверждая, что это вовсе не второстепенный вопрос, как принято считать.
      Таким образом, парное программирование выгодно по трем основным причинам.
      Как вы уже поняли из приведенного выше рассказа, люди учатся работать вместе. Во время эксперимента в университете Юта ни одна из 14 пар программистов не столкнулась с непреодолимыми препятствиями психологического толка. Впрочем, со слов тех, кто пытается практиковать парное программирование во время реальной работы над проектом, такие проблемы все же случаются (возможно, сказывается слабое воздействие на программистов или недостаток мотивации к совместной работе). Опросы тех разработчиков, которые сумели преодолеть трудности, показывают, что изложенный выше сценарий срабатывает довольно часто (может быть, разве что не в столь ярко выраженной форме). Зачастую люди могут научиться работать вместе только после того, как начнут это делать.
      Научиться работать вместе - значит научиться более быстро решать вместе со своими коллегами различные проблемы, а не скрывать друг от друга свои мысли и идеи. В этом случае заметно совершенствуется командный стиль работы.
      Если пара программистов сумеет сработаться, то им будет гораздо легче общаться. Кроме того, это общение будет протекать гораздо чаще. При увеличении объема и частоты коммуникаций увеличивается и общий поток информации, циркулирующий внутри команды. Чтобы усилить и ускорить этот процесс, нужно не забывать менять партнеров в парах.
      Похоже, все это существенно улучшает производительность команды. К сожалению, эти выводы основываются только на рассказах самих программистов. Никаких статистических данных на этот счет у нас пока нет.

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

      Основные преимущества парного программирования заключаются в следующем:
      большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (QA) или же во время работы клиента с системой (см. непрерывная проверка кода);
      заметно снижается общий коэффициент ошибок, что подтверждается статистическими данными (см. непрерывная проверка кода);
      готовый продукт имеет лучший дизайн и меньший объем программного кода (см. "мозговой штурм" и принцип "парной эстафеты");
      команда быстрее справляется с возникающими проблемами (см. принцип "парной эстафеты");
      разработчики гораздо больше узнают как о системе, так и самом процессе разработки ПО (см. обучение в поле зрения учителя);
      к моменту окончания проекта множество людей обладает глубокими знаниями о каждой из его частей;
      люди учатся совместной работе и общению, что приводит к увеличению потока информации внутри команды и положительно влияет на ее динамику;
      люди испытывают больше удовольствия от своей работы.
      При этом увеличение стоимости разработки при парном программировании составляет вовсе не 100%, как можно было бы ожидать, а приблизительно 15%, что легко окупается за счет более высокого качества программного кода (а значит, меньших затрат на тестирование и поддержку).

      1. Salomon, G., Distributed Cognitions: Psychological and educational considerations. Learning in doing: Social, cognitive, and computational perspectives, ed. R. Pea and J.S. Brown. 1993, Cambridge: Cambridge University Press.
      2. Constantine, L.L., Constantine on Peopleware. Yourdon Press Computing Series, ed. E. Yourdon. 1995, Englewood Cliffs, NJ: Yourdon Press.
      3. Beck, K., Extreme Programming Explained: Embrace Change. 2000, Reading, Massachusetts: Addison-Wesley.
      4. Williams, L., et al., Strengthening the Case for Pair-Programming, in IEEE Software. submitted to IEEE Software. Online at www.cs.edu/~lwilliam/Papers/ieeeSoftware.PDF
      5. Williams, L.A. and R.R. Kessler. The Collaborative Software Process. in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland. Online at www.cs.edu/~lwilliam/Papers/ICSE.pdf
      6. Nosek, J.T., The Case for Collaborative Programming, in Communications of the ACM. 1998. p. 105-108.
      7. Humphrey, W.S., A Discipline for Software Engineering. SEI Series in Software Engineering, ed. P. Freeman, Musa, John. 1995: Addison Wesley Longman, Inc.
      8. Humphrey, W.S., Introduction to the Personal Software Process. 1997: Addison-Wesley.
      9. Flor, N.V. and E.L. Hutchins. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. in Empirical Studies of Programmers: Fourth Workshop. 1991: Ablex Publishing Corporation.
      10. Fagan, M.E., Advances in software inspections to reduce errors in program development. IBM Systems Journal, 1976. 15: p. 182-211.
      11. Johnson, P.M., Reengineering Inspection: The Future of Formal Technical Review, in Communications of the ACM. 1998. p. 49-52.
      12. Lave, J. and E. Wenger, Situated Learning: Legitimate peripheral participation. 1991, New York, NY: Cambridge University Press.
      13. Weinberg, G.M., The Psychology of Computer Programming Silver Anniversary Edition. 1998, New York: Dorset House Publishing.
      14. DeMarco, T. and T. Lister, Peopleware. 1977, New York: Dorset House Publishers.
      15. Cockburn, A., Crystal "Clear": A human-powered software development methodology for small teams, Addison-Wesley, 2001, in preparation. Online at http://members.aol.com/humansandt/crystal/clear
      16. Highsmith, J., Adaptive Software Development, Dorset House, 1999.
      17. Cockburn, A., Characterizing People as Non-Linear, First-Order Components in Software Development, in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland… Online as Humans and Technology Technical Report, TR 99.05, http://members.aol.com/humansandt/ papers/ nonlinear/nonlinear.htm. (На русском языке: );

      (полную версию смотрите на http://c2.com/cgi/wiki?ExpertInEarshot)
 
 
      Неопытным программистам довольно сложно самостоятельно научиться хорошо работать, поэтому…
      Около них (в пределах слышимости) должен находиться высококлассный специалист в данной области.
 

Показания

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

Противопоказания

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

Цели и задачи

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

Сделайте следующее

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

Эффект передозировки

 
      (1) Чрезмерное обилие вопросов существенно снизит производительность специалиста.
      (2) Если в одной комнате собрать слишком много переговаривающихся между собой людей, в такой обстановке будет трудно сконцентрироваться.
       См. также
       Паттерн "Обучение:Дневная няня" (Training:Day Care)предлагает следующее: "Если ваши специалисты проводят слишком много времени за обучением новичков, то … каждый день назначайте одного "ответственного" за всех новичков, а остальные спецы будут в это время спокойно работать. [CoSOOP]. Это может также быть решением в ситуации, когда специалист пытается обучать новичков во время проектирования системы. В паттерне "Специалист в пределах слышимости" (Expert In Earshot), профессионалы не отвечают за обучение новичков. В этой ситуации само окружение позволяет новичку получать необходимые знания, наблюдая за тем, как работает специалист.
      Паттерн "Парное программирование" (Pair Programming) не противоречит принципам паттерна "Специалист в пределах слышимости". Таким образом, специалист оказывается в пределах слышимости только своего партнера-новичка (если они работают в одной паре), или же всех остальных коллег, которые работают с ним в одном помещении.
       Примеры
      (1) Когда Томас Дж. Уотсон Младший, бывший главный администратор компании IBM, сменил жизнь авиатора и плэйбоя на карьеру в серьезном бизнесе, его отец, исполнявший тогда обязанности главного администратора в этой компании, распорядился, чтобы тот провел полгода, сидя сбоку у стола одного из старших руководителей. Целых шесть месяцев единственным занятием молодого человека было смотреть и слушать, как этот высококлассный профессионал выполнял свою ежедневную работу, как он общался с людьми и т.д. Это несколько необычный, но зато очень яркий пример паттерна "Специалист в пределах слышимости".
      (2) Одному опытному программисту поручили команду из четырех новичков, для того чтобы они разработали графическую рабочую станцию. При этом для руководителя команды выделили отдельный офис. Через несколько недель он почувствовал, что работать отдельно от своей команды ему неудобно, поэтому он перенес свой стол в комнату, где работали четыре его младших программиста. Несмотря на то, что они постоянно его отвлекали (хотя он вовсе не собирался становиться для них штатным преподавателем), работа пошла успешнее, поскольку он мог в любой момент обсудить со своими разработчиками любой вопрос. Постепенно они приобрели необходимое мастерство и уже не так сильно мешали ему своими расспросами. К следующему проекту эта команда уже обладала всеми необходимыми навыками и умениями.
      (3) Старший программист работал в одной комнате с шестью новичками. У этого специалиста были две не очень хорошие привычки: во-первых, он не принимал всерьез идею правильного и аккуратного дизайна системы и, во-вторых, вместо того, чтобы объяснять своим неопытным коллегам, что такое хороший дизайн или программа, он просто по ночам переписывал их код. Утром, приходя на работу, эти шестеро никогда не знали, осталась ли программа в прежнем виде или изменилась, и насколько. Через несколько месяцев все новички стали создавать не только плохой, но и неряшливый дизайн. Их идеалом стало высокомерное отношение к проектированию старшего программиста.
      Когда этот человек перестал работать над проектом, на его место пришел другой консультант. Теперь проектные решения всесторонне обсуждались, так чтобы все могли при желании услышать, о чем идет речь. Через несколько месяцев трое новичков начали рассуждать о проектировании и строить диаграммы, и вскоре овладели этим искусством так же хорошо, как и программированием.
 
      © Copyright 2000-2002, Alistair Cockburn ("Humans and Technology" Technical Report)
      © Copyright , перевод, 2002
 
      Глоссарий используемых терминов:
       = проверка кода
       = распределенное знание
       = поддержка продукта, уже находящегося в эксплуатации
       = парное программирование
       = парная эстафета
 
       Послесловие переводчиков :
      Опыт освоения парного программирования в отечественной софтверной компании описан в статье Романа Еремина