Як організувати роботу програмістів з максимальною ефективністю? Один із способів - парне програмування (pair programming), варіант методики гнучкого програмування (agile programming). У такого підходу є ряд переваг і недоліків. Тому інтерес представляє практичний досвід, яким з InformationWeek поділився розробник Філ Горовіц (Phil Horovitz) з компанії Perforce Software.
Згідно Wikipedia, парне програмування - техніка, при якій вихідний код створюється парами людей, що програмують одну задачу, сидячи за одним робочим місцем. Один з них ( «провідний») управляє комп'ютером і в основному думає над кодуванням в деталях, а інший ( «штурман») зосереджений на картині в цілому і безперервно переглядає код, вироблений першим програмістом. Час від часу вони міняються ролями.
Прихильники такого підходу вважають, що він дозволяє забезпечити більш високу якість коду за рахунок підвищення відповідальності розробників і безперервного тестування коду, підвищити продуктивність праці і поліпшити дисципліну, так як працюючи разом люди будуть менше відволікатися.
Головний аргумент проти полягає в підвищенні витрат. Навіщо платити двом програмістам за те, що може зробити один? Однак при цьому не береться до уваги аспект навчання. На думку Горовиця, можливість підвищити кваліфікацію, оволодіти новими навичками і є головною перевагою парного програмування.
Йому довелося скористатися цим методом в ході одного проекту, для якого потрібен був досвід розробки хмарного ПО, відсутній у співробітників Perforce Software. Консультанти з Pivotal Labs запропонували парне програмування. Була зібрана команда, що включає по чотири співробітника з кожної компанії, причому склад пар змінювався щодня, щоб люди могли отримувати різні навички.
За спостереженням Горовиця, єдина актуальна проблема полягала в тому, що хто-небудь переставав пояснювати свої дії і починав програмувати мовчки, не звертаючи уваги на партнера. Проблема швидко дозволялася без стороннього втручання. Бували звичайно і розбіжності, але вони як правило були конструктивними і вирішувалися шляхом обговорення.
Однак виявилося, що звикнути до такого стилю роботи нелегко. Наприклад, Горовицю для цього потрібна була тиждень, причому найважчим був перший день, після якого він насилу знайшов сили піти додому. Потім стало легше, але все одно учасники проекту відчували сильну перевтому через напруженої роботи. Було важко встигати за колегою, який сидить поруч, програмує і одночасно пояснює нові концепції, пов'язані з мовою, процесами і інструментами.
Але є і хороша новина: до другого тижня Горовіц повністю адаптувався і думає, що якщо йому доведеться займатися парним програмуванням в майбутньому, то навіть в перший день у нього не буде таких проблем. Він уже навчився працювати в парі і вважає це одним з корисних навичок, отриманих в цьому проекті.
Крім того, такий стиль приніс і інші бонуси крім початкової завдання навчання розробці хмарного ПО. Так, парна робота призводить до ретельного вивчення коду з різних сторін і точок зору, що неможливо в разі індивідуальної розробки. Адже якість коду зростає, коли вам потрібно пояснювати і захищати свої рішення або коли у вас є можливість попросити колегу зупинитися і пояснити свої дії.
Іншою перевагою є страховка від нещасного випадку. Навіть якщо з одним з учасників команди що-небудь трапиться, інші його легко замінять, так як знайомі з інструментами, процесами і проектом в цілому. Тому незважаючи на додаткові інвестиції з точки зору часу і людських ресурсів парне програмування забезпечує компанії віддачу.
Після завершення цього проекту колегам Горовиця настільки сподобався такий спосіб роботи, що вони стали його застосовувати всюди, де тільки можна. Але виявилося, що він годиться далеко не завжди і тепер використовується в обмеженому обсязі.
Горовіц рекомендує ІТ-директорам і керівникам відділів розробки не застосовувати до парного програмування підхід «все або нічого», а використовувати його, якщо потрібно розширити набір навичок програмування і знань у своєї команди. До того ж застосування такого підходу може дати програмістам поштовх до переходу від індивідуального стилю роботи до більш відкритого і колективному. А чим ширше в команді розвинене співробітництво, тим успішніше результати.
isicad.ru: кілька доданих посилань
