Expert JS React Developers for TUI wanted. Join Ciklum and get a $4000 sign-on bonus!
×Закрыть

Парне програмування. Бути чи не бути

Мене звати Вадим Бараненко, я співпрацюю з ЕРАМ у ролі архітектора рішень. З парним програмуванням ознайомився у 2012-му та практикував цей підхід на різних проєктах близько п’яти років. Частину з них — у харківському офісі ЕРАМ, частину — на території замовника, в Англії. Досвід був цікавим і корисним. Поділюсь ним у цій статті.

Перший проєкт, на якому я стикнувся з парним програмування, був для одного з найбільших ритейлерів Англії. Клієнт використовував гнучкі методології розробки, екстремальне програмування (ХР), зокрема парне програмування, test-driven development. Під час цієї співпраці я зацікавився практиками підвищення інженерної продуктивності. Водночас в ЕРАМ з’явився клієнт, котрий хотів мати команду з такими навичками, тож я погодився зібрати її та налагодити інженерні практики.

Згодом з’явилась потреба ще в одній команді і я перейшов туди стартувати процеси як лід. Відтак сформувалася і третя команда. Пізніше я переїхав в Англію та став працювати на боці замовника. Там у нас була справжня Agile-команда без лідів, хоча всі інженери були дуже досвідченими. Певною мірою було цікавим викликом працювати пліч-о-пліч з людьми з різних країн та з різноманітним культурним досвідом. В колективі були інженери з Нігерії, Індії, Єгипту, Англії, України — відчуваєте розмаїття? :) Цікавинки виникали навіть на рівні мови.

Щоправда, тепер мені все частіше трапляються проєкти зі значним обсягом робіт і конкретним бюджетом. У такому форматі навряд чи можна дозволити двом програмістам працювати над одним завданням. Але часом використовувати парне програмування можна. Так, три роки тому ми «вхопили» проблему на продакшні пізно ввечері й разом з лідом проєкту сіли в пару. Писали код за принципом TDD, щоб бути впевненими, що нічого не зламаємо. Вкотре переконалися: коли над кодом працює двоє інженерів з різним мисленням, то ймовірність помилки значно менша. Простий приклад: я побачив у коді п’ять потенційних дефектів, стільки ж — мій партнер. Три дефекти збіглися, але загалом ми відшукали ще більше огріхів, які могли призвести до помилок у продакшені.

Ілюстрація створена за допомогою Awesomic

Чому парне програмування не надто популярне

«Продати» замовнику парне програмування складно. Більшість не розуміє, чому над одним завданням має працювати два інженери. Поверхові підрахунки демонструють, що проєкт потребуватиме вдвічі більше часу та коштів. Щоб погодитися на парне програмування, клієнт має або від початку позитивно ставитися до Agile-методологій, або проходити період цифрової трансформації власного бізнесу, прагнути зрозуміти та розібратись у цих процесах. Важливо, щоб ІТ-відділ замовника був готовий до гнучкіших технологій, а сам клієнт був налаштований платити за якість. Парне програмування дає змогу вивести на ринок практично ідеальний продукт у спокійні, передбачувані терміни. Для жорстких дедлайнів це, мабуть, не найкраща ідея.

Але давайте за порядком. Екстремальне програмування (або ХР) було створено у другій половині 90-х і на той період виводило відомі підходи до створення продуктів на новий рівень. 25 років тому, за часів розквіту каскадної моделі розробки, існували складнощі з тим, щоб інтегрувати, тестувати, створити дизайн різних частин продукту та налагодити комунікації між їх розробниками. Однією з практик ХР, що обіцяла швидкий обмін знаннями про систему, рев’ю коду фактично у режимі реального часу та своєчасне створення дизайну системи, стало парне програмування. Воно й тепер дає змогу займатися кодом разом і замість великих релізів робити значно менші. Це спрощує внесення змін і поліпшує якість продукту.

Як організувати парне програмування

Процес парного програмування можна вибудувати по-різному. Є канонічний підхід, який рекомендує Кент Бек (один із засновників ХР): пари інженерів сидять за великим столом з одним монітором, однією мишею та клавіатурою. Але в ЕРАМ ми дещо модифікували його.

Простір

Двоє програмістів сидять за великим столом з одним системним блоком, але двома моніторами, мишами та клавіатурами. Так, на нашу думку, зручніше працювати.

