company_banner

Как начать программировать в парах

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

    • Обучение и онбординг новичков.
    • Шеринг кода/процессов и обмен опытом.
    • Пара решает проблему быстрее и реже обращаются за помощью.
    • Повышение производительности.
    • Сплочение коллектива.
    • Увеличение скорости ревью.

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


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

    Если в двух словах, то это чаще всего это недостаточная «зрелость» команды и влияние некоторых стереотипов. Для себя я выделяю следующие популярные стереотипы и причины, которые мешают начать практику парного программирования:

    • Если посадить двух программистов за два разных компьютера, то они напишут в два раза больше кода. Этот стереотип еще имеет форму «девять женщин могут родить ребенка за один месяц».
    • Мы же наняли еще одного программиста, значит можем взять на N задач больше в спринт.
    • Один я пишу код лучше и быстрее, нежели чем когда кому-то объясняю, что делать и как я это вижу.
    • Во время планирования задачи распределяются не на команду, а индивидуально в виде «Петя возьмет таск X, а Коля будет делать таск Y».
    • Конфликты в команде.

    Но есть и хорошая новость. Парное программирование не нужно внедрять сразу на всю команду.

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

    Конечно тут тоже есть свои нюансы.

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

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

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

    Кому-то больше заходит попробовать парное программирование на мелких тасках. Мотивация тут простая: посмотреть что это и как работает, так сказать буквально проникнуться ситуацией работы «плечом к плечу» с коллегой. Ну а кому-то элементарные задачи совсем не заходят.

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

    Если вы решили все же попробовать парное программирование в своей команде, то вот вам пару советов и наблюдений, с чего лучше начать:


    • Следите за тем, чтобы девелоперы менялись местами. Смена ролей помогает держать людей в тонусе и погруженными в процесс решения задачи.
    • Не рекомендую делать очень длинные сессии, причем как в одной роли, так и сессию парного программирования целиком. Сама сессия парного программирования отнимает достаточно много сил и ресурсов человека. Находиться в ней очень долго тяжело, особенно если вы только начинаете внедрять эту практику в команде. На мой взгляд, на старте вся сессия не должна превышать нескольких часов.
    • Не стоит пытаться писать в паре каждый день и хвататься при этом за любые задачи спринта. Лучше заранее определить, на каких тасках вы попробуете метод парного программирования. Это может быть всего несколько задач из целей спринта. Как подобрать эти задачи я писал выше — это зависит от самих разработчиков.
    • Не стоит формировать пары случайным образом. К этому вопросу надо подойти с ответственностью. По моему опыту, хорошо срабатываются пары со схожим темпом работы. Также хорошо показывают себя люди, которые давно работают вместе и хорошо знают друг друга. Ну и конечно же, если посадить за парное программирование человека, который не хочет этим заниматься, то ничего не получится.
    • Внутри команды/компании должен существовать четкий code style и согласованные подходы к разработке. Это нужно, чтобы во время сессии парного программирования разработчики не тратили время на споры о том, как должен быть оформлен код и как его вообще стоит писать.

    Теория это хорошо, но как это реализовать физически?


    Во времена до пандемии с реализацией практики парного программирования было проще. Два разработчика садились за один стол или шли в переговорку с большим монитором или телевизором, а в процессе работы просто передавали друг другу ноутбук/клавиатуру. И я не просто так упомянул телевизор.

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


    На этом фото сессия моб-программирования, в которой я участвовал еще в докарантинные времена. Как видите, все чувствуют себя комфортно и не сидят друг у друга на головах :)

    Сейчас же, с приходом массовой удаленной работы, просто сесть рядом стало проблематично, но желание продолжать практиковать парное программирование оказалось сильнее. Не могу сказать, что я видел и пробовал очень много решений для организации парного программирования онлайн, но из того, с чем имел дело, ничего конкретного порекомендовать не могу. Тут надо отметить, что мы в команде используем стек kotlin/java + JS/TS и используем продукты от JetBrains. И вот путей удобной организации парного программирования с использованием их продуктов я не нашел. Поэтому вначале мы использовали пусть и не самый удобный, но простой способ — созвон через Zoom. Драйвер шарил свой экран, штурман мог видеть, что пишет драйвер, и комментировать это в процессе.

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

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

    Иногда мы поступали иначе: драйвер делает коммит в новую ветку того, что успел написать. Мы ставили статус WIP этому коммиту (Work in progress) и после смены ролей новый драйвер пулил эту ветку и продолжал писать код. Такой вариант тоже не очень хорош, так как появлялось слишком много коммитов, которые, по сути, были не работающими. Конечно, потом можно было бы их сквошить, но все равно — подход так себе.

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

    В итоге мы пришли к новому продукту JetBrains, который они выпустили в бета-тест. Речь об инструменте для совместного программирования «Code with me». Он позволяет устраивать удаленные сессия парного программирования с совершенно новым уровнем комфорта. Несколько пользователей одновременно может писать в разных местах одного файла или в разных файлах, либо «синхронизировать» свои фокусы ввода. Плюс вы нормально видите «дерево» всего проекта, все его классы и файлы — это очень полезно и помогает в работе. Если интересно, то посмотреть можно тут.

    Конечно, для других инструментов тоже есть подобные решения. Я видел что-то похожее для Atom, Visual Studio и других. Но так как мы пользуемся продуктами JetBrains, то что-то конкретное я могу сказать только про них. Если вы пользовались решениями, похожими по описанию на «Code with me» — поделитесь в комментариях.

    Вместо морали


    Я считаю, что самое главное — это не нужно заставлять людей практиковать парное программирование, они должны прийти к этому самостоятельно. Только так разработчики смогут почувствовать плюсы и выгоды этого метода. Также надо признать, что не каждый может работать в паре, либо пару разработчику тяжело найти. Так бывает и это нормально. Люди, задействованные в парном программировании, должны «подходить» друг другу.
    Райффайзенбанк
    Развеиваем мифы об IT в банках

    Комментарии 38

      +1
      И все же мне не совсем понятно, как это организовать в моем очень частном случае.
      Большую часть времени я сижу на диване, хожу по комнате, выхожу гулять. Так было и в офисе: я сидел на бескаркасных пуфах, гулял по офису, выходил подышать воздухом. Иногда я мог подойти к доске и начать что-то писать. Конечно, может показаться, что я всячески избегал работы, но на деле мне так легче думается. Результат это всегда подтверждал. Только вот запись результата занимала 1-2 часа. Иногда это время было разбито между описанными активностями.
      Не знаю, как у других, но вот уже 6 лет я работаю именно так. Потому хотелось бы спросить у автора: есть ли возможность как-то в этом случае начать практиковать ПП?
      Также, хотелось бы спросить у хабровчан: как долго вы сидите перед компом? Как вам лучше думается?
        0
        Я, к сожалению, не смогу дать точного совета, как тебе поступить.
        Но я хотел бы напомнить, что ПП это не только непосредственное написание кода. Это инструмент, который можно использовать на разных задачах. И я думаю, что ты мог бы это попробовать стоять у доски (рисуя новую архитектуру, или алгоритм, или что-то еще) с кем-то в паре. И придумывать вместе. Это как вариант.

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

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

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

        Не нужно внедрять сверху парное программирование, те программисты, которым это подходит и которые полагают для себя этот метод не просто приемлемым, но желательным и эффективным, должны прийти к этому самостоятельно.
          +1
          Тоже попробовали «Code with me», удобная вещь, хоть и не без неприятных моментов вроде того, что у кого то может синхронизация накрыться и новые файлы не появляются (спасает переподключение). Решение на

          Если кто-то еще сможет посоветовать что-то удобное для совместной работы по SSH, вроде Team Shell (их сайт увы более не доступен, даже не успел опробовать), то буду признателен.
            0
            Да, иногда бывают «неприятные моменты». Но не стоит забывать, что пока этот продукт у них в бета-тесте. Буду надеяться, что они все недочеты подправят.
              0

              В tmux можно совместно использовать одну сессию

              +15
              Когда я был школьником у меня не было компа, и я ходил к другу у которого был. У нас были парные компьютерные игры. Он играл, а я сидел и смотрел, как он играет. Теперь мы выросли. Занимаемся парным программированием. Он кодит, а я всё так же смотрю, как он кодит :)
                0
                Lol, это парное программирование на моей памяти еще пытаются использовать еще с начала 2000-х, но так оно и не пошло в массы. А для уровня выше мидла так и вообще оно вредно. А мидлу и ниже куда полезнее кодить в одиночку, так быстрее у него идет прогресс. Опытный и дружелюбный наставник сделает прогресс еще более эффективным.
                  0
                  Да, вроде как одно их первых упоминаний про парное программирование было в книге Кента Бека «Экстремальное программирование» в 1999 году. Хотя я не готов утверждать, что это было прям первое описание этого инструмента.

                  Что же касается твоего утверждения, что ПП вредит программистам «выше мидла», то я тут не могу с тобой согласиться. Свои доводы, в чем я вижу плюсы этого инструмента, где я это использую, я написал в предыдущей статье (вначале этой статьи есть ссылка). Это мой опыт, мои наблюдения и выводы.
                  Но я бы с радостью послушал бы и твои доводы, где и как это может вредить. Возможно, я пересмотрю свои взгляды.

                  По поводу, что это не пошло в массы. Тут я скорее соглашусь. Это не используют поголовно все. Но есть очень-очень много компаний где практикуют ПП в том или ином объеме.. И в России и за рубежом.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Кто-то будет сидеть рядом со мной за моим компом, юзать мою мышку и клаву, влезать, отвлекать, не давать самому отвлекаться…

                    Парное программирование не есть работа двух и более программистов за одной машиной.

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

                    Постоянно подключенным нужно держать только на время парной работы. Никто же не обязывает всё время вместе работать. Можно разделить время совместного обсуждения/кодинга/поиска багов и т.п.
                    +1
                    Как хоть что-то понять
                      –1

                      Нужно просто включить мозг.

                      0

                      А как потом проводить perf review и как решать кого промоутить?

                        +1
                        Ну тут просто — одну зарплату делим на двоих (её и повышаем)
                          0
                          Это один из стереотипов и глубокое заблуждение, имхо, что при работе в паре ценность каждого меньше, и что каждый работает в два раза меньше.
                          Это путь про «утилизацию ресурса программиста». И если у вас это есть в команде, то это не очень хорошо, имхо.
                          0
                          1. Люди не сидят в паре весь спринт. И не делают все задачи в парах. Увидеть их индивидуальные способности не составит труда, имхо.
                          2. Работа и перформанс команды в целом — не менее важно (а чаще и больше), чем работа отдельного человека
                          3. Если человек еще берет на себя работу по обучению коллег в паре и делится знаниями (хардовыми или бизнесовыми), то это, на мой взгляд, только плюс человеку при вопросе о промоуте.
                          0
                          Хороший замысел. Я бы посоветовал для парной работы определить общую цель. Например можете придумать создать вместе какого-то бота для социальной сети. Как говорят «в интернете есть вся инфа», а то, чего нету, то подскажут на форумах. И ведомые одной целью вы будете идти по одному неразрывному пути, помогая друг другу осваивать программирование
                            +2

                            любимый стиль ;)
                            хинт: главное для штурмана — удобный диван!)

                              0
                              Обычное код ревью чем хуже?
                              Лучше асинхронностью и тем что никто не стоит над душой.
                                0

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

                                  0

                                  А что мешает ревьюеру разобраться как работает код? Или вообще запустить его, если на вид непонятно.

                                    +1

                                    Полагаю, то же, что мешает писать код не торопясь и без багов :)

                                  0
                                  Оно не лучше и не хуже. Это просто совсем другое.
                                  В предыдущей статье я рассказывал, как я вижу, какие задачи помогает решить ПП. Там есть разные кейсы по составу пар и по целям, которые могут быть достигнуты в ПП.
                                  Если очень коротко, то, во-перых, скорость — не главный показатель. Иногда мы осознано жертвуем скоростью для других «плюсов». Так как ПП это далеко не всегда про скорость.
                                  Во вторых, иногда придумать «что и как» написать занимает больше времени, чем само написание кода. И в паре порой решить сложную задачу получается быстрее.
                                  +1
                                  Мне странно, что так много негатива к парному программированию. Наверное, если на галере закрывать однообразные тикеты по пачке в день, то это не эффективно. Если задача сложная, то начинается игра в пинг-понг от стендапа к стендапу (ну, по моему опыту). И в итоге решение меняется и переменяется проходя через кучу рук и ревью. А можно двум-трём людям сесть и посмотреть на задачу вместе и подумать глубоко.

                                  У меня так существенная часть кодинга проходит. Пару часов думаем вместе. Потом можем развалиться на подзадачи (или даже альтернативные подходы попробовать) и собираемся назад. Так получается найти взвешенное решение за приемлемое время. Ну и есть облучательный бонус для новичков.
                                    0
                                    Мне странно, что так много негатива к парному программированию

                                    Вроде очевидно же — неудачный личный опыт, особенно если этот способ вводили из под палки.


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

                                      +1

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

                                    0
                                    А что с выгоранием при длительной работе в парах? Не наступит ли оно быстрее?
                                    image
                                      0
                                      Не готов говорить за всех. И какой-то статистики у меня нет.
                                      Но по моим наблюдениям все как раз наоборот. Так как есть еще некий момент поддержки и мотивации друг друга.
                                      Встречал случаи, когда человек в «одиночку» сидел со «своей задачей». И видно было, что у него чуть ли на апатия к ней… Но когда он сел в пару, сделали ее буквально за пару часов.
                                      Тут, конечно, все индивидуально сильно.
                                      Но на мой взгляд, что ПП наоборот часто помогает не выгореть.
                                      +1
                                      Огромное спасибо за статью! Я для своих студентов иногда практикую парное программирование. Кое-что для себя почерпнул новое.
                                        0
                                        Спасибо за добрые слова. Могу предложить прочитать предыдущую мою статью о плюсах парного программирования. И мою статью про новичков. Возможно, тоже что-нибудь интересное для себя найдете. Ну или наоборот, напишете с чем и почему вы не согласны, что бы я посмотрел на эти вопросы и с другой стороны.
                                          +1
                                          Уже их читаю. Сам думал что-то подобное написать, но вы успели раньше )))
                                        +1
                                        Могу написать по своему опыту (мелкие и крупные компании, в которых я работал/работаю).

                                        Вообще, когда речь заходит о любых совместных, да еще и длительных, действиях, то вперед выдвигается совместимость людей, психология, социология, и т.д., а умение программировать уходит на задний план. Программисты часто бывают интроверты и им психологически тяжело выполнять совместную работу на регулярной основе.
                                        Поэтому есть риск скатиться в ситуацию, когда кто-то один пишет одну часть, а второй другую (относительно независимую) или вообще думает о чем-то другом пока компьютер занят первым, хотя на бумаге они работают в паре — людям проще самим «поделить» задачу внутри и начать пересекаться очень слабо. Особенно опять же актуально для интровертов, которые не любят пускать посторонних в интимный процесс раздумий и попыток написания кода.
                                        Что еще? По опыту ревью (да и аудит) кода надо делать независимо, а не параллельно в паре. В паре люди проникаются общей идеей и начинают не замечать ее недочеты, и чем дальше, тем больше. Переубедить может только независимый взгляд на код человека, который желательно вообще его не писал до этого. Так что для ревью это почти никак не экономит время, а синтаксические и стилистические ошибки проще ловить разными утилитами, а не глазами людей.
                                        Про модный «онбординг» — грамотного специалиста надо учить архитектуре, основам и умению думать самостоятельно. В паре можно поработать недолго в самом начале. Иначе есть риск получить человека, который только в паре и будет способен что-то делать, а самостоятельно — не очень, потому что будет ждать совета от коллеги в паре.
                                        Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном. Во-первых, это удобнее: можно сослаться на документ, а не объяснять что-то каждый раз. Во-вторых, в этом случае новые знания охватывают сразу всех, а не только двух в паре и обсуждать на вики можно именно их, не отвлекаясь на код. А если появилось что-то действительно важное — лучше периодически устраивать внутренние «конференции» и обсуждения проблем и новых практик в коде во всей команде.
                                        Что касается сплочения коллектива — опять же спорно, что парные практики так уж сплачивают его. Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива? По моему опыту хорошо сплачивает коллектив периодические встречи (строго добровольные!) вне рабочей тематики и регулярный мониторинг настроений и возможностей коллектива и подстройка планов под эти настроения. Люди ценят, когда о них заботятся, и еще более ценят, когда эта забота пусть и скромная, но зато регулярная.

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

                                          Пару слов про твой комментарий:

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

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

                                           В паре люди проникаются общей идеей и начинают не замечать ее недочеты,

                                          Я не в коем случаи не говорю что надо отменить ревью. Но при написание кода в паре они могут замечать и отлавливать какие-то ошибки. Подсказывать более оптимальный подход или паттерн. Делиться «на лету» своим опытом.

                                          Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном. 

                                          Я согласен. Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация по всем приложениям и процессам?

                                          Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива?

                                          Нет. Не значит. Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.
                                          Совместные Тимбилдинги, походы в бар, поедания пиццы, и просто разговор по душам или помощь никто не отменял. Это всегда будет на первом месте для сплочения людей и командообразования
                                            0
                                            людей в пару надо подбирать, а не сажать случайных. Что нельзя навязывать ПП. И что вначале надо делать маленькие по времени сессии парного программирования.

                                            Это конечно так, но кто и как будет подбирать людей в пары? Только метод проб и ошибок? Слишком много факторов — строить матрицу совместимости людей? И что делать в коллективе матерых интровертов, которых от ежедневных встреч-то тошнит? Нужна мотивация для людей, а не только для тимлида.
                                            Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация

                                            Если уж совсем честно, я нигде не видел ничего идеального. ПП тоже не идеально, и уж тем более независимо от его наличия нужна и документация и ревью и все остальное — поэтому это первично, а ПП — вторично. Может конечно есть какой-то эффект от парного ревью или парного написания документации, но я не уверен.
                                            Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.

                                            Если ПП практикует только часть (и тем более не самая большая) коллектива, то это вряд ли станет дополнительным фактором сплочения. Это примерно как сказать, что курение сплачивает коллектив, потому что в курилке народ что-то дополнительно обсуждает, даже если большая часть не курит и курить никто не заставляет. Однако ж курение никто так не рекламирует для увеличения эффективности программистов :)
                                          +1
                                          Спасибо за интересную статью. У нас тоже используется Zoom, но у него не очень удобное управление чужим рабочим -скорость работы за чужим компьютером зависит от скорости канала у обоих участников, а если это еще и какой-нибудь VPN+RDP, то всё становится совсем плохо.
                                          У меня первый опыт парного программирования был еще в студенческие годы (начало 90х).
                                          Мы с другом устроились в «контору» где и компьютеров то было очень мало: днем там работали «крутые» и бухгалтера, а вечером обычно оставался один-два программиста (слова разработчик тогда еще не было), мы с другом и еще один такой же студент. Опыта программирования вообще у нас всех на тот момент было очень мало.
                                          У нас был один комп на двоих и мы писали программу по очереди. Вначале мы не очень эффективно работали: мой друг выдавал огромное количество кода и потом править, а я предпочитал писать короткий код который обдумывал и только потом писал.
                                          Но мы научились это использовать: пока мой друг писал код я придумывал алгоритмы и мы параллельно обсуждали что можно сделать лучше с точки зрения кода и скорости. Тогда в «конторе» был только один 386й и то у директора, который тоже программировал и «да» :) — это был в начале DOS и чуть позже Windows 2.0-3.11 и OS/2.
                                          Это я к тому, что даже с разными темпераментами можно работать в паре, но главное чтобы у людей не было отторжения друг от друга и сажать можно вместе не только людей с разным уровнем, но и с разным «темпераментом разработки» — это тоже помогает показать людям разные подходы и они обязательно что-то позаимствуют друг от друга.
                                          Может мой опыт и был исключением, но надеюсь, что кто-то сможет собрать пару такого же типа в своих командах.
                                            0
                                            Спасибо за интересную историю.
                                            +1
                                            Мы применяли парную работу неформально еще в первой половине 80-х.
                                            Обычно возникала потребность у младшего программера разобраться в том, что он наваял.
                                            Тогда старший садился рядом, анализировал вслух код и тут же рефакторил его, по ходу дела объясняя младшему, почему делать надо именно так.
                                            Реально получалось хорошо.

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

                                            Самое читаемое