Обмен парами: каковы плюсы и минусы?


15

Общая идея, поддерживаемая большинством теоретиков Agile / XP , заключается в том, что пары должны регулярно меняться местами. Например, каждый программист должен менять пары один раз в день; половина людей меняет местами в начале дня, половина людей меняет местами после обеда: из-за внешних факторов, таких как встречи, праздники и т. п., большинство людей склонны менять время обмена один или два раза в неделю, чтобы парные конфигурации распределялись довольно равномерно по всей команде.

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

Оба утверждения звучат разумно; с точки зрения менеджмента это звучит так, как будто вы получаете повышение как стабильности, так и качества, и, как следствие такого частого обмена, это в значительной степени стандартная теория в большинстве книг по Agile / XP, на которые я смотрел.

Итак, когда на самом деле применяются на практике, что люди на самом деле думают о парном обмене с

  • Точка зрения программиста?
  • Точка зрения менеджера?

И

  • Что должно определить, когда кто-то поменяется с / на пару?

Это то же самое, что и "Программирование пар"?
Роберт Харви

@ Роберт Харви - Ну, это один из аспектов парного программирования. Как только команда решает, что она будет программировать в парах (для некоторой части своего рабочего дня), тогда им нужно решить, как расположить программистов в пары, то есть, когда один программист должен оставить пару (другой должен присоединиться одновременно ). Это «Обмен парами».

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

2
Я лично нашел бы, что обмен пары очень отвлекает. Попытка справиться с таким большим количеством разных личностей и уровней квалификации в таких тесных кругах привела бы к слишком большому когнитивному диссонансу.
Роберт Харви

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

Ответы:


4

Парное программирование сложно.

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

Я обнаружил, что даже в средах, где выполняется сопряжение, обмен парами не стоит затрат. Однако это может быть связано с тем, что наши задачи никогда не занимают более 1,5 дней. Мы нашли большое преимущество в том, чтобы разбивать задачи не более чем на 1,5 дня работы. Обмен парами может иметь больше смысла в контексте более длительных задач.


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

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

@ Уильям Пьетри: По моему опыту, спаривание не очень хороший формат для обучения. У меня нет проблем с тем, чтобы взять кого-то и пройтись по коду, чтобы объяснить им, что происходит. Однако это не парное программирование.
dietbuddha

@jwenting: Если вы говорите, что парное программирование не будет хорошо работать в магазинах, которые фокусируются на крайних сроках, касающихся качества и устойчивости, я бы не стал спорить. Мой совет: работай где-нибудь, что не безумие.
Уильям Пьетри

@dietbuddha: работает для меня! Самый быстрый способ для меня выучить новый язык, структуру или библиотеку - это общаться с людьми, которые хорошо это знают. И я не знаю лучшего способа увеличить скорость, чем спаривание. Например, этот опыт приобретает
Уильям Пьетри,

3

Я и программист, и менеджер. Вот мой дубль:

Регулярная замена это здорово. Я предпочитаю обмениваться 2-4 раза в день, что примерно так же быстро, как я думаю, вы можете пойти. Для нас это происходит в естественных переломных моментах: обычно обед и полдень. Менять каждый день или два, наверное, хорошо, но я бы беспокоился о том, чтобы идти намного дольше. (Я слышал об одном месте, которое обменивается так же редко, как каждые шесть недель, что, на мой взгляд, безумие; после такого большого количества времени вместе вы будете готовы нанести удар святому.)

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

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

Что касается того, кто остается с текущей работой, я чувствую, что это в основном зависит от вовлеченных людей. Иногда вы хотите что-то увидеть, а иногда вы готовы к переменам. Мы также иногда обмениваемся, чтобы привнести опыт, или чтобы кто-то мог узнать что-то, в чем он заинтересован. Мы стараемся, чтобы наши единицы работы были довольно небольшими (0,5-2,0 пары дней), так что это не имеет большого значения, однако обмен происходит ,


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

@B Тайлер - Я думаю, кодовая база - это совместная интеллектуальная работа, поэтому у вас должно быть четкое видение, которое также является общим видением. Это одна из причин, почему я думаю, что важно поменяться местами: требуется много взаимодействия и дискуссий, чтобы выработать солидный общий подход.
Уильям Пьетри

1

Хорошо, здесь идет ответ от самопровозглашенного прагматичного программиста Agile / XP. Я занимаюсь парным программированием уже более двух лет. Если парное программирование хорошо, меняйте пары часто (в идеале каждые два часа, если не каждые полдня). В нашем офисе мы рекомендуем менять пары каждый день (обычно) или каждые два дня (в худшем случае). Выполнение этого само по себе может дать нам большую уверенность в качестве кода, который мы фиксируем и изучаем или отнимаем, который мы имеем при каждой ротации пары (мы знаем, что проверка кода хороша, чем больше, тем лучше и чем раньше, тем лучше. Это то, чего достигает «парное программирование, включая практику обмена парами» .

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

Я был свидетелем и испытал это. Теперь я его евангелист. Это не теория. Скорее прагматично :) Счастливое соединение в пинг-понге и обмен парами.


1
Увы, теперь я полностью убежден в том, что парное программирование вообще плохая идея; частый обмен парами в парном программировании только усугубляет ситуацию. Я слышал всю теорию и много пробовал на практике, и я просто думаю, что она невероятно неэффективна, намного скучнее и разочаровывает, чем одиночное программирование, и приводит к снижению качества кода.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.