在以后，当尘埃落定时，您会发现数百行甚至数千行代码可能没有编写，因为有人不了解库 X 或技术 Y. 配对改善这个问题，但并不能消除它。 它鼓励个人和两人在陷入盲目的代码兴奋之前做更多的研究。
我希望我能够配对更多......
How do you know your unpaired programmers are any more efficient ? I sometimes think the single/pair is comparable to the old fairytale of the rabbit and the tortoise.
Pairing doesn't drift off into days of counter-productive work. I have no idea of how often I've seen developers spending weeks working on stuff that later turns out to be replaced by something far simpler. The single programmer "in the zone" often does stupid things. It's just too easy to produce too much code, when what you want is more punch with less code.
And in posterity, when the dust settles, you find hundreds, if not thousands of lines of code that could have been not written because someone didn't know about library X or technique Y. Pairing improves this problem, but does not remove it. It encourages both individuals and the pair to do more research before diving into mindless code euphoria.
We use this approach in our company, but only for the difficult tasks or when you're unsure about something someone else has worked on already which I believe works very well. It saves you getting stuck in a rut and being able to bounce ideas off people where necessary while still being able to work independently for most simple tasks.
I also believe it is more beneficial than a code review, which is something else we do where I work. It is often difficult to know fully what's going on when doing a code review without providing significant context, at which point you don't always have the time to think about all the in's and out's. Pair programming gives you that context from the start and allows you to spend more time thinking about edge cases that may or may not cause problems.
基本上，您需要评估您正在处理的代码。 简单的任务通常不值得花钱请人来监督你并确保你正确地编写了 for 循环。 然而，在某些阈值上，任务足够复杂，使得结对编程的投资回报率是合理的。
Although I agree with most of the response so far about pair programming being a good thing, I will play devil's advocate and argue that it doesn't always make sense.
When you pair you don't get a programmer that's got twice the brains. You get a programmer that's the union of both of your brains. So basically any time that I screw up and my partner catches or finds some way better, it's a plus. However, any time that I write the correct code on my own is a waste of money since my partner wasn't needed.
Basically, you need to evaluate the code you're working on. Simple tasks are usually not worth the money to pay someone to sit over shoulder and make sure you wrote your for loop correctly. However, at some threshold, the tasks are complicated enough to make the roi for pair programming justifiable.
It does not mean double the cost if it takes less than 1/2 the time it would have taken with one dev. I think on difficult or low-level tasks this would be helpful. I find that it's worth it because you've got someone to say "no, don't do THAT!" long before it ends up in production code where it will REALLY cost you time and money.
I've written operating systems and things of that nature where it was invaluable that someone was sitting next to me to double check my logic.
It's hard to say - I've spent a lot of time working in a force-paired environment and also in a pairing-optional environment. The highest quality code I've seen is not in the paired environment. That probably has more to do with the caliber and discipline of the individual developers. Sometimes you'll get your money's worth from pairing, especially where some of the coders are not top-tier. But if all the coders are experienced, well-disciplined coders, you're just wasting your money if they're pairing all the time.
One type of experience that I've had multiple times that has a huge impact on my coding discipline and the quality of product I produce is this: carrying a pager. When I have to support a system for which I code, it changes how I code. That is, I code in such a way as to keep that pager from going off. The result is a better quality product, and typically better code quality, too. The coders I've seen that have never carried a pager produce code that's more fragile. It's not something that they can even understand and improve upon until they've been on support.
在工作中我们一直采用结对编程的方式。 诀窍是要知道哪些任务应该结对完成，哪些任务如果由两个开发人员完成会“浪费时间”。 经验法则是，更多以研究为导向的任务（即 POC 和峰值）以及新功能的开发应该成对完成（以便知识将存在于多个头脑中）。 更平凡的任务（例如 CI 服务器安装或插件图标替换）由单个开发人员完成。 另一个因素是团队成员当前的可用性以及当前迭代中要完成的任务。
At work we use pair programming all the time. The trick is to know which tasks should be done in pair and which would be a "waste of time" if done by two developers. The rule of the thumb is that tasks that are more research oriented (i.e. POCs & spikes) should be done in pairs as well as development of new features (so that the knowledge will exist in more than one mind). Tasks that are more mundain such as CI server installation or replacement of the addon icons is done by a single developer. Another factor is the current availability of team members and the current tasks to be done at that iteration.
Pair programming can be amazingly effective, however you shouldn't be hiring programmers in pairs. You can't force developers to pair program. It only works when two developers click and decide they can learn from each other and build something awesome together. My advice is to hire as many of the smartest developers you can find and put them in a setting that naturally lends itself to encouraging part-time pair programming. Developers need to be able to code alone, but also talk to others on the team about it.
Finding the right mix that works for you and your company will be more art than science, and certainly not something you can do by blindly following the demands of some published methodology.
That said, the more bugs you squash before they ever get checked in, the more you save in the long run. Having another developer looking on as you architect something will always be more effective than having a tester black-box it afterward. I'd call it money well spent.
The sooner a bug/defect is found the cheaper it is to fix, so using the money to hire more qa people vs another developers, is going to cost you more time/money because of how many trips from DEV to QA.
Having said this, pair programing don't work with everyone, some developers don't pair well, they distract each other, spend all their time fighting, etc.
If you have developers that can pair program, it can be more then beneficial in the long run when you add in more maintainable code, lower defects so less time in QA, and most importantly if one of the developers get hit by a bus, you don't have to wait for someone to come up to speed on a project before any more work can be done on it.
If your developers can't pair program don't force them into it, all you're going to do is waste time and money.
The first assumption one makes with pair programming is that a story card will cost twice a much to develop. The assumption is faulty. Here is why?
Improved quality: A pair of active programmers working on the same story card will complete the card with less defects
Improved productivity: a pair is less likely to be slowed down if not outright blocked when solving a problem. Furthermore, it is harder to take an email or web vacation when you are working with a partner ... you don't want to let the partner down. You will solve the problem with a cleaner design and less lines of code when working as a pair
Eliminate silos of knowledge: With rotating pairs, you will learn application and domain business knowledge across the team. The team is less likely to be blocked because Sue when on vacation and no one else knows her code.
Knowledge Transfer: Rotating pairs teach new skills (engineering and domain) to each other as they work together. The level of the team will rise for everyone and the knowledge propagates through the team.
Team self selects: The team learns one anther's skills and will quickly weed out someone that is not performing.
From actual experience we have seen defect drop significantly. New team members can be added without slowing down the team (try that with a non-paired team). For a trial, one team estimated the work for a set of story cards as if six single developers would complete the code individually. The six developer were then told to pair. They completed the work on time with high quality. If you don't pair, you are spending to much time to deliver to little quality, you have no way to scale and you have too many silos of expertise.
In a second example, we estimated to complete the work in the time requested we would need to take a team from 4 pairs to 7 pairs. We gave ourselves 1 month to on board the new pairs. We paired a new developer with an experienced developer and rotated the pairs across story cards. The team hit all deliverables with quality in the time planned. Without pairing one could not have added 6 developers to a team of 8 developers and hit the mark!
Bottom line, you will save money with pairing. You will take about the same time, delivery with higher quality, improve the teams performance, skills and knowledge and weed out the dead wood. Your savings will come with sustainable pace and significantly fewer defects in the way to slow the team down.
Pair programming doesn't double the cost - it just halves the amount of typing. Typing isn't programming. Completing the functionality in the software is programming. It's problem solving. You can't just measure it in lines of code typed. Some programmers will use a better algorithm so they end up typing less.
How would you define value for money? Possibly total time elapsed between start of coding and completed, working feature in live?
The cost of not pairing isn't often counted correctly: The problem is that most people don't measure the number of defects or the amount of extra time taken to fix work that wasn't completed properly in the first place - they just measure the time taken to "throw the work over the fence" in the first place.
There are a few attempts at measuring productivity when paring, but unfortunately it gets a bit tied up with "number of lines of code delivered" - which is a bogus metric.
The premise is that your productivity more than doubles. Part of the gain is realized right away (e.g., before code is checked in) and part is realized further on, when there are fewer bugs and failures.
When I teach students with two semesters' experience, for most pairs their productivity more than doubles because they ask each other questions and they learn and finish faster. But it's not universally true; a badly matched pair can take longer and do worse than the more skilled half.
Quality management experience from other many industries teaches us that defect prevention is cheaper in the long run than defect detection (also known as QA) and subsequent fixing.
They also learned that the long run ranges in most cases from 1 to 2 years, which means that your investment pays off after that. Considering that investments on that scale are usually expected to reach a break even after 4 years, this is pretty good!
The problem is that it took the other industries several decades to accumulate enough data for being able to prove that this is the case for them. You can easily find data to support their conclusion and draw a conclusion for software in analogy to that, but as of today, there is no proof for the software business.
That being said, I believe that the analogous conclusion is valid: A pair of developers and one tester are more productive than one developer and two testers.
If you have problems justifying two expensive developers sitting in front of one computer to the managament, there are many other things that help with defect prevention, but are not as visible (and therefore irritating) to the management.
When I am programming on my friend's boat we don't always have time because one of us is sailing it while the other is coding. However, when we are anchored or in calm water we can do pair programming and it works fine.
No way man! in the company i'm working we practice a lot of pair-programming! it gets things done really fast and really efficiently! just make a try! you will valuate it later!
Professor Laurie Williams from NC State is the primary authority in academia about the effectiveness of pair programming, she did a whole bunch of studies on this.
If you want the "official word", visit her publication list.
Her article: "Strengthening the Case for Pair-Programming" is extremely famous.
It depends on the developers. Unfortunately, you can't just stick any two developers together and expect timely, high quality results. Not everybody is cut out for paired programming or even cut out for working in an agile development environment. Two things about paired programming that I think make it worth while are : (1) Cross-training between developers; and (2) Real-time peer reviews. Cross-training will help to strengthen the skills of the team as a whole, and real-time peer reviews can eliminate the need for formal peer reviews. I've learned more from my peers over the years than I ever learned at a technical training.
Unless you are a very tiny shop, you are probably already paying the salaries of two programmers. Pair programming is just a way to (theoreticaly) get more debugged and working software out of those two in the same amount of time.
It's not a black and white thing or a silver bullet of any kind, the concept of pair programming.
Pair programming is generally extremely efficient for various reasons, but done right it's also very exhausting (in my opinion any way) - meaning a good pair might pair program a few hours a day at most. This should be encouraged, of course, but not mandated and especially not mandated at 100% time because that seems hard to manage (with sustained efficiency and no beer anyway).
So, pair programming is just one way of approaching a problem, and I find it hard to look at it from the question's perspective. It's not like you need to hire twice as many developers for this. It's like wondering if it's worth hiring a message boy/girl to have two employees in the same department talk to each other... when the obvious solution is to have them talk to each other directly without an additional messenger.
I haven't done the stats--and I suspect you'd have a hard time doing a statistically valid study--but keep in mind the ostensible objective of producing working, error-free code--not just quantity of code. A good pair should be able to create at least as much correct code as two programmers working separately.
发布评论
评论（21）
你怎么知道不配对的程序员效率更高？ 我有时觉得单/对可以与兔子和乌龟的古老童话相媲美。
结对工作不会导致日复一日的适得其反的工作。 我不知道我有多少次看到开发人员花费数周的时间来开发一些东西，但后来却被更简单的东西所取代。 “在该区域”的单个程序员经常会做一些愚蠢的事情。 当您想要用更少的代码获得更多功能时，很容易生成太多代码。
在以后，当尘埃落定时，您会发现数百行甚至数千行代码可能没有编写，因为有人不了解库 X 或技术 Y. 配对改善这个问题，但并不能消除它。 它鼓励个人和两人在陷入盲目的代码兴奋之前做更多的研究。
我希望我能够配对更多......
How do you know your unpaired programmers are any more efficient ? I sometimes think the single/pair is comparable to the old fairytale of the rabbit and the tortoise.
Pairing doesn't drift off into days of counter-productive work. I have no idea of how often I've seen developers spending weeks working on stuff that later turns out to be replaced by something far simpler. The single programmer "in the zone" often does stupid things. It's just too easy to produce too much code, when what you want is more punch with less code.
And in posterity, when the dust settles, you find hundreds, if not thousands of lines of code that could have been not written because someone didn't know about library X or technique Y. Pairing improves this problem, but does not remove it. It encourages both individuals and the pair to do more research before diving into mindless code euphoria.
I wish I was able to pair more....
我们在公司中使用这种方法，但仅适用于困难的任务，或者当您不确定其他人已经做过的事情时，我认为这种方法非常有效。 它可以帮助您避免墨守成规，并能够在必要时向人们征求想法，同时仍然能够独立完成大多数简单的任务。
我还相信它比代码审查更有益，这是我们在工作中所做的其他事情。 在进行代码审查时，如果不提供重要的上下文，通常很难完全了解发生了什么，此时您并不总是有时间考虑所有的细节。 结对编程从一开始就为您提供了这种背景，并允许您花更多时间思考可能会或可能不会导致问题的边缘情况。
We use this approach in our company, but only for the difficult tasks or when you're unsure about something someone else has worked on already which I believe works very well. It saves you getting stuck in a rut and being able to bounce ideas off people where necessary while still being able to work independently for most simple tasks.
I also believe it is more beneficial than a code review, which is something else we do where I work. It is often difficult to know fully what's going on when doing a code review without providing significant context, at which point you don't always have the time to think about all the in's and out's. Pair programming gives you that context from the start and allows you to spend more time thinking about edge cases that may or may not cause problems.
尽管我同意迄今为止关于结对编程是一件好事的大多数回应，但我会唱反调并认为它并不总是有意义。
当你结对时，你不会得到一个拥有双倍大脑的程序员。 你得到的程序员是你两个大脑的联合。 所以基本上任何时候我搞砸了而我的伴侣发现或找到了更好的方法，这都是一个优点。 然而，任何时候我自己编写正确的代码都是浪费金钱，因为不需要我的合作伙伴。
基本上，您需要评估您正在处理的代码。 简单的任务通常不值得花钱请人来监督你并确保你正确地编写了 for 循环。 然而，在某些阈值上，任务足够复杂，使得结对编程的投资回报率是合理的。
Although I agree with most of the response so far about pair programming being a good thing, I will play devil's advocate and argue that it doesn't always make sense.
When you pair you don't get a programmer that's got twice the brains. You get a programmer that's the union of both of your brains. So basically any time that I screw up and my partner catches or finds some way better, it's a plus. However, any time that I write the correct code on my own is a waste of money since my partner wasn't needed.
Basically, you need to evaluate the code you're working on. Simple tasks are usually not worth the money to pay someone to sit over shoulder and make sure you wrote your for loop correctly. However, at some threshold, the tasks are complicated enough to make the roi for pair programming justifiable.
通过结对编程，您可以结合：
您不会比这更容易获得如此多的投资回报。
话又说回来，您不应该将它用于所有任务。
With pair programming, you combine:
You won't get that much return on investment easier than that.
Then again, you shouldn't use it for all tasks.
如果所需时间不到一个开发人员所需时间的 1/2，这并不意味着成本翻倍。 我认为对于困难或低级别的任务这会很有帮助。 我发现这是值得的，因为有人会说“不，不要这样做！” 早在它最终进入生产代码之前，它就会真正花费你的时间和金钱。
我写过操作系统和类似的东西，有人坐在我旁边仔细检查我的逻辑是非常宝贵的。
It does not mean double the cost if it takes less than 1/2 the time it would have taken with one dev. I think on difficult or low-level tasks this would be helpful. I find that it's worth it because you've got someone to say "no, don't do THAT!" long before it ends up in production code where it will REALLY cost you time and money.
I've written operating systems and things of that nature where it was invaluable that someone was sitting next to me to double check my logic.
很难说 - 我花了很多时间在强制配对环境和可选配对环境中工作。 我见过的最高质量的代码不是在配对环境中。 这可能与单个开发人员的能力和纪律有更多关系。 有时，结对会让你的钱物有所值，特别是当一些编码员不是顶级的时候。 但是，如果所有编码员都是经验丰富、纪律严明的编码员，那么如果他们一直一直配对，那么您就是在浪费钱。
我曾多次经历过的一种对我的编码纪律和我生产的产品质量产生巨大影响的经历是：携带寻呼机。 当我必须支持我编码的系统时，它会改变我的编码方式。 也就是说，我以防止寻呼机关闭的方式进行编码。 其结果是产品质量更高，而且代码质量通常也更好。 我见过从未携带过寻呼机的编码员，他们生成的代码更加脆弱。 在获得支持之前，他们甚至无法理解和改进这一点。
It's hard to say - I've spent a lot of time working in a force-paired environment and also in a pairing-optional environment. The highest quality code I've seen is not in the paired environment. That probably has more to do with the caliber and discipline of the individual developers. Sometimes you'll get your money's worth from pairing, especially where some of the coders are not top-tier. But if all the coders are experienced, well-disciplined coders, you're just wasting your money if they're pairing all the time.
One type of experience that I've had multiple times that has a huge impact on my coding discipline and the quality of product I produce is this: carrying a pager. When I have to support a system for which I code, it changes how I code. That is, I code in such a way as to keep that pager from going off. The result is a better quality product, and typically better code quality, too. The coders I've seen that have never carried a pager produce code that's more fragile. It's not something that they can even understand and improve upon until they've been on support.
在工作中我们一直采用结对编程的方式。
诀窍是要知道哪些任务应该结对完成，哪些任务如果由两个开发人员完成会“浪费时间”。
经验法则是，更多以研究为导向的任务（即 POC 和峰值）以及新功能的开发应该成对完成（以便知识将存在于多个头脑中）。
更平凡的任务（例如 CI 服务器安装或插件图标替换）由单个开发人员完成。
另一个因素是团队成员当前的可用性以及当前迭代中要完成的任务。
At work we use pair programming all the time.
The trick is to know which tasks should be done in pair and which would be a "waste of time" if done by two developers.
The rule of the thumb is that tasks that are more research oriented (i.e. POCs & spikes) should be done in pairs as well as development of new features (so that the knowledge will exist in more than one mind).
Tasks that are more mundain such as CI server installation or replacement of the addon icons is done by a single developer.
Another factor is the current availability of team members and the current tasks to be done at that iteration.
不，你不知道。 每个程序员仍然只能拿到一份薪水。
你认为如果你不称之为“结对编程”，你的程序员就不会互相交谈吗？ 您认为编程是完全可并行的吗？
No, you don't. Each programmer still gets exactly one salary.
Do you think your programmers won't talk to each other if you don't call it "pair programming"? Do you think programming is perfectly parallelizable?
结对编程可以非常有效，但是您不应该结对雇用程序员。 你不能强迫开发人员结对编程。 只有当两个开发人员点击并决定他们可以互相学习并共同构建一些很棒的东西时，它才有效。 我的建议是雇佣尽可能多的最聪明的开发人员，并将他们安置在一个自然适合鼓励兼职结对编程的环境中。 开发人员需要能够单独编码，但也需要与团队中的其他人讨论。
找到适合您和您的公司的正确组合更像是一门艺术，而不是一门科学，而且肯定不是盲目遵循某些已发表的方法论的要求就能做到的。
也就是说，在检查之前消灭的错误越多，从长远来看，您节省的时间就越多。 当你构建某些东西时，让另一位开发人员在旁看着总是比事后让测试人员对它进行黑盒更有效。 我认为这钱花得值。
Pair programming can be amazingly effective, however you shouldn't be hiring programmers in pairs. You can't force developers to pair program. It only works when two developers click and decide they can learn from each other and build something awesome together. My advice is to hire as many of the smartest developers you can find and put them in a setting that naturally lends itself to encouraging part-time pair programming. Developers need to be able to code alone, but also talk to others on the team about it.
Finding the right mix that works for you and your company will be more art than science, and certainly not something you can do by blindly following the demands of some published methodology.
That said, the more bugs you squash before they ever get checked in, the more you save in the long run. Having another developer looking on as you architect something will always be more effective than having a tester black-box it afterward. I'd call it money well spent.
越早发现错误/缺陷，修复的成本就越低，因此与其他开发人员相比，使用这笔钱雇用更多的质量保证人员会花费您更多的时间/金钱，因为从开发到质量保证的往返次数较多。
话虽如此，结对编程并不适合所有人，有些开发人员结对不好，他们会互相分散注意力，把所有的时间都花在争吵上，等等。
如果你有可以结对编程的开发人员，那么它在以下方面可能会更有好处：从长远来看，当您添加更多可维护的代码时，缺陷会减少，从而减少质量检查的时间，最重要的是，如果其中一位开发人员被公共汽车撞了，您不必等待某人加快项目进度在对其进行更多工作之前。
如果您的开发人员无法结对编程，请不要强迫他们，您要做的就是浪费时间和金钱。
The sooner a bug/defect is found the cheaper it is to fix, so using the money to hire more qa people vs another developers, is going to cost you more time/money because of how many trips from DEV to QA.
Having said this, pair programing don't work with everyone, some developers don't pair well, they distract each other, spend all their time fighting, etc.
If you have developers that can pair program, it can be more then beneficial in the long run when you add in more maintainable code, lower defects so less time in QA, and most importantly if one of the developers get hit by a bus, you don't have to wait for someone to come up to speed on a project before any more work can be done on it.
If your developers can't pair program don't force them into it, all you're going to do is waste time and money.
人们对结对编程所做的第一个假设是，开发一张故事卡的成本是原来的两倍。 这个假设是错误的。 这是为什么呢？
从实际经验来看，我们看到缺陷显着下降。 可以添加新的团队成员，而不会减慢团队的速度（尝试使用非配对团队）。 在试验中，一个团队估计了一组故事卡的工作量，就好像六个开发人员单独完成代码一样。 然后，六名开发人员被告知结对。 他们按时高质量地完成了工作。 如果你不结对，你就会花费大量时间来交付低质量的产品，你无法扩展，而且你会有太多的专业知识孤岛。
在第二个示例中，我们估计要在要求的时间内完成工作，我们需要将团队人数从 4 对减少到 7 对。 我们给自己 1 个月的时间来适应新的配对。 我们将一位新开发人员与一位经验丰富的开发人员配对，并在故事卡上轮流进行配对。 该团队在计划时间内高质量地完成了所有可交付成果。 如果不结对，就不可能将 6 名开发人员添加到 8 名开发人员的团队中并达到目标！
最重要的是，通过配对可以省钱。 您将花费大约相同的时间，以更高的质量交付，提高团队的绩效、技能和知识，并清除死木。 您的节省将伴随着可持续的步伐，并且显着减少导致团队放慢速度的缺陷。
The first assumption one makes with pair programming is that a story card will cost twice a much to develop. The assumption is faulty. Here is why?
From actual experience we have seen defect drop significantly. New team members can be added without slowing down the team (try that with a non-paired team). For a trial, one team estimated the work for a set of story cards as if six single developers would complete the code individually. The six developer were then told to pair. They completed the work on time with high quality. If you don't pair, you are spending to much time to deliver to little quality, you have no way to scale and you have too many silos of expertise.
In a second example, we estimated to complete the work in the time requested we would need to take a team from 4 pairs to 7 pairs. We gave ourselves 1 month to on board the new pairs. We paired a new developer with an experienced developer and rotated the pairs across story cards. The team hit all deliverables with quality in the time planned. Without pairing one could not have added 6 developers to a team of 8 developers and hit the mark!
Bottom line, you will save money with pairing. You will take about the same time, delivery with higher quality, improve the teams performance, skills and knowledge and weed out the dead wood. Your savings will come with sustainable pace and significantly fewer defects in the way to slow the team down.
结对编程不会使成本加倍——它只是将打字量减半。 打字不是编程。 完成软件中的功能就是编程。 这是解决问题。 你不能只用输入的代码行数来衡量它。 一些程序员会使用更好的算法，因此他们最终会减少输入。
您如何定义物有所值？从开始编码到完成实际工作功能之间可能花费的总时间？
不配对的成本通常不会被正确计算：问题是，大多数人不会衡量缺陷数量或修复未正确完成的工作所需的额外时间。首先——他们只是测量“把工作扔过栅栏”所花费的时间。
在配对时有一些衡量生产力的尝试，但不幸的是，它与“交付的代码行数”有点联系——这是一个虚假的指标。
您可能会发现这项研究相关： http://协作.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Pair programming doesn't double the cost - it just halves the amount of typing. Typing isn't programming. Completing the functionality in the software is programming. It's problem solving. You can't just measure it in lines of code typed. Some programmers will use a better algorithm so they end up typing less.
How would you define value for money? Possibly total time elapsed between start of coding and completed, working feature in live?
The cost of not pairing isn't often counted correctly: The problem is that most people don't measure the number of defects or the amount of extra time taken to fix work that wasn't completed properly in the first place - they just measure the time taken to "throw the work over the fence" in the first place.
There are a few attempts at measuring productivity when paring, but unfortunately it gets a bit tied up with "number of lines of code delivered" - which is a bogus metric.
You might find this study relevant: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
前提是你的生产力提高一倍以上。 部分收益会立即实现（例如，在代码签入之前），部分收益会在错误和故障较少时进一步实现。
当我教有两个学期经验的学生时，对于大多数来说，他们的生产力提高了一倍以上，因为他们互相提问，学习和完成的速度更快。 但这并不是普遍正确的。 一对不匹配的搭档可能会比熟练的搭档花费更长的时间并且表现更差。
The premise is that your productivity more than doubles. Part of the gain is realized right away (e.g., before code is checked in) and part is realized further on, when there are fewer bugs and failures.
When I teach students with two semesters' experience, for most pairs their productivity more than doubles because they ask each other questions and they learn and finish faster. But it's not universally true; a badly matched pair can take longer and do worse than the more skilled half.
其他许多行业的质量管理经验告诉我们，从长远来看，缺陷预防比缺陷检测（也称为 QA）和后续修复更便宜。
他们还了解到，在大多数情况下，长期范围为 1 到 2 年，这意味着您的投资在此之后就会得到回报。 考虑到这种规模的投资通常预计在 4 年后就能实现收支平衡，这已经相当不错了！
问题在于，其他行业花了几十年的时间才积累了足够的数据，才能证明他们的情况就是如此。 你可以很容易地找到数据来支持他们的结论，并得出类似的软件结论，但截至目前，还没有针对软件业务的证据。
话虽这么说，我相信类似的结论是有效的：一对开发人员和一名测试人员比一名开发人员和两名测试人员更有生产力。
如果您无法向管理层证明两名昂贵的开发人员坐在一台计算机前，那么还有许多其他事情可以帮助预防缺陷，但对管理层来说并不那么明显（因此令人恼火）。
Quality management experience from other many industries teaches us that defect prevention is cheaper in the long run than defect detection (also known as QA) and subsequent fixing.
They also learned that the long run ranges in most cases from 1 to 2 years, which means that your investment pays off after that. Considering that investments on that scale are usually expected to reach a break even after 4 years, this is pretty good!
The problem is that it took the other industries several decades to accumulate enough data for being able to prove that this is the case for them. You can easily find data to support their conclusion and draw a conclusion for software in analogy to that, but as of today, there is no proof for the software business.
That being said, I believe that the analogous conclusion is valid: A pair of developers and one tester are more productive than one developer and two testers.
If you have problems justifying two expensive developers sitting in front of one computer to the managament, there are many other things that help with defect prevention, but are not as visible (and therefore irritating) to the management.
当我在朋友的船上编程时，我们并不总是有时间，因为我们中的一个人在航行，而另一个人在编码。 然而，当我们抛锚或在平静的水中时，我们可以进行结对编程，而且效果很好。
When I am programming on my friend's boat we don't always have time because one of us is sailing it while the other is coding. However, when we are anchored or in calm water we can do pair programming and it works fine.
没门！ 在我工作的公司里，我们练习了很多结对编程！ 它可以非常快速且非常高效地完成工作！ 尝试一下吧！ 以后你会评价的！
No way man! in the company i'm working we practice a lot of pair-programming! it gets things done really fast and really efficiently! just make a try! you will valuate it later!
北卡罗来纳州立大学的 Laurie Williams 教授是学术界关于结对编程有效性的主要权威，她对此做了很多研究。
如果您想要“官方消息”，请访问她的出版物列表。
她的文章“加强结对编程的案例”非常有名。
Professor Laurie Williams from NC State is the primary authority in academia about the effectiveness of pair programming, she did a whole bunch of studies on this.
If you want the "official word", visit her publication list.
Her article: "Strengthening the Case for Pair-Programming" is extremely famous.
这取决于开发商。 不幸的是，您无法将任何两个开发人员聚集在一起并期望及时获得高质量的结果。 并不是每个人都适合结对编程，甚至适合在敏捷开发环境中工作。 我认为结对编程值得做的两件事是：（1）开发人员之间的交叉培训； (2) 实时同行评审。 交叉培训将有助于增强整个团队的技能，实时同行评审可以消除正式同行评审的需要。 多年来，我从同行那里学到的东西比我在技术培训中学到的还要多。
It depends on the developers. Unfortunately, you can't just stick any two developers together and expect timely, high quality results. Not everybody is cut out for paired programming or even cut out for working in an agile development environment. Two things about paired programming that I think make it worth while are : (1) Cross-training between developers; and (2) Real-time peer reviews. Cross-training will help to strengthen the skills of the team as a whole, and real-time peer reviews can eliminate the need for formal peer reviews. I've learned more from my peers over the years than I ever learned at a technical training.
除非您是一家非常小的商店，否则您可能已经支付两名程序员的工资。 结对编程只是（理论上）在相同的时间内从这两个软件中获得更多经过调试和工作的软件的一种方法。
Unless you are a very tiny shop, you are probably already paying the salaries of two programmers. Pair programming is just a way to (theoreticaly) get more debugged and working software out of those two in the same amount of time.
结对编程的概念不是黑白分明的，也不是任何灵丹妙药。
由于各种原因，结对编程通常非常有效，但如果做得好，它也非常累人（在我看来无论如何）——这意味着一个好的结对编程可能每天最多几个小时结对编程。 当然，应该鼓励这样做，但不强制执行，尤其是不强制执行 100% 的时间，因为这似乎很难管理（保持持续的效率，而且无论如何都没有啤酒）。
所以，结对编程只是解决问题的一种方式，我发现很难从问题的角度来看待它。 您不需要为此雇用两倍的开发人员。 这就像想知道是否值得雇用一个消息男孩/女孩来让同一部门的两名员工相互交谈......而显而易见的解决方案是让他们直接相互交谈而无需额外的信使。
It's not a black and white thing or a silver bullet of any kind, the concept of pair programming.
Pair programming is generally extremely efficient for various reasons, but done right it's also very exhausting (in my opinion any way) - meaning a good pair might pair program a few hours a day at most. This should be encouraged, of course, but not mandated and especially not mandated at 100% time because that seems hard to manage (with sustained efficiency and no beer anyway).
So, pair programming is just one way of approaching a problem, and I find it hard to look at it from the question's perspective. It's not like you need to hire twice as many developers for this. It's like wondering if it's worth hiring a message boy/girl to have two employees in the same department talk to each other... when the obvious solution is to have them talk to each other directly without an additional messenger.
我还没有做统计——我怀疑你很难进行统计上有效的研究——但请记住生成有效、无错误代码的表面目标--不仅仅是代码数量。 一对好的搭档应该能够创建至少与两个单独工作的程序员一样多的正确代码。
I haven't done the stats--and I suspect you'd have a hard time doing a statistically valid study--but keep in mind the ostensible objective of producing working, error-free code--not just quantity of code. A good pair should be able to create at least as much correct code as two programmers working separately.