• У деяких компаніях Кремнієвої долини вважається, що програмісту не обов'язково мати окремий комп'ютер для того, щоб писати код. Це компанії, які взяли на озброєння парне програмування - оригінальний метод організації робочого процесу, при якому над одним і тим самим кодом працюють два співробітника. Незважаючи на те, що метод істотно прискорює процес розробки, багатьом програмістам він незручний чисто з людської точки зору - не кожному розробнику до вподоби, коли у нього «стоять над душею».
    Основне призначення парного програмування полягає в тому, щоб підвищити швидкість розробки програмних продуктів, які вимагають швидкого випуску та виправлення. Двоє розробників ділять між собою один стіл і один комп'ютер. Один із співробітників є «провідним»: він працює на клавіатурі і безпосередньо пише код програми. Тим часом другий співробітник, «штурман», стежить за екраном і перевіряє код на наявність помилок або невірних рішень в дизайні.
    Витоки популярності парного програмування треба шукати в 1999 р., коли в світ вийшла відома книга Кента Бека (Kent Beck) «Екстремальне програмування». Кент Бек розробив основні положення методу в 1980-х, працюючи над софтверним проектом спільно з Уордом Каннингемом (Опіка Cunningham), творцем першої wiki. Все почалося з того, що Бек попросив Каннінгема перевірити свій код на помилки. Поступово між двома розробниками встановилося глибоке співпрацю, і вони почали працювати в парі, щоб швидше виконувати завдання і тим самим вивільняти час на реалізацію аматорських проектів.
    Парне програмування об'єднує
    Бека, парне програмування об'єднує співробітників настільки, що вони починають мислити в одному ключі. «Комунікація стає настільки глибоким, що вам більше не потрібно використовувати слова, - запевняє Бек, який зараз працює в Facebook. - Досить хмыкнуть і ткнути пальцем в екран». Крім того, метод дозволяє вчасно виявити дорогі помилки програмного забезпечення. І підвищує дисципліну - в парі співробітники не відволікаються на веб-серфінг.
    нині практика парного програмування процвітає. Метод знайшов шанувальників в офісах таких технологічних компаній, як Facebook або сервіс мобільних платежів Square. Square, що базується в Сан-Франциско, стверджує, що принаймні 15% з її програмістів повний день працює в парах. Половина співробітників вдається до методу час від часу - тим більше що їм дозволено вибирати, коли і з ким співпрацювати.
    Pivotal Labs, лабораторія розробки програмного забезпечення, в березні поточного року стала частиною технологічного гіганта EMC, стверджує, що 175 її інженерів працюють в парах щодня. Деякі співпрацюють на постійній основі, інші ж вважають за краще постійно міняти партнерів, що серед співробітників компанії жартома зветься «безладним спарюванням». Є й інші форми парного програмування - наприклад, партнерство в стилі «пінг-понг», коли партнери «перекидають» один одному завдання. Ще один варіант - парне програмування на удаленной основе: один співробітник надає другого доступ до свого екрана комп'ютера через інтернет.
    Побачення наосліп
    Добре, якщо співробітники знаходять один одного споріднену душу, працюючи в парі. Однак на практиці парне програмування нерідко нагадує не дуже вдале побачення наосліп. Уїлл Сарджент (Will Sargent), колишній інженер Grockit, інтернет-компанії з Сан-Франциско, ділиться невдалим випадком зі своєї практики: одного разу йому довелося працювати в парі з розробником набагато досвідченіше себе. Коли Сарджент, колишній в парі «провідним», робив помилку, його партнер просто забирав у нього клавіатуру і робив все по-своєму. «Той рівень, на якому він працював, був для мене недосяжний», - згадує Сарджент, який залишив компанію в 2010 р.
    Генеральний директор Grockit Рой Гілберт (Roy Gilbert), тим не менш, заявляє, що практика парного програмування довела свій успіх. «Наші розробники продовжують проповідувати цей метод», - стверджує президент компанії.
    Головний ворог парного програмування - людські звички. Брайан Кокол (Brian Kocol), технічний директор Drive Current, ІТ-консалтингової компанії з програмного забезпечення, згадує одного зі своїх інженерів, який мав звичай вимовляти вголос всі свої дії над кодом. «Деякі люди мають незручні звички - наприклад, розмовляють самі з собою, - зауважує він. - Інших співробітників це зводить з розуму». Дратувати може що завгодно: недолік особистої гігієни, невміння вести себе за столом, звичка класти ноги на стіл або плямкати.
    На відміну від Grockit, Drive Current встала на бік співробітників, яким парне програмування не по душі. Після двох років експерименту, коли розробників просили за три години у день працювати в парі, компанія припинила цю практику. «Не думаю, що хтось з нею дуже сумує», - уїдливо зауважує Йон Сент Джон (Jon St. John), один з програмістів компанії, якому теж дістався дуже досвідчений і допитливий «штурман».
    З іншого боку, деякі співробітники, що мають проблеми з партнером по програмуванню, прагнуть вирішити їх самостійно. Джеймі Каррагер (Jamie Kite), програміст з нью-йоркської консалтингової компанії Relevance, зіткнувшись з взаимонепониманием, викликала партнера на відверту розмову. Щоб розібратися в ситуації, їм довелося виписати свої проблеми і думки щодо їх вирішення на дошці, проте, врешті-решт, компроміс був знайдений.
    «Так буває в будь-яких відносинах, - пояснює Він. - Якщо про проблему не говорити, то і співпраці не вийде».
    Relevance, де парне програмування застосовується дуже активно, існує спеціальна посада «тренера», який допомагає заплутався партнерам прийти до розуміння. Марк Філіпс (Mark Philips), один з тренерів компанії, порівнює парне програмування з сімейним життям. «Люди, які якесь час попрацювали в парі, починають поводитися як схильні до чвар дружини», - іронічно помічає Філіпс.