Стіл має бути прямий. Спершу ми мали кутові, а це незручно. Іноді треба було пересувати меблі, щоб сидіти поруч, мати органічний простір для спілкування. Такі маніпуляції — це зайвий час і клопіт.

Командна робота

Щоб побудувати процеси, у вас має бути авторитет. Адже іноді складно пояснити замовнику, менеджменту та інженерам важливість парного програмування.

Якщо клієнт і менеджмент цей підхід приймають, а складнощі залишаються лише з командою, вам варто приділити час побудові хороших стосунків. Культура повинна фокусуватися на взаємодопомозі, а не засудженні.

У парному програмуванні один (ведучий) пише код, другий спостерігає, осмислює на вищому рівні та коригує процес, щоб він відповідав початковим вимогам дизайну. Це взаємодія на кшталт роботи пілота та штурмана у ралійних перегонах. Ролі при такому підході треба часто змінювати, щоб кожен мав змогу і писати, і контролювати код, над яким працює напарник.

Ще одна корисна техніка — це поєднання TDD та парного програмування, коли один пише тест, а другий — імплементацію. Потім запускаємо тест і міняємо ролі. Таким чином ніхто не нудьгує.

Пари мають постійно змінюватися. Завдяки цьому кожен програміст в команді має уявлення про всю систему, а не лише про її частину. Спочатку ми нехтували цією рекомендацією. Під час планування спринту видавали одну User Story на пару та в процесі роботи вже не могли її розділити. Потім, коли одна пара завершувала роботу над User Story, інші зазвичай ще працювали над своїми. Звісно, їх теж неможливо було розділити. Вже в Англії я стикнувся з підходом, який, на мою думку, працює краще. Треба, щоб задачу брав один програміст, а другий йому допомагав. По-перше, ми вирішуємо психологічне питання, коли деяким інженерам комфортно працювати з одними людьми та вкрай дискомфортно з іншими. По-друге — логістичне, адже помічнику на короткий термін співпраці не треба переносити всі свої речі на нове місце. Отже, пару варто створювати або на один день, або на одне завдання.

Інженери в парі повинні дивитися на одну й ту саму частину коду та спілкуватися між собою вголос. «Штурману» не варто забирати керування у свої руки. Хороша практика — звернути увагу на огріхи, розповісти та обговорити, що можна зробити інакше.

Мій досвід доводить, що в парі можна якісно натренувати Junior’ів. Це дещо суперечить канонам, адже програмісти повинні бути близькі за своїм професійним рівнем. Але, якщо підходити до процесу розумно, не відбирати у початківця «кермо» та спілкуватися одне з одним, спрацює.

Отже, ви переконались, що парне програмування на вашому проєкті необхідне. Ось перелік переваг, щоб «продати» ідею, та недоліків, щоб бути до них готовими.

Переваги парного програмування (або «Бути)

Обмін знаннями. Ви можете миттю поширювати інформацію та не залежати від однієї людини. Якщо хтось з команди піде у відпустку або на лікарняний, в інших буде повна картинка. Цього можна досягти, якщо регулярно змінювати пари.

Якість коду в разі правильної побудови процесу підвищується. Різні підходи до роботи та погляди на параметри коду можуть дати краще рішення.

Кращий дизайн на різних рівнях продукту. Якщо перед тим як писати код, програмісти обговорюватимуть його, то якість коду буде вищою у всій системі. Звісно, ХР вчить, що команда менше часу має приділяти дизайну продукту, аби одразу сфокусуватися на коді. Знаєте, як часто молоді інженери починають писати код, щойно отримали завдання? От у таких випадках робота в парі допомагає більше думати та економити час на виправленні дефектів. На мій погляд, це навіть ефективніше, ніж двоє програмістів, які працюють над двома різними завданнями паралельно.

Вища ефективність команди. Як я вже зазначав, якщо хтось стежить за роботою спеціаліста, він виконує її краще, ніж наодинці. І це не історія про так званих low перформерів (тобто тих, хто демонструє дуже посередні результати). Це елементарна психологія.

Менше контролю з боку менеджерів. Адже в парному програмуванні члени команди контролюють одне одного. Спільна відповідальність за виконання завдання мотивує людей показувати кращі результати.

Потенційні складнощі (або «Не бути»)

