Парное программирование - мысли вслух...

Основные наблюдения: 

- парное программирование - это весело, с улыбками

- парное программирование - это шумно

- парное программирование - это концентрация на задаче

Если чего-то из этого не получается - повод задуматься. Что-то пошло не так.

В паре есть две роли. Тот кто у руля и тот, кто с test list (дальше, тестлистом). У каждой роли свои четкие обязанности. 

Тот кто с тесилистом - молчать должен, и стараться не критиковать вообще того кто у руля. Говорит тот, у кого клавиатура. Говорит о том, как он решет текущую задачу. Тот кто с тестилистом внимательно следит и смотрит за несоответсвием того кто у руля в том что он говорит и пишет. Говорю <= пишу >=, говорю -1 пишу 1. И так далее. Ловить баги.

Что делать с критикой? Выписать ее в тестлист, и когда произойдет обмен клавиатурой, предложить устранить запах, который вызвал протест. 

Если так делать случается магия. Сеньйор, который сидит у тестлиста вдруг начинает учиться у джуника, который у руля. Как это возможно? Джуник просто накануне прочитал умную стать. Но если сеньйор будет постоянно его поучать "сделай так" "сделай эдак", то и сам нового не узнает и джуника ничему не научит. Дело в том, что тебя, о Сеньйор, никто не слушает, пока в голове есть своя идея как это можно было бы реализовать. Даже если ты знаешь, почему она не сработает - тебя не услышат, пока не получат граблями по бошке.  

А вот за чем ты должн следить с тестлистом на руках, так это за временем. Не больше 10 минут на каждую итерацию. Дай время напарнику облажаться, а потом забери клавиатуру если у него не получилось, сделай так как считаешь нужно. У тебя-то получится. Хотя практика показывает, что не всегда. 

Что делать тому, кто у руля, если у сеньйора с тестлисом рот не закрывается. Сунуть ему клавиатуру в руки и сказать, на делай - теперь ты у руля. А я посмотрю, как ты это сделаешь за ближайшие 10 минут. Поменялись ролями, теперь джуник следит за тем, что делает сеньор и помагает. 

Как джуник может помочь сеньйору? А сеньйор делает те же самые очепятки что и джуник, приблизительно с той же скоростью. За ними следи. Так же у сеньйора не получается что-то, что он думает, что получится. Магия в том, что в этот момент пока сеньор напряженно думает у руля, у джуника может появится идея и стоит только подождать немного пока сеньйор не сдастся (лимитировав его конечно по времени) а потом взять клавиатуру (снова поменяться ролями) и попробовать свое. Вышло? Поздравляю! Не вышло. Думайте дальше... 

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

Что касается спора. Все вопросы, которые возникают у вас обоих во время делания текущей задачи должны выписываться в тестлист тем, кто его сейчас держит в руках. Никаких клевых идей! Сейчас надо закончить то, что начали 2 минуты назад - потом уже все рефакторинги, пересомтры архитектуры и так далее... Все через тест лист. Спорить так же не сильно стоит. В момент когда текущая задача решена, просто выберите из списка то, что можно сделать быстро в течении следующих 5 минут. Если такой задачи сейчас нет - разбробите ту что есть на помельче. Выхлоп (коммит) и смена ролей должна происходить каждый 5-10-15 минут. 

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

Я только что сказал "сделать риверт". Так вот чтобы сделать риверт последних 2 минут, надо как минимум делать коммит каждые 5 минут. Частые коммиты, это то что помагает парному программированию.

Еще на каждом коммите полезно предлагать другу "дать пять". Это эмоциональный якорек успеха. И других ребят подбадривает...

Что еще? 

Вот что. Забудь что есть сеньйор или джун. В паре вскоре оказывается, что каждый сеньорный в чем-то своем, тогда как напарник при это джуник. Не пытайся "научить джуника" жить (кодить) правильно. Предлагай изменения через тестлист, и берись за них в тот момент, когда он готов будет услышать. Сам же не зацикливайся на том, что знаешь - послушай своего коллегу. Чаще спрашивай: а как ты это сделал? а почему? И увидишь, что он тоже знает оченьо многое.  

Зачем парное программирование? 

Для меня причине несколько. Более эффективное делание чего-то. Я не тужусь над проблемой сам, меня напарник подменяет. У пары сил обычно больше, чем у двоих ребят по отдельности, иначе не было понятия синергия.  В паре не страшно делать что-то потому как с ответственность делится с другом. Кроме того где ему страшно, не страшно напарнику и наоборот. В паре весело - это то, что запомнится на долго. В паре одет обмен опытом более эффективно, чем на митингах - просто потому, что он идет постоянно и неосознанно. Мы просто перенимаем хорошие привычки друг друга. 

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

