Парное программирование в деталях: плюсы и минусы. Часть 1
Всем привет, меня зовут Юрий Бондаренко. Я сотрудничаю с EPAM в роли Senior Software Engineer. В ходе работы у меня накопился большой практический опыт парного программирования, я решил поделиться им.
Так как материал получился объемный, я разделил его на две части. В первой расскажу о том, как начал работать по такому подходу, а также перечислю его плюсы и минусы. Во второй части речь пойдет непосредственно о техниках, которые можно использовать для получения лучшего результата, и задачах, которые не стоит делать в паре.
Предыстория
Вступительную часть для этой статьи я переписывал множество раз. Снова и снова мне что-то не нравилось. В какой-то момент история, с которой я решил начать свой рассказ, нашла меня сама. Каждый год на зимние праздники я с семьей приезжаю к моим родителям. И это Рождество не было исключением. В этот раз с собой решил взять Nintendo Switch, которую моей дочке подарил Дед Мороз :)
В один из вечеров, когда мы дружно играли в Crash team racing nitro-fueled, мои родители вспомнили, что точно так же играли в моем детстве. И в этот момент я осознал, что моя первая сессия парного программирования произошла больше 25 лет назад, когда мне было лет просил умолял родителей купить это чудо техники.
В один прекрасный день мои родители принесли домой, как они говорили, что-то «значительно более крутое, чем эта ваша Dendy» (правда, мне тогда так не казалось). Это был украинский «персональный компьютер» Робик, клон SpectrumZX.
Но как же я ошибался! Оказалось, для него существовало много игр и была даже возможность копировать их, а самое крутое и неочевидное достоинство состояло в том, что он давал возможность программировать на диалекте Basic-a. Очень быстро Робик полюбился всей семьей, а воспоминаниям о наших играх теперь отведено особое место.
Чего только стоит история о том, как мы проходили «Приключения Буратино»: в какой-то момент моя мама на миллиметровке нарисовала полноразмерную и детализированную карту ее игрового мира — и это все только для того, чтобы мы сбежали от преследования. Но это совсем другая история...
Наигравшись вдоволь в игры Робика, мне стало интересно, что значат слова, написанные на ребре практически каждой клавиши. К тому моменту я пользовался всего одним из этих слов `LOAD` для старта загрузки игры. К моему счастью, вместе с компьютером родители купили книгу и что-то напоминающее университетскую методичку по похожему диалекту Basic-а. Изучал я это взахлеб: было невероятно интересно, хоть и местами очень непонятно. Благо, у моего отца был небольшой опыт программирования в студенческие годы и он всячески помогал мне разобраться в вопросе.
В какой-то момент мы начали придумывать себе задачки, которые решали совместно — парно программировали, так сказать. А еще через несколько лет, когда я начал участвовать в разных олимпиадах (правда, не по программированию), мы обсуждали и решали те задачи, в которых я не смог разобраться самостоятельно.
Все это мне дало определенный набор навыков, которые помогают и сейчас работать в «кооперативном режиме». И только через много лет я узнал, что есть такая практика как парное программирование.
Около
Мы не могли обсудить детали проекта оффлайн, но в тоже время онлайн позволял нам в любой момент «провалиться» в код, поделившись в онлайне экраном. Для нас было в порядке вещей просто созвониться и обсудить какую-то проблему или даже что-то не связанное с проектами. Очень часто, начав, решение находилось само собой, стоило озвучить свою проблему. В это же время мы пробовали разные подходы из экстремального программирования, а полигоном для испытаний были разные проекты вне основной работы.
Однако мы долго не могли опробовать парное программирование в полной мере: не было вменяемого программного решения. В какой-то момент нам пришел инвайт в Screenhero — продукт, который предоставлял комплексное решение для парного программирования (позже его выкупил Slack). Дождавшись выходных, мы устроили полноценную сессию, на которой в буквальном смысле за пару дней сделали больше, чем за пару месяцев до этого. Такой колоссальный успех стал возможен за счет нескольких факторов одновременно:
- огромного желания попробовать новый подход в разработке;
- отлаженного взаимодействия, так как за несколько месяцев совместной работы мы научились правильно коммуницировать и доверяли друг другу;
- отсутствия боязни сказать какую-то ерунду.
Пожалуй, те выходные были моим первым полноценным опытом парного программирования.
Но давайте всё-таки разберемся, что вообще такое парное программирование. Согласно определению, это процесс, когда два человека совместно и одновременно работают над одной задачей, используя для этого один компьютер. При этом, вопреки названию, метод подходит не только для написания кода, но и для планирования, обсуждения путей решения и требований для нахождения наиболее оптимального варианта. Звучит немного сложно, но на практике все значительно проще.
Для начала стоит разобраться, какие потенциальные преимущества и проблемы мы можем получить, используя парное программирование. Проанализировав их, нам будет значительно проще находить применение этой техники в реальных проектах.
Преимущества парного программирования
Обмен знаниями. Это, наверное, самое очевидное и самое недооцененное преимущество совместной работы. Когда два человека работают над новым направлением, такой обмен позволяет более эффективно распространять знания, полученные в предметной и технической областях. Кроме того, когда над одним вопросом работают двое — шансы найти оптимальное решение повышаются.
Формулирование своих мыслей. Думаю, большинство из нас сталкивались с ситуацией, когда было достаточно сформулировать и озвучить свою проблему, чтобы решение по выходу из тупика пришло само.
Парное программирование как раз заставляет участников процесса больше обсуждать идеи и решения, а не только вести диалог в своей голове. Озвучивая свои мысли, мы помогаем мозгу формулировать их точнее, полнее. Также это наталкивает нас на размышления, а правильно ли мы понимаем проблематику задачи и действительно ли предлагаем удачное решение.
Сохранения фокуса. Работая вдвоем, мы более сфокусированы на задаче и шансов поймать себя на прокрастинации становится все меньше. Согласитесь, в одиночку вероятность переключится на что-то неважное значительно выше. И эта проблема стала еще актуальнее, когда мы перешли на удаленную работу: теперь нас отвлекает не только почта, Ютубчик, твиттеры и т. д., но и домашние заботы.
Чтобы не сбиваться с пути, сохранять концентрацию на результате и не прятаться в условных «кроличьих норах», стоит попробовать работу в паре. Это поможет завершать поставленные задачи быстрее.
Code review как часть процесса. Так как в процессе парного программирование участвуют два человека, то один всегда является наблюдателем. Это похоже на Code Review, однако, с тем отличием, что ревьювер находится непосредственно в контексте, что облегчает его задачу. Главное — задавать вопросы и в тоже время быть открытым к ним со стороны своего напарника.
Совмещение двух разных моделей мышления. Работая самостоятельно над какой-то задачей, мы изначально продумываем все стратегические решения, архитектуру, и потом приступаем к реализации деталей, периодически переключаясь обратно на стратегическое мышление, чтобы понять, что же в процессе у нас получается.
При парном программировании пока один работает над деталями, у второго есть возможность взглянуть на всю картину в целом и внести корректировки на более раннем этапе.
Совмещение разных сфер знаний. В парном программировании не обязательно должно участвовать два разработчика. Часто бывает эффективнее брать в напарники людей, у которых знаний значительно больше в других сферах. К примеру, это может быть человек, который обладает более обширным пониманием бизнес-процессов.
Проблемы парного программирования
Хоть парное программирование имеет уйму достоинств, оно не лишено и недостатков. Как минимум, оно требует практики, так как с самого начала все может быть далеко не гладко. Ниже я постараюсь привести самые распространенные сложности.
Если (или когда) вы столкнётесь с ними, напоминайте себе о преимуществах, перечисленных выше, и причинах, по которым вы изначально создали эту пару. Важно понимать свои цели с самого начала, так будет значительно проще достичь результата.
Это может быть утомительно. Работая в одиночку, вы можете делать перерывы тогда, когда вам этого захочется. Работа в паре заставляет быть более сконцентрированным в течение достаточно продолжительного времени. Повышенная концентрация, с одной стороны, является преимуществом парного программирования, однако, такая интенсивность может утомлять. Четко лимитируйте длину сессий и не забывайте делать перерывы, чтобы избежать этого.
Плотное общение — это непросто. Так как парное программирование подразумевает большое количество коммуникации, для многих это становится камнем преткновения. У вас с партнером могут быть разные методы разработки и решения проблем, разный уровень знаний: как технических, так и о самом продукте.
Кто-то может оказаться классическим интровертом, а кто-то — будет готов говорить без умолку. В любом из этих сценариев вам придется потратить какое-то время, чтобы научится работать вместе.
Как бы странно это не звучало, только общение и обсуждение формата работы помогут решить данную проблему. Попробуйте проводить обмен обратной связью в конце сессий, чтобы в итоге найти формат, который будет удобен обоим.
Найти время. Не знаю как у вас, а у меня бывают дни, которые под завязку забиты разного рода встречами и звонками. В этих ситуациях к вечеру остается чувство, будто ничего и не сделал за весь день. С одной стороны, все эти встречи необходимы для обсуждения, планирования и согласования разных вещей. С другой — они прерывают поток и нередко из-за большого количества звонков просто невозможно найти время, когда оба члена пары доступны для совместной работы.
Так как митинги будут всегда и отказаться от них полностью невозможно, нужно искать какие-то пути решения. Вот пара советов:
- Вносить такие сессии в календарь.
- Четко ограничить суммарную продолжительность всех встреч в течение дня. Так как наш мозг придает повышенный приоритет новым входящим запросам, то за счет этой уязвимости мы можем неразумно расходовать время. Также очень полезно проанализировать свой календарь за последние несколько месяцев для выявления потенциально неважных или избыточных звонков.
- Сокращать продолжительность сессий парного программирования, что поможет также понизить интенсивность работы до разумных пределов.
Дисбаланс влияния. В команде всегда есть формальные и неформальные иерархии. Примером формальной иерархии может быть взаимодействие между PM или Team Lead-ом и командой. А примером неформальной служат схемы «старший — младший», «новенький в команде — тот, кто на проекте уже несколько лет».
Это всего несколько примеров, в реальности неформальные иерархии бывают очень разные и они могут вносить дисбаланс в пары. Это ведет к тому, что кто-то доминирует в сеансе и захватывает клавиатуру в заложники, не давая второму активно участвовать в разработке; кто-то ведет себя как учитель; кто-то не слушает доводы напарника или игнорирует его предложения.
Пожалуй, это одна из самых сложных проблем, которую не так легко идентифицировать за пределами непосредственной пары.
Вскрытие слабых мест. Работая в паре, нужно не только активно пользоваться своими знаниями, но и проявлять их отсутствие в той или иной теме. Это является нетипичным поведением для большинства людей. Как показывает практика, проявление недостатка знаний дается многим довольно сложно, так как для нас естественно стараться показать себя с сильной стороны.
Для решения этой проблемы существует только один путь: создание атмосферы доверия внутри пары. Только при таком взаимодействии человеку комфортно открываться и не бояться показаться «слабым».
Поиск возможностей. Вообще, наверное, самое первое, с чем сталкиваются люди, которые хотят внедрить парное программирование в команду — убеждение менеджмента и команды в эффективности данного метода. Подчас сложно даже найти напарника. И для решения этой проблемы не существует простого рецепта. Здесь нужно пробовать, аргументировать и искать возможности.
На этом пока ставлю многоточие. Во второй части статьи речь пойдет о техниках парного программирования, настройке этого процесса в удаленном формате, возможных хитростях в работе, неподходящих для парного программирования задачах и прочем.
Спасибо всем, кто дочитал. Делитесь своим опытом парного программирования, буду рад конструктивной дискуссии в комментариях. Продолжение следует...
Anton Katrus
Олег
Олег
Oleksandr Tkalenko
Roman Glebov
Yaroslav Kuchkovsky
Рахіт Срінавасович Кумар
dou-user-220215
dou-user-220215
Paul Loyanich
anonymous
19 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів