Парне програмування. Бути чи не бути
Мене звати Вадим Бараненко, я співпрацюю з ЕРАМ у ролі архітектора рішень. З парним програмуванням ознайомився у
Перший проєкт, на якому я стикнувся з парним програмування, був для одного з найбільших ритейлерів Англії. Клієнт використовував гнучкі методології розробки, екстремальне програмування (ХР), зокрема парне програмування, test-driven development. Під час цієї співпраці я зацікавився практиками підвищення інженерної продуктивності. Водночас в ЕРАМ з’явився клієнт, котрий хотів мати команду з такими навичками, тож я погодився зібрати її та налагодити інженерні практики.
Згодом з’явилась потреба ще в одній команді і я перейшов туди стартувати процеси як лід. Відтак сформувалася і третя команда. Пізніше я переїхав в Англію та став працювати на боці замовника. Там у нас була справжня Agile-команда без лідів, хоча всі інженери були дуже досвідченими. Певною мірою було цікавим викликом працювати пліч-о-пліч з людьми з різних країн та з різноманітним культурним досвідом. В колективі були інженери з Нігерії, Індії, Єгипту, Англії, України — відчуваєте розмаїття? :) Цікавинки виникали навіть на рівні мови.
Щоправда, тепер мені все частіше трапляються проєкти зі значним обсягом робіт і конкретним бюджетом. У такому форматі навряд чи можна дозволити двом програмістам працювати над одним завданням. Але часом використовувати парне програмування можна. Так, три роки тому ми «вхопили» проблему на продакшні пізно ввечері й разом з лідом проєкту сіли в пару. Писали код за принципом TDD, щоб бути впевненими, що нічого не зламаємо. Вкотре переконалися: коли над кодом працює двоє інженерів з різним мисленням, то ймовірність помилки значно менша. Простий приклад: я побачив у коді п’ять потенційних дефектів, стільки ж — мій партнер. Три дефекти збіглися, але загалом ми відшукали ще більше огріхів, які могли призвести до помилок у продакшені.
Ілюстрація створена за допомогою Awesomic
Чому парне програмування не надто популярне
«Продати» замовнику парне програмування складно. Більшість не розуміє, чому над одним завданням має працювати два інженери. Поверхові підрахунки демонструють, що проєкт потребуватиме вдвічі більше часу та коштів. Щоб погодитися на парне програмування, клієнт має або від початку позитивно ставитися до Agile-методологій, або проходити період цифрової трансформації власного бізнесу, прагнути зрозуміти та розібратись у цих процесах. Важливо, щоб ІТ-відділ замовника був готовий до гнучкіших технологій, а сам клієнт був налаштований платити за якість. Парне програмування дає змогу вивести на ринок практично ідеальний продукт у спокійні, передбачувані терміни. Для жорстких дедлайнів це, мабуть, не найкраща ідея.
Але давайте за порядком. Екстремальне програмування (або ХР) було створено у другій половині
Як організувати парне програмування
Процес парного програмування можна вибудувати по-різному. Є канонічний підхід, який рекомендує Кент Бек (один із засновників ХР): пари інженерів сидять за великим столом з одним монітором, однією мишею та клавіатурою. Але в ЕРАМ ми дещо модифікували його.
Простір
Двоє програмістів сидять за великим столом з одним системним блоком, але двома моніторами, мишами та клавіатурами. Так, на нашу думку, зручніше працювати.
Стіл має бути прямий. Спершу ми мали кутові, а це незручно. Іноді треба було пересувати меблі, щоб сидіти поруч, мати органічний простір для спілкування. Такі маніпуляції — це зайвий час і клопіт.
Командна робота
Щоб побудувати процеси, у вас має бути авторитет. Адже іноді складно пояснити замовнику, менеджменту та інженерам важливість парного програмування.
Якщо клієнт і менеджмент цей підхід приймають, а складнощі залишаються лише з командою, вам варто приділити час побудові хороших стосунків. Культура повинна фокусуватися на взаємодопомозі, а не засудженні.
У парному програмуванні один (ведучий) пише код, другий спостерігає, осмислює на вищому рівні та коригує процес, щоб він відповідав початковим вимогам дизайну. Це взаємодія на кшталт роботи пілота та штурмана у ралійних перегонах. Ролі при такому підході треба часто змінювати, щоб кожен мав змогу і писати, і контролювати код, над яким працює напарник.
Ще одна корисна техніка — це поєднання TDD та парного програмування, коли один пише тест, а другий — імплементацію. Потім запускаємо тест і міняємо ролі. Таким чином ніхто не нудьгує.
Пари мають постійно змінюватися. Завдяки цьому кожен програміст в команді має уявлення про всю систему, а не лише про її частину. Спочатку ми нехтували цією рекомендацією. Під час планування спринту видавали одну User Story на пару та в процесі роботи вже не могли її розділити. Потім, коли одна пара завершувала роботу над User Story, інші зазвичай ще працювали над своїми. Звісно, їх теж неможливо було розділити. Вже в Англії я стикнувся з підходом, який, на мою думку, працює краще. Треба, щоб задачу брав один програміст, а другий йому допомагав. По-перше, ми вирішуємо психологічне питання, коли деяким інженерам комфортно працювати з одними людьми та вкрай дискомфортно з іншими. По-друге — логістичне, адже помічнику на короткий термін співпраці не треба переносити всі свої речі на нове місце. Отже, пару варто створювати або на один день, або на одне завдання.
Інженери в парі повинні дивитися на одну й ту саму частину коду та спілкуватися між собою вголос. «Штурману» не варто забирати керування у свої руки. Хороша практика — звернути увагу на огріхи, розповісти та обговорити, що можна зробити інакше.
Мій досвід доводить, що в парі можна якісно натренувати Junior’ів. Це дещо суперечить канонам, адже програмісти повинні бути близькі за своїм професійним рівнем. Але, якщо підходити до процесу розумно, не відбирати у початківця «кермо» та спілкуватися одне з одним, спрацює.
Отже, ви переконались, що парне програмування на вашому проєкті необхідне. Ось перелік переваг, щоб «продати» ідею, та недоліків, щоб бути до них готовими.
Переваги парного програмування (або «Бути)
Обмін знаннями. Ви можете миттю поширювати інформацію та не залежати від однієї людини. Якщо хтось з команди піде у відпустку або на лікарняний, в інших буде повна картинка. Цього можна досягти, якщо регулярно змінювати пари.
Якість коду в разі правильної побудови процесу підвищується. Різні підходи до роботи та погляди на параметри коду можуть дати краще рішення.
Кращий дизайн на різних рівнях продукту. Якщо перед тим як писати код, програмісти обговорюватимуть його, то якість коду буде вищою у всій системі. Звісно, ХР вчить, що команда менше часу має приділяти дизайну продукту, аби одразу сфокусуватися на коді. Знаєте, як часто молоді інженери починають писати код, щойно отримали завдання? От у таких випадках робота в парі допомагає більше думати та економити час на виправленні дефектів. На мій погляд, це навіть ефективніше, ніж двоє програмістів, які працюють над двома різними завданнями паралельно.
Вища ефективність команди. Як я вже зазначав, якщо хтось стежить за роботою спеціаліста, він виконує її краще, ніж наодинці. І це не історія про так званих low перформерів (тобто тих, хто демонструє дуже посередні результати). Це елементарна психологія.
Менше контролю з боку менеджерів. Адже в парному програмуванні члени команди контролюють одне одного. Спільна відповідальність за виконання завдання мотивує людей показувати кращі результати.
Потенційні складнощі (або «Не бути»)
Інженерам почати працювати з кимось у парі психологічно складно. По-перше, не всім подобається, коли за їхньою роботою пильно спостерігають. Пам’ятаю, коли я у
Не кожному замовнику легко довести важливість парного програмування. Найскладніше це зробити для клієнтів, які далекі від ІТ-сфери (мовляв, навіщо вдвох працювати над тим, що може робити один?). А найпростіше — для клієнтів з проєктами із зафіксованими дедлайнами та обсягами робіт на конкретний період. Такі проєкти суперечать певним принципам гнучких методологій, адже команда лише частково контролює процес, проте парне програмування в них дозволяє ефективніше розв’язувати складні завдання.
Є багато ситуацій, коли з процесами щось пішло не так, бо лід, Scrum-майстер або інша відповідальна людина пропустили кризову ситуацію. Скажімо, або ніхто відразу не встановив правила роботи в парах, або посадив за один стіл зовсім різних за професійним рівнем і темпераментом фахівців, або забув про зміну пар... Усе це ламає підхід до парного програмування, погана репутація проєкту поширюється зі швидкістю світла, й надалі все складніше залучати нових інженерів до роботи. Найбільші труднощі виникають, коли люди не взаємодіють ефективно, не довіряють одне одному та не розуміють, навіщо їм працювати разом.
Працювати віддалено та застосовувати парне програмування майже нереально. Є певні онлайн-інструменти, але я їх майже не використовував. Бракує найголовнішого: живого контакту людей.
Хвилинка стереотипів :) Є думка, що програмісти не дуже люблять мати справу з іншими людьми. Мовляв, їм більше до душі спілкування з комп’ютерами. А у парному програмуванні доведеться говорити з іншими членами команди. Пояснювати, що та чому робиш. Це може дратувати та справді не всім підходить.
Отже, парному програмуванню бути. Що далі
Розпочніть з піару :) Розповідайте команді, менеджменту та замовникам, навіщо це робите, яким труднощам завдяки такому підходу можна запобігти, як зробити так, щоб парне програмування працювало як слід. Спробуйте впроваджувати його не одразу, а поступово. Наприклад, коли будуть складні завдання. Під час планування дозволяйте інженерам самим обирати завдання до душі та запрошувати колег долучитися до роботи. Якщо маєте в команді людину з досвідом парного програмування, заплануйте, щоб вона попрацювала по черзі з кожним членом команди. Я так робив, коли налаштовував процеси парного програмування та TDD у низці нових проєктів. Фактично я був ментором і показував найкращі практики новачкам.
На початку роботи спробуйте визначити страхи вашої команди, пов’язані з впровадженням парного програмування. Поясніть, що їх ніхто не буде засуджувати за помилки чи неідеальні рішення, що час на каву залишиться. Наголосіть на тому, що завдяки такій роботі можна вивчити багато нового та підгледіти найкращі практики своїх колег: от Ігор, скажімо, робить класні тести, а Сергій чудово виправляє баги. Досвід кожного члена команди від парної роботи стане багатшим, це добре не лише для розуміння продукту, а для й самоорганізації. Звісно, в плюсі будуть і менеджери. В парі люди працюють ефективніше, адже соромно перед колегою ледарювати.
Парне програмування не срібна куля, але може бути дуже корисним для деяких проєктів. Розкажіть, а ви працювали з ним? Може, знаєте більше класних ресурсів, щоб зануритися в тему? Буду радий обмінятися досвідом у коментарях.
Корисні матеріали
- Кент Бек Extreme Programming Explained: Embrace Change, 2nd Edition.
- Роберт Мартін The Clean Coder: A Code of Conduct for Professional Programmers.
- Відео від Роберта Мартіна.