Інженерам почати працювати з кимось у парі психологічно складно. По-перше, не всім подобається, коли за їхньою роботою пильно спостерігають. Пам’ятаю, коли я у 2012-му починав працювати в парі, то був сеньйором і боявся, що хтось побачить, як я чогось не знаю і маю гуглити питання. Тепер я архітектор рішень, і практика довела, що всі чогось не знають і це нормально. По-друге, не всі прагнуть працювати 100% робочого часу. Гарний результат — шість продуктивних годин. Якщо більше, команда може дійти до вигорання, вичерпати свої ресурси. Щоб запобігти цьому, можна запровадити в парах відомий метод Pomodoro: так інженери будуть працювати 20 або 30 хвилин разом, а потім робити 10-хвилинну перерву, щоб перемкнутися.

Не кожному замовнику легко довести важливість парного програмування. Найскладніше це зробити для клієнтів, які далекі від ІТ-сфери (мовляв, навіщо вдвох працювати над тим, що може робити один?). А найпростіше — для клієнтів з проєктами із зафіксованими дедлайнами та обсягами робіт на конкретний період. Такі проєкти суперечать певним принципам гнучких методологій, адже команда лише частково контролює процес, проте парне програмування в них дозволяє ефективніше розв’язувати складні завдання.

Є багато ситуацій, коли з процесами щось пішло не так, бо лід, Scrum-майстер або інша відповідальна людина пропустили кризову ситуацію. Скажімо, або ніхто відразу не встановив правила роботи в парах, або посадив за один стіл зовсім різних за професійним рівнем і темпераментом фахівців, або забув про зміну пар... Усе це ламає підхід до парного програмування, погана репутація проєкту поширюється зі швидкістю світла, й надалі все складніше залучати нових інженерів до роботи. Найбільші труднощі виникають, коли люди не взаємодіють ефективно, не довіряють одне одному та не розуміють, навіщо їм працювати разом.

Працювати віддалено та застосовувати парне програмування майже нереально. Є певні онлайн-інструменти, але я їх майже не використовував. Бракує найголовнішого: живого контакту людей.

Хвилинка стереотипів :) Є думка, що програмісти не дуже люблять мати справу з іншими людьми. Мовляв, їм більше до душі спілкування з комп’ютерами. А у парному програмуванні доведеться говорити з іншими членами команди. Пояснювати, що та чому робиш. Це може дратувати та справді не всім підходить.

Отже, парному програмуванню бути. Що далі

Розпочніть з піару :) Розповідайте команді, менеджменту та замовникам, навіщо це робите, яким труднощам завдяки такому підходу можна запобігти, як зробити так, щоб парне програмування працювало як слід. Спробуйте впроваджувати його не одразу, а поступово. Наприклад, коли будуть складні завдання. Під час планування дозволяйте інженерам самим обирати завдання до душі та запрошувати колег долучитися до роботи. Якщо маєте в команді людину з досвідом парного програмування, заплануйте, щоб вона попрацювала по черзі з кожним членом команди. Я так робив, коли налаштовував процеси парного програмування та TDD у низці нових проєктів. Фактично я був ментором і показував найкращі практики новачкам.

На початку роботи спробуйте визначити страхи вашої команди, пов’язані з впровадженням парного програмування. Поясніть, що їх ніхто не буде засуджувати за помилки чи неідеальні рішення, що час на каву залишиться. Наголосіть на тому, що завдяки такій роботі можна вивчити багато нового та підгледіти найкращі практики своїх колег: от Ігор, скажімо, робить класні тести, а Сергій чудово виправляє баги. Досвід кожного члена команди від парної роботи стане багатшим, це добре не лише для розуміння продукту, а для й самоорганізації. Звісно, в плюсі будуть і менеджери. В парі люди працюють ефективніше, адже соромно перед колегою ледарювати.

Парне програмування не срібна куля, але може бути дуже корисним для деяких проєктів. Розкажіть, а ви працювали з ним? Може, знаєте більше класних ресурсів, щоб зануритися в тему? Буду радий обмінятися досвідом у коментарях.

Корисні матеріали

  1. Кент Бек Extreme Programming Explained: Embrace Change, 2nd Edition.
  2. Роберт Мартін The Clean Coder: A Code of Conduct for Professional Programmers.
  3. Відео від Роберта Мартіна.
👍НравитсяПонравилось11
В избранноеВ избранном1
Подписаться на тему «программирование»
LinkedIn

Похожие статьи




Підписуйтесь: Soundcloud | Google Podcast | YouTube


20 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

ПП отношусь плохо, первое что приходит на ум как разарабочику это не эффективно для заурядных задач которые уже поставлены «на рельсы» и надо «лабать». Потом не понятно как в двоем вести фикс багов, например?
За XP и хакатоны промолчу — ересь нафиг.

это не эффективно для заурядных задач которые уже поставлены «на рельсы» и надо «лабать»

Собственно это так и есть, его надо использовать для других задач

Потом не понятно как в двоем вести фикс багов, например?

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

За XP и хакатоны

на всякий случай уточню что они никак между собой не связаны :)

Уявімо таку ситуацію.
У нас на проекті 4 Senior developers. З одного боку — дві пари для парного програмування, з іншого боку Senior Developer — людина, яка може працювати сама, без сторонньої допомоги. За це йому і платять чималі гроші.
Що дасть парна робота в такому випадку? Що вона прискорить або поліпшить?
Як на мене її варто використовувати:
1) Коли в команді з’являється новачок
2) Дуже складне технічне завдання
3) Обмін досвідом між людьми з різним background(знання технологій, самого проекту і т.д.)
4) Є синьйор і кілька джуніорiв

Зазвичай, в кожного серьора є якісь специфічні знання, яких немає в інших програмістів, кожен читає щось своє і робота в парі це шанс вивчити щось обом.
Люди часто починають робити щось з різних сторін. В мене були випадки, коли я вважав, що починати якимось способом було очевидно, але мені показували інші способи.
Також це можливість обмінятися контекстом — в кожного можуть бути припущення, що будуть невірними. В парі легко порівняти свої погдяди.

Oleksandr вже гарно відповів про обмін контекстом та різні спецефічні знання у кожного сеньора. Якщо проект вже у відносно спокійному стані (саппорт та додавання нових насклядних фічей) та вся команда вже довго працюе и добре розумія архітектуру і технічні особливості то використовувати ПП постійно буде не зовсім доречно. Від себе я можу додати що ПП працюе найкраще якщо два розробнікі мають пріблізно однаковий рівень. Для роботи над складними завданнями два Senior Developer зазвичай створять рішення краще ніж поодинці, але це може зайняти ще більще часу

Для роботи над складними завданнями два Senior Developer зазвичай створять рішення краще ніж поодинц

Или войдут в штопор холиваров «Почему библиотека X а не Y, или фреймворк B а не С». Проблема ПП, как и всяких аджайлов — чтобы оно работало как планировалось, нужно строгое выполнение набора условий, труднодостижимое в реальном мире.Иначе как раз и будет

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

собственно это проблема не только аджаила :) что бы что-то работало как планировалось надо следовать плану и знать что и как делать в различных ситуациях

Или войдут в штопор холиваров «Почему библиотека X а не Y, или фреймворк B а не С»

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

Дякую за статтю, а чому ви ніде не скорочували парне програмування як ПП?)

Перехожу на новую работу, удаленную. На интервью говорили, что активно практикуют парное программирование на удаленном сервере при помощи tmux и vim. Я с обоими тулами, конечно же, на ты, но посмотрим что из этого выйдет. Вроде как они давно так работают, и им заходит.

Недостатки на самом деле такие
1) оно стоит ровно в ДВА раза дороже для компании(платите двум за ту же задачу), при этом, как правило не дает двойной производительности
2) оно требует, чтоб два человека находилися в фокусе одновременно. Что маловероятно, на самом деле.
3) через какое-то время пара «договаривается» и разные взгляды исчезают. Тоетсь надо еще и менять пары. Причем они все должны быть «совместимые».

Но это когда оно парное, а не просто имитация.

1. В жопочасах — в 2 раза дороже. Но в жопочасах и синьер в 10+ раз дороже джуна
2. Вот в этом, как раз и находится сильнейшая сторона парного программирования — наличие коллеги рядом держит тебя в фокусе. Не «должно держать», а именно держит
3. Да, парное программирование это не просто 2 человека за одним компом — об этом и статья

3) Ну примерно то же я и описал в статье ) пары надо менять однозначно

Давайте порахуємо вартість. Щоб було простіше розробники працюють в парі 6 годин на добу з перервами та перевіркою пошти.

