Алистэр Коуберн - Парное программирование: преимущества и недостатки

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

Очень эффективно совмещать технику "мозгового штурма" и парной эстафеты. Один из опытных программистов заметил:

Когда мне приходится снова работать в одиночку после того, как поработал в паре, мне кажется, что у меня отказала часть мозга. Я чувствую, что начинаю терять уверенность в том, что делаю.

Обучение

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

Обучение протекает в режиме "ученичества". Партнеры-программисты попеременно выполняют роли ученика и учителя. При этом они обмениваются даже навыками и привычками, которые невозможно передать на словах.

Обучение на визуальных примерах и его роль в ученичестве

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

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

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

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

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

Специалист в пределах слышимости (Expert In Earshot)

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

Использовать паттерн Специалист в пределах слышимости (Expert In Earshot) нужно тогда, когда вы замечаете, что программисты-новички, работающие в вашей команде, усваивают новые навыки не так хорошо, как хотелось бы. При этом вы не хотите, чтобы специалист в данном вопросе тратил все свое рабочее время на их обучение. В этом случае нужно поместить специалиста или руководителя команды в то помещение, где работают новички. Таким образом, молодежь будет наглядно обучаться тому, как работает профессионал. Наблюдая и прислушиваясь, новички приобретут манеру (будем надеяться, правильную) работы специалиста. (Понятно, что этого специалиста будут часто отвлекать, поэтому необходимо заранее позаботиться о том, чтобы у него было время и на спокойную, сосредоточенную работу).

Обратите внимание, как этот подход соотносится с исследованиями в области ученичества (см. выше). Важно отметить, что этот паттерн понравился всем 10 руководителям, и они собирались немедленно внедрить его в своих компаниях.

Парное программирование представляет собой сочетание паттерна Специалист в пределах слышимости (Expert In Earshot) и принципа периферийного участия ученика в серьезной и ответственной работе (когда он слышит и видит учителя). Следовательно, в случае с парным программированием мы вправе ожидать более значительных результатов, нежели просто обучение владению новым инструментарием или языком программирования. Эти ожидания подтверждаются сообщениями программистов, которые уже приняли на вооружение эту практику.

Данные статистики

Второй автор этой статьи использовал парное программирование во время преподавания курса web-программирования в университете Юта. Группа студентов состояла из 20 человек, имевших разный опыт программирования. Однако никто из них не знал ни языков web-программирования, ни инструментарий, который для этого используется. Опыт большей части студентов в этой области состоял лишь в применении WYSIWYG редакторов web-страниц. В течении 11 недель занятий студенты на хорошем уровне изучили язык HTML, JavaScript, VBScript, Active Server Page Scripting, Microsoft Access/SQL и некоторые команды ActiveX. Порой им приходилось совмещать операторы всех этих языков в одной программе.

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

74% написали, что выясняли все вопросы в процессе общения друг с другом.

84% согласились с утверждением: "Я смог изучить Active Server Pages быстрее и лучше, так как все время работал вдвоем с партнером".

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

Формирование команды amp;коммуникация

По прибытии я обнаружил удручающую картину: у Билла не было никакой команды разработчиков. У него было шесть талантливых, хорошо подготовленных сотрудников, которые не могли вместе работать. Они даже сидели поодаль друг от друга. Ясно было, что особых симпатий между ними пока не возникло.

"Давайте поговорим о парном программировании. (далее перечисляются все его преимущества). ‹пауза› Парное программирование вводится теперь в обязательном порядке. Весь программный код должен быть написан при участии второго партнера".

‹Неловкое молчание. Люди обмениваются неприязненными взглядами›

"Не думаю, что это сработает. Вот, например, что будет, если мне нужно писать код, а партнера нет рядом?"

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

"А если рядом никого не окажется?"

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

‹Все удивленно смотрят на меня. Гробовая тишина. ›

Несколько раз парное программирование прошло довольно гладко. Иногда, правда, что-то не получалось. Общались разработчики вяло и редко. Я изо всех сил старался помочь ребятам - старался приучить их думать вслух (то, что Уорд Каннингэм называл рефлективной артикуляцией). И это решило дело! Программисты действительно стали вместе работать, а не просто писать код для одной системы.

Уже через неделю я начал подмечать существенные изменения в поведении разработчиков. Они начали разговаривать друг с другом. Совершенно нормально, так как говорят между собой обычные люди. Нужно было видеть их в начале проекта, чтобы понять, как сильно изменилось их отношение друг к другу. Они беседовали, шутили, смеялись. Теперь уже они начали понимать, что такое доверять друг другу и получать удовольствие от совместной работы.

Еще через несколько дней эти разработчики превратились в отличную слаженную команду."