Talk about pairing troubles as a group, and make sure the group is aware of different pairings that aren't working. That way, the group can help ensure that your pairs aren't avoiding each other. If you keep a disfunctional pair separate, they will always be disfunctional.
Get the pair to open lines of communication; try to get both sides to do new things. Assuming both people are genuinely good developers, they both have much to learn from one another. Try to alter their attitude from teacher to student.
Another approach is to continually switch your pairs within the scrum. Have a timer which might be set for 1/2/3 hours. When the bell goes off, rotate your pairs. This has a few effects:
Two people don't get stuck pairing together for a long time
Your developers will get to rotate through your current stories, getting familiar with each one and different areas of the code
If one of your dev's smells, you will only have to get through a short period of stink!
Pairing is a critical practice for an agile team. To begin with, it is best to identify developers that are willing and able to work effectively in pairs. One company I am aware of does extreme interviewing. That is, they will interview candidates in pairs giving them a problem to solve. They are interested if the developers are ability to solve the problem but are interested in their collaboration skills. Only those that can work well with others are considered.
It is not a requirement that all pair like each other. What is important is that they are effective. Given that pairs rotate frequently (for each card or more frequently), personality is less of an issue. If someone is not across pairs, and after being coached is still a problem, he or she should be asked to leave the team.
I'd second muloh's question - what kinds of thing are they having problems with?
In my experience these problems are often (but not always) a sign of underlying problems with the team structure / skills / relationships that need to be addressed if you want to get the best out of everybody involved.
Is Mary not getting along with Fred because Fred doesn't know enough about how sane folk work with databases? Is Fred not getting along with Jo because Jo doesn't bathe quite as regularly as they ought? Is Jo not getting along with Mary because Mary is a rude SOB? If so you can almost guarantee that Fred, Jo & Mary are also annoying the rest of the team in similar ways.
Just coz one or two folk push the issue enough to avoid pairing doesn't mean the problems goes away. It may well be annoying other folk too - they may have alternate ways of coping. Like looking for alternate employment for example :-)
If the team doesn't work well together it isn't a team.
Out of curiosity - how long are your pairing sessions and how often do you switch pairs? I find that it's sometimes easier to deal with this sort of thing if folk are switching pairs on a regular basis - once or twice a day. That way everybody gets to share the relative pros and cons of everybody on the team - which can help everybody focus on solving some of the cons.
Pair programming is based on the idea that the interaction of two programmers adds value. If this is not true, change the pairs... let them choose. Programming should be fun!
How about rotating the pairs every week or every sprint so that if there are issues between a couple of pairs they don't feel like it has to be that way forever. I think if there is a specific time frame that you have to work with someone you do not get along with it makes it easier to "suck it up" and hopefully you won't lose any great people that way.
If after a few rotations you notice a specific individual that nobody is enjoying it may be appropriate to focus on adjusting the way that individual interacts with the team or if it continues perpetually removing them from the team all together.
What exactly are they having problems with? Do they not get along, not understand each other? Are they at different levels of programming experience?
It may help if you have a team member that can act as a "mediator" of sorts. Somebody who's successfully done pair-programming in the past and can help the two through their first few times together.
The first step to resolving conflicts is to recognize that people are different. Even the most mild mannered programmer's patience can be tried in pair programming, it can be very stressful. Some people withdraw when they are confronted by conflict, others get aggressive.
The best way of approaching pair programming, in my experience, is to have a detailed discussion of what it is you want to accomplish for the session, before you lay hands on code. This will put both of your minds on the same track. When you disagree on something, stop coding, discuss it away from the computer, try to find common ground and most importantly don't dismiss any ideas your partner may have. Take breaks; don't work for 2 hours straight, try to stand up or go for a break every 45 minutes or so.
发布评论
评论（9）
以小组形式讨论配对问题，并确保小组意识到不同的配对方式不起作用。 这样，小组就可以帮助确保你们的搭档不会互相回避。 如果你把一对功能失调的人分开，它们将永远是功能失调的。
让两人畅通沟通渠道； 尝试让双方都做新的事情。 假设这两个人都是真正优秀的开发人员，那么他们都有很多东西可以互相学习。 尝试改变他们对老师对学生的态度。
Talk about pairing troubles as a group, and make sure the group is aware of different pairings that aren't working. That way, the group can help ensure that your pairs aren't avoiding each other. If you keep a disfunctional pair separate, they will always be disfunctional.
Get the pair to open lines of communication; try to get both sides to do new things. Assuming both people are genuinely good developers, they both have much to learn from one another. Try to alter their attitude from teacher to student.
另一种方法是在 scrum 中不断交换你们的搭档。 有一个可以设置为 1/2/3 小时的计时器。 当铃声响起时，轮流配对。 这会产生一些影响：
Another approach is to continually switch your pairs within the scrum. Have a timer which might be set for 1/2/3 hours. When the bell goes off, rotate your pairs. This has a few effects:
结对是敏捷团队的关键实践。 首先，最好确定愿意并且能够有效地结对工作的开发人员。 据我所知，有一家公司进行极端面试。 也就是说，他们将两人一组面试候选人，给他们一个需要解决的问题。 他们对开发人员是否有能力解决问题感兴趣，但对他们的协作技能感兴趣。 只有那些能够与他人良好合作的人才会被考虑。
并不要求所有人都彼此喜欢。 重要的是它们是有效的。 鉴于配对频繁轮换（每张牌或更频繁），个性就不再是问题。 如果有人没有跨过双人组，经过辅导后仍然存在问题，就应该要求他或她离队。
Pairing is a critical practice for an agile team. To begin with, it is best to identify developers that are willing and able to work effectively in pairs. One company I am aware of does extreme interviewing. That is, they will interview candidates in pairs giving them a problem to solve. They are interested if the developers are ability to solve the problem but are interested in their collaboration skills. Only those that can work well with others are considered.
It is not a requirement that all pair like each other. What is important is that they are effective. Given that pairs rotate frequently (for each card or more frequently), personality is less of an issue. If someone is not across pairs, and after being coached is still a problem, he or she should be asked to leave the team.
我想问一下 muloh 的问题——他们遇到了什么问题？
根据我的经验，这些问题通常（但并非总是）表明团队结构/技能/关系存在潜在问题，如果您想充分发挥每个参与人员的作用，就需要解决这些问题。
玛丽和弗雷德相处不好是因为弗雷德对正常人如何使用数据库了解不够吗？ 弗雷德和乔相处不好是因为乔没有像他们应该的那样经常洗澡吗？ 乔和玛丽相处不好是因为玛丽是个粗鲁的混蛋吗？ 如果是这样，你几乎可以保证弗雷德、乔和 玛丽也以类似的方式惹恼了团队的其他成员。
仅仅因为一两个人将这个问题推到足以避免配对并不意味着问题就消失了。 这很可能也会让其他人烦恼——他们可能有其他的应对方式。 例如寻找替代工作:-)
如果团队不能很好地合作，那么它就不是一个团队。
出于好奇 - 你们的配对时间有多长以及你们多久换一次配对？ 我发现，如果人们定期交换配对（每天一次或两次），有时处理此类事情会更容易。 这样，每个人都可以分享团队中每个人的相对优缺点 - 这可以帮助每个人专注于解决一些缺点。
I'd second muloh's question - what kinds of thing are they having problems with?
In my experience these problems are often (but not always) a sign of underlying problems with the team structure / skills / relationships that need to be addressed if you want to get the best out of everybody involved.
Is Mary not getting along with Fred because Fred doesn't know enough about how sane folk work with databases? Is Fred not getting along with Jo because Jo doesn't bathe quite as regularly as they ought? Is Jo not getting along with Mary because Mary is a rude SOB? If so you can almost guarantee that Fred, Jo & Mary are also annoying the rest of the team in similar ways.
Just coz one or two folk push the issue enough to avoid pairing doesn't mean the problems goes away. It may well be annoying other folk too - they may have alternate ways of coping. Like looking for alternate employment for example :-)
If the team doesn't work well together it isn't a team.
Out of curiosity - how long are your pairing sessions and how often do you switch pairs? I find that it's sometimes easier to deal with this sort of thing if folk are switching pairs on a regular basis - once or twice a day. That way everybody gets to share the relative pros and cons of everybody on the team - which can help everybody focus on solving some of the cons.
结对编程基于两个程序员的交互增加价值的理念。 如果情况并非如此，请更换配对...让他们选择。 编程应该很有趣！
Pair programming is based on the idea that the interaction of two programmers adds value. If this is not true, change the pairs... let them choose. Programming should be fun!
每周或每次冲刺轮换一下配对怎么样，这样如果一对之间出现问题，他们就不会觉得必须永远这样。 我认为，如果有一个特定的时间框架，你必须与一个你不合群的人一起工作，这会让你更容易“忍气吞声”，希望你不会因此失去任何优秀的人。
如果经过几次轮换后，您发现没有人喜欢某个特定的个人，那么可能需要集中精力调整该个人与团队互动的方式，或者如果这种情况继续永久地将他们从团队中删除，则可能是适当的。
How about rotating the pairs every week or every sprint so that if there are issues between a couple of pairs they don't feel like it has to be that way forever. I think if there is a specific time frame that you have to work with someone you do not get along with it makes it easier to "suck it up" and hopefully you won't lose any great people that way.
If after a few rotations you notice a specific individual that nobody is enjoying it may be appropriate to focus on adjusting the way that individual interacts with the team or if it continues perpetually removing them from the team all together.
他们究竟遇到了什么问题？ 难道他们不合得来，互相不理解吗？ 他们的编程经验水平是否不同？
如果您有一个可以充当某种“调解人”的团队成员，这可能会有所帮助。 过去成功完成结对编程的人可以帮助两人度过最初的几次合作。
What exactly are they having problems with? Do they not get along, not understand each other? Are they at different levels of programming experience?
It may help if you have a team member that can act as a "mediator" of sorts. Somebody who's successfully done pair-programming in the past and can help the two through their first few times together.
解决冲突的第一步是认识到人与人之间是不同的。 即使是最温和的程序员的耐心也会在结对编程中受到考验，这可能会带来很大的压力。 有些人在遇到冲突时会退缩，而另一些人则会变得咄咄逼人。
根据我的经验，进行结对编程的最佳方法是在动手编写代码之前详细讨论您想要在会话中完成的任务。 这将使你们双方的想法处于同一轨道上。 当您对某件事有不同意见时，请停止编码，远离计算机进行讨论，尝试找到共同点，最重要的是不要忽视您的合作伙伴可能有的任何想法。 休息一下; 不要连续工作 2 小时，尝试每隔 45 分钟左右站起来或休息一下。
The first step to resolving conflicts is to recognize that people are different. Even the most mild mannered programmer's patience can be tried in pair programming, it can be very stressful. Some people withdraw when they are confronted by conflict, others get aggressive.
The best way of approaching pair programming, in my experience, is to have a detailed discussion of what it is you want to accomplish for the session, before you lay hands on code. This will put both of your minds on the same track. When you disagree on something, stop coding, discuss it away from the computer, try to find common ground and most importantly don't dismiss any ideas your partner may have. Take breaks; don't work for 2 hours straight, try to stand up or go for a break every 45 minutes or so.
重新评估您的招聘实践，并确保选择以团队为导向的员工。
如果做不到这一点，呼吸薄荷味。
-亚当
Reassess your hiring practices and make sure that you select for team oriented employees.
Failing that, breath mints.
-Adam