Два розробника — кожен працює десь годин п’ять з перервами на доу. (Втикати в парі набагато складніше).
Ще десь півгодини на те, щоб зрозуміти як зробити, але замість поради людини в парі.
Ще десь півгодини на рев’ю коду. В парі код вже перевірений.

Це вже 8 годин коду проти 6.
А ще ж є час на здобуття контексту — в парі це за замовчуванням.
Ще початковий час на onboarding. В парному програмуванні розробник може наносити користь з першого тижня, але в звичайному з мого досвіду легко може пройти місяць.

Ще час на менторинг. В парному програмуванні набувають навички швидше, ніж у звичайному.

Працювати віддалено та застосовувати парне програмування майже нереально

Пользуемся Code With Me от Intellij — ну просто очень довольны!

Было бы интересно услышать ваш опыт более подробно, сейчас я в основном парно диаграммы рисую в люсидчарте

Как это работает в целом:
* Хост работает в своей родной IDE, клиенты работают в легковесных IDE которые, в пределах задач написания кода, вполне себе полноценные. И клиенты и хост могу как независимо просматривать файлы, так и следовать друг за другом (заставить всех «следовать» за вами — один хоткей). Не в режиме следования — у каждого свой курсор. Но по нашему опыту, в режиме «следования» друг за другом проходит 90%+ времени
* Владеть IDE должен только хост! То есть клиентам покупать IDE что бы парно по-программировать не нужно. Для подключения нового клиента достаточно просто ссылки — весь сетап клиента полностью автоматизирован
Что мне кажется особенно удобным:
* Когда кто-то выделяет код, другие это выделение видят. Так что можно использовать фразы типа «вот тут», еще и без использования мыши :)
* Отдельно настраиваются разрешения на возможность редактировать код, на доступ к файловой системе, возможность запускать код, доступ к консоли
* Клиентам доступны hotkey-схемы разных популярных редакторов, так что человек работающий преимущественно, например, в VS Code будет чувствовать себя достаточно комфортно. Локальные настройки сохраняются, так что поднастройка клиентов, при необходимости, происходит всего единожды
* В свежей версии добавили возможность звонить друг другу, так что даже не нужно будет на фоне запускать zoom — все будет в одной программе
* Может быть для кого-то важно — можно настроить систему чтобы трафик миновал сервера Jetbrains

Функция в режиме ОЧЕНЬ активной разработки. Так что доводилось натыкаться на не очень приятные баги, многие из которых уже пофиксили. Но в целом, по состоянию на сегодня, UX местами сыроват — нужно быть к этому морально готовым

Описался — не от Intellij а от JetBrains. Code with me работает почти во всех JetBrains IDE, не только в Intellij, а в перспективе будет работать во всех

Працювати віддалено та застосовувати парне програмування майже нереально.

Всё отлично работает. Уже год успешно используем tuple.app , но даже Zoom + annotate делает дело.

Гарний результат — шість продуктивних годин. Якщо більше, команда може дійти до вигорання, вичерпати свої ресурси.

На моей практике 6 часов PP даже с регулярными перерывами — это уровень усталости в «мясо» даже для ветеранов PP.

Процитирую сам себя из другого топика:
«Мы регулярно практикуем PP и это мощнейший инструмент продуктивности, но он требует лазерного фокуса и взрывных усилий. Соответственно, применять его нужно разумно и по необходимости. Например, проработать вместе API контракт, отрефакторить модуль, проверить несколько гипотез. То есть реально тогда, когда можно честно сказать, что „одна голова хорошо — а две лучше“. PP для унылого бойлерплейта и тривиальных задач — изнуряет и демотивирует. Обычно мы в таких ситуациях говорим что-то вроде „ок, тут все очевидно, я набросаю решение и завтра продолжим“.»
«PP — это двое человек с одним I/O, что делает невозможным разделение чего-либо, кроме мыслительного процесса.
Соответственно, когда задача тривиальна, то I/O становится bottleneck’ом процесса и 2 „мозга“ начинают жестко throttle’ить.
PP эффективен в противоположной ситуации — когда задача нетривиальна и I/O компьютера большую часть времени ожидает пока 2 „мозга“ выдадут результат.»

У випадку рутини можна вкласти час в вивчення інструментів, але що використовуються (vim, and tmux, and tuple), відрефакторити чи завтоматизувати щось.

Подписаться на комментарии