Парное программирование в деталях: плюсы и минусы. Часть 1

Всем привет, меня зовут Юрий Бондаренко. Я сотрудничаю с EPAM в роли Senior Software Engineer. В ходе работы у меня накопился большой практический опыт парного программирования, я решил поделиться им.

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

Предыстория

Вступительную часть для этой статьи я переписывал множество раз. Снова и снова мне что-то не нравилось. В какой-то момент история, с которой я решил начать свой рассказ, нашла меня сама. Каждый год на зимние праздники я с семьей приезжаю к моим родителям. И это Рождество не было исключением. В этот раз с собой решил взять Nintendo Switch, которую моей дочке подарил Дед Мороз :)

В один из вечеров, когда мы дружно играли в Crash team racing nitro-fueled, мои родители вспомнили, что точно так же играли в моем детстве. И в этот момент я осознал, что моя первая сессия парного программирования произошла больше 25 лет назад, когда мне было лет 8-9. Чтобы понять, как это вообще возможно, нужно переместиться во времена, когда мечтой практически каждого ребенка была NES-приставка. Я не был исключением и регулярно просил умолял родителей купить это чудо техники.

В один прекрасный день мои родители принесли домой, как они говорили, что-то «значительно более крутое, чем эта ваша Dendy» (правда, мне тогда так не казалось). Это был украинский «персональный компьютер» Робик, клон SpectrumZX.

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

Чего только стоит история о том, как мы проходили «Приключения Буратино»: в какой-то момент моя мама на миллиметровке нарисовала полноразмерную и детализированную карту ее игрового мира — и это все только для того, чтобы мы сбежали от преследования. Но это совсем другая история...

Наигравшись вдоволь в игры Робика, мне стало интересно, что значат слова, написанные на ребре практически каждой клавиши. К тому моменту я пользовался всего одним из этих слов `LOAD` для старта загрузки игры. К моему счастью, вместе с компьютером родители купили книгу и что-то напоминающее университетскую методичку по похожему диалекту Basic-а. Изучал я это взахлеб: было невероятно интересно, хоть и местами очень непонятно. Благо, у моего отца был небольшой опыт программирования в студенческие годы и он всячески помогал мне разобраться в вопросе.

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

Все это мне дало определенный набор навыков, которые помогают и сейчас работать в «кооперативном режиме». И только через много лет я узнал, что есть такая практика как парное программирование.

Около 7-8 лет назад в небольшой компании, где я тогда работал, я познакомился с крутым разработчиком Гошей. Он научил меня многим вещам, а в последствии стал хорошим другом. С ним мы поработали над далеко не одним проектом в нескольких компаниях. Но так получилось, что все время нашего сотрудничества и дружбы мы живем в разных городах, а сейчас и вовсе — в разных странах. И это всегда накладывало определенные ограничения на нашу коммуникацию.

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

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

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

Пожалуй, те выходные были моим первым полноценным опытом парного программирования.

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

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

Преимущества парного программирования

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

Формулирование своих мыслей. Думаю, большинство из нас сталкивались с ситуацией, когда было достаточно сформулировать и озвучить свою проблему, чтобы решение по выходу из тупика пришло само.

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

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

Чтобы не сбиваться с пути, сохранять концентрацию на результате и не прятаться в условных «кроличьих норах», стоит попробовать работу в паре. Это поможет завершать поставленные задачи быстрее.

Code review как часть процесса. Так как в процессе парного программирование участвуют два человека, то один всегда является наблюдателем. Это похоже на Code Review, однако, с тем отличием, что ревьювер находится непосредственно в контексте, что облегчает его задачу. Главное — задавать вопросы и в тоже время быть открытым к ним со стороны своего напарника.

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

При парном программировании пока один работает над деталями, у второго есть возможность взглянуть на всю картину в целом и внести корректировки на более раннем этапе.

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

Проблемы парного программирования

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

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

Это может быть утомительно. Работая в одиночку, вы можете делать перерывы тогда, когда вам этого захочется. Работа в паре заставляет быть более сконцентрированным в течение достаточно продолжительного времени. Повышенная концентрация, с одной стороны, является преимуществом парного программирования, однако, такая интенсивность может утомлять. Четко лимитируйте длину сессий и не забывайте делать перерывы, чтобы избежать этого.

Плотное общение — это непросто. Так как парное программирование подразумевает большое количество коммуникации, для многих это становится камнем преткновения. У вас с партнером могут быть разные методы разработки и решения проблем, разный уровень знаний: как технических, так и о самом продукте.

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

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

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

Так как митинги будут всегда и отказаться от них полностью невозможно, нужно искать какие-то пути решения. Вот пара советов:

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