Что еще? 

Вдвоем, после преодоления внутренних барьеров включается режим игры. Вы не воюете с кодом, как бы делали по отдельности, вы играетесь в него. Кроме того в паре существуют игры, например TDD-пинг понг. Игру можете придумать и сами. Хорошо если к самому процессу парного программирования будете относиться как к игре. 

Скорость с которой вы педалите просто зашкаливает. И у сработанной пары на много превышает затраты на то, что двое решают одну задачу - для менеджера на одну задачу двое больше времени уходит (вдвое дороже), а пара поймет вскоре, что при этом они становятся в X раз эффективнее. И x >> 2. Но не сразу - помни про внутренний барьер, желание переучить напарника - эффективность произойдет тогда, когда ты это преодолеешь.

На чем экономится время? Баналльно на всяких мессенджерах, соцсетях. Вероятность того, что твой напарник будет заинтересован посмотреть твою стенку на Facebook в то же время что и тебе и так же как тебе обычно стремится к 0. Ему интересно что-то другое, чем бы он занялся, если бы рядом не было тебя. Может он так отвлекается, отдыхает. Но когда вы в паре, вам надо найти другое развлечение, совместное, например чаепитие... 

Итак если сотрудник лоботряс (опять же по мнению менеджера), и половину рабочего времени тусит в соцсетях, то лечится это парным программированием. Два лоботряса сажаешь друг с дружкой в пару, вот они уже работают не 4 + 4 часа по отдельности, а 8+8 но вместе. Немного утрирую, но как-то так оно и происходит. 

Напарник с тестлистом не дает тебе отвлечься на клевую идею как-то все порефакторить (или прикрутить либу), которая у тебя вдруг возникла. Если кодишь сам - все бросаешь и берешься за клевую идею. Она ведь у меня в голове появилась. Значит она клевая. Но прикол в том, что если ее отложить на час в тестлист, а потом вернуться к ней спустя некоторое время, то окажется что никакая она не клевая, а вообще фукака... Напарник помагает тебе не сорваться на ее выполнение со словами "я выпишу это в тестлист" он предлагает продолжить начатое, ведь у нас есть 10 минут до коммита... С этим экономится масса времени.

Баги. Бага это такая штука, которая иногда появляется как очепятка (думаю одно а пишу другое), потом обрастает кодом и уже нужен дебаггер, чтобы ее найти и устранить. А дебаг - самое ресурсоемкое занятие. Его по хорошему стоит вообще стоит исключить из процесса. Но как? Напарник. Он вылавшивает баги. Он смотрит на то, что ты делаешь с другой точки зрения и он видит то, чего не видишь ты. Дебага будет меньше, баги будут вылавливаться раньше, а значит работа пойдет быстрее.

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

Банально напарник может научить тебя пользоваться хоткеями, к которыми привык и просто на наборе текста ты уже ускоришься. Он не будет тебя принуждать учить хоткеи как он - он просто будет делать привычные вещи, а тебе это понравится и ты сам спросишь у него - а что ты там сделал? Ану-ка покажи...

Есть конечно же ограничения. Не работать больше 6-8 часов, 5 дней в неделю. Потому как иначе будет на износ. 

Ну а если не получается что-то помни, что не инструмент не работает, не проект у тебя особенный, а ты просто  не хочешь - все в тебе и от тебя зависит, будет ли что-то работать или нет. 

Как быть если ты энтузиаст и хочешь, чтобы у вас в команде было парное программирование? Не принуждай, скорее всего ты получишь отпор команды. И это естественно. Покупают обычно не то, что предлагают в переходе, а то что сам решил купить (или думаешь, что решил). Так вот сядь и выжидай, когда же к тебе обратится за помощью коллега. Обратился? Что-то спрашивает? Не говори НЕТ я занят, не предлагай ему устного решения, предложи так - "у меня есть сейчас пол часа времени, давай сядем вместе и разберемся что у тебя там". Это вскоре приведет к тому, что парного программирования станет чаще и происходить оно будет не только с тобой. Начни с себя! 

И помни, парное программирование как наркотик. Если вдруг привык а потом приходится работать не в паре, кажется что удалили пол мозга. Но и тут есть решения. Например эффект мишки тедди, когда напарником можешь поставить себе плюшевого медвежонка и ему все рассказывать вслух. TDD, когда за твоими ошибками следят тесты. Тестлист можно вести самому и ко всем идеям, что возникают относиться скептически. Частые коммиты и много других прикольных практик можно  выполнять самому. Было бы желание.