Дисбаланс влияния. В команде всегда есть формальные и неформальные иерархии. Примером формальной иерархии может быть взаимодействие между PM или Team Lead-ом и командой. А примером неформальной служат схемы «старший — младший», «новенький в команде — тот, кто на проекте уже несколько лет».

Это всего несколько примеров, в реальности неформальные иерархии бывают очень разные и они могут вносить дисбаланс в пары. Это ведет к тому, что кто-то доминирует в сеансе и захватывает клавиатуру в заложники, не давая второму активно участвовать в разработке; кто-то ведет себя как учитель; кто-то не слушает доводы напарника или игнорирует его предложения.

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

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

Для решения этой проблемы существует только один путь: создание атмосферы доверия внутри пары. Только при таком взаимодействии человеку комфортно открываться и не бояться показаться «слабым».

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

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

Спасибо всем, кто дочитал. Делитесь своим опытом парного программирования, буду рад конструктивной дискуссии в комментариях. Продолжение следует...

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Был у меня опыт парного программирования, в течении 4 месяцев по 6-8 часов в день. Never
ever fucking again.

Ух, это очень большие сессии в день. Не нужно так )))

Головний плюс — можна відчути всю чарівність рубі і підготуватися до релокейту в Дніпро.

подарил Дед Мороз

дед мороз в расее

у нас другой персонаж

Для чего «парное программирование» галере — понятно: синьоры сами обучают своих же конкурентов, вместо того чтобы заниматься любимым делом (коденьем).

Для чего «парное программирование» джунам — понятно тоже (см выше).

Но для чего оно самим синьорам?

Кроме того, не перечислены существенные недостатки «парного программирования»:

— коденье становится в несколько раз медленнее/временные издержки растут в те же разы (необходимость объяснять + отсутствие фокуса + над таском для одного кодера, задействованы сразу 2 кодера)

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

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

Спасибо за комментарий, у Вас был реальный опыт парного программирования или это теоретические мысли? И да в рамках второй части я проговорю о задачи которые не очень подходят для ПП ))

у Вас был реальный опыт парного программирования или это теоретические мысли?

Был, но я всегда старался его минимизировать (если это не касалось моих личных проектов, не «на дядю»).

Лично я рассматриваю «парное программирование» исключительно, как преподавательскую деятельность (где в паре синьор и джун).
Если спецы равноценны, для решения простых тасков — такая «пара» не нужна, для сложных тасков (где нужен прежде всего фокус) — неэффективна.

Для каждого инструмента есть свое применение )) Но частично, только частично соглашусь с Вами.

Но для чего оно самим синьорам?

Потому что сениор однажды захочет стать СЕО и зарабатывать два-три-пять лямов в год. Или даже миллиард. Создаст фирму, заключит контракты, выйдет за головами — а на рынке одна пена, которая ни в коде, ни в процессах, ни в доменах.

И единственный шанс исправить ситуацию, это начать самому и сейчас, чтобы потом, когда ты СЕО, возможно, не грести вайтишную шелупонь с запросами, как у сениора.

Потому что сениор однажды захочет стать СЕО

Для того, чтобы стать CEO в «дядиной» конторе — нужно для начала стать в ней менеджером и дальше пойти по менеджерской линии.

А нафига такое толковоми синьору? Менеджерить тушки, писать бумажки и тереть тёрки — вместо педаленья кода? Хорошему синьору — такое, как правило, нафиг не надо.

П.С. Я знаю случаи продвижения хороших кодеров/техспецов в менеджмент. У немцев это очень популярно — растить менеджерские кадры из «своих», продвигая в них своих лучших технарей (заманивают повышением зарплаты и прочими плюшками).
Итог обычно неутешителен: хороший технический спец начинает заниматься тем, что ему не нравится и несвойственно — факапит порученные проекты, пытается чего-то там подкоживать (непонятно зачем), впадает в стрессы, спивается...

А нафига такое толковоми синьору?

я просто предложил вариант ответа. сам я парное программирование пробовал(и моб тоже) — там разные случаи были, а вот до CEO еще не дорос.

У немцев это очень популярно — растить менеджерские кадры из «своих», продвигая в них своих лучших технарей

Вот это интересно. А как сам процесс продвижения работает? Это менторство, курсы какие-то или в матрице роста все заложено?

хороший технический спец начинает заниматься тем, что ему не нравится — факапит порученные проекты, пытается чего-то там подкоживать (непонятно зачем), впадает в стрессы

Это только к менеджерам относится или С-левел тоже так может облажаться?

а вот до CEO еще не дорос

Да ладно. У тебя ведь своя контора, вроде. Значит, сам у себя и CEO.

У немчегов — всякие курсы, по управлению проектом, работе с людьми, умению слушать, итп. Затем начало работы по менеджерcкой линии

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

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

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