If you could do something else alone, why not when pairing? Maybe simpler action items could be taken off an issue list while waiting? A 3 minute wait would be too long for me to keep the brain in the "flow-mode". So being disrupted anyway (and your partner as well), can't you just do something else with your partner?
However, in your situation, I'd not work in any environment where I have 3 minutes pauses after a change. So the question is: can't you develop and debug that code in a smaller environment, broil it to perfection and then reintegrate those pieces into the main stream ?
Pair programming should be applied only to the research/POC/innovative parts of the development. Simple tasks should be delegated to the single programmers.
It is not only the problem of the waste of time when you have to wait for your partner to complete the tivial but time-consuming task. There is also a human factor - you get bored while waiting. Remember that productive developer need to be constantly motivated - waiting for your partner to complete lowers your morale.
You should probably consider refactoring the process. Three minutes to get feedback is too much both for pairing but also for coding solo. It is killing your productivity to have to switch gears constantly. You probably just feel it more when pairing.
Performance work, where of necessity you must run for a few minutes to gather statistics, is something that isn't a great fit for XP. There's a strong case to be made for starting off as a pair to sketch out some ideas, then going solo to avoid wasting two people's time for every three-minute performance runs, then joining up again to review the work prior to checking in.
Time for a spike Performance has to be built in, not added on. The team should have a set of automated test that can run frequently (daily) in a production like environment. Also, the team should be running a profiler continuously. If you don't have either, time to stop the line and get it done now!!!
If the team finds itself in a situation where performance is an issue, it needs to identify the technical debt and create a set of story cards to address the debt. It would include a set of automate performance test, A set of profiler tests. Daily analysis of the results of the test is a must. An architectural or design spike can then be called should a performance issue present itself.
If an team has not been doing performance testing continually from the start, you could have a significant technical debt to address. Once you have the application performing, you need to keep running your automated testing daily so you can become aware if and when a problem arises. You are then better to identify the offending changes to the applications.
By running automated performance test, you can allow the test to run for some period, generally for a period of hours. The results can later be analyzed and it frees the developers to do work on other story cards without waiting for the result of numerous individual performance tests.
Waiting is a blocker. Eliminate waiting via automated tests.
It doesn't matter if you are pair programming or not. 3 minutes is way too long for getting feedback on code change even if you are coding alone. I would profile and break down the project so that I can focus on a smaller pieces. In that sense, XP is actually helping(forcing) you to improve the design before it's too late.
I would split up for those tasks. Both of you work on the code separately, and recombine every so often (30 minutes or so?) when you've made improvements.
发布评论
评论（8）
如果你可以单独做其他事情，为什么结对时不可以呢？ 也许在等待时可以将更简单的行动项目从问题列表中删除？ 三分钟的等待对于我来说太长了，无法让大脑保持在“心流模式”。 因此，无论如何（还有你的伴侣）受到干扰，你就不能和你的伴侣一起做点别的事情吗？
但是，在您的情况下，我不会在任何更改后有 3 分钟暂停的环境中工作。 所以问题是：你不能在较小的环境中开发和调试该代码，将其烤至完美，然后将这些部分重新集成到主流中吗？
If you could do something else alone, why not when pairing? Maybe simpler action items could be taken off an issue list while waiting? A 3 minute wait would be too long for me to keep the brain in the "flow-mode". So being disrupted anyway (and your partner as well), can't you just do something else with your partner?
However, in your situation, I'd not work in any environment where I have 3 minutes pauses after a change. So the question is: can't you develop and debug that code in a smaller environment, broil it to perfection and then reintegrate those pieces into the main stream ?
你的情况可能会有所不同，但我认为在任何非主要功能上进行结对编程至少会浪费一个程序员的时间
your mileage may vary, but i consider pair programming on anything less than a major feature to be a waste of at least one programmer's time
结对编程应仅应用于开发的研究/POC/创新部分。 简单的任务应该委托给单个程序员。
当你必须等待你的伴侣完成琐碎但耗时的任务时，这不仅仅是浪费时间的问题。 还有一个人为因素 - 等待时你会感到无聊。 请记住，高效的开发人员需要不断激励 - 等待合作伙伴完成会降低你的士气。
Pair programming should be applied only to the research/POC/innovative parts of the development. Simple tasks should be delegated to the single programmers.
It is not only the problem of the waste of time when you have to wait for your partner to complete the tivial but time-consuming task. There is also a human factor - you get bored while waiting. Remember that productive developer need to be constantly motivated - waiting for your partner to complete lowers your morale.
您可能应该考虑重构该流程。 无论是对于结对还是单独编码来说，三分钟获取反馈都太过分了。 必须不断地切换齿轮会降低你的生产力。 您可能只是在配对时更有感觉。
You should probably consider refactoring the process. Three minutes to get feedback is too much both for pairing but also for coding solo. It is killing your productivity to have to switch gears constantly. You probably just feel it more when pairing.
性能工作（必须运行几分钟来收集统计数据）不太适合 XP。 有一个强有力的理由是，首先两人一起勾勒出一些想法，然后单独进行，以避免在每三分钟的表演中浪费两个人的时间，然后在签到之前再次联合起来回顾工作。
Performance work, where of necessity you must run for a few minutes to gather statistics, is something that isn't a great fit for XP. There's a strong case to be made for starting off as a pair to sketch out some ideas, then going solo to avoid wasting two people's time for every three-minute performance runs, then joining up again to review the work prior to checking in.
达到峰值的时间 性能必须是内置的，而不是附加的。 团队应该拥有一组可以在类似生产环境中频繁（每天）运行的自动化测试。 此外，团队应该持续运行分析器。 如果你两者都没有，那么现在就停下来完成它吧！
如果团队发现自己处于性能成为问题的情况，则需要确定技术债务并创建一组故事卡来解决债务。 它将包括一组自动化性能测试、一组分析器测试。 每天分析测试结果是必须的。 如果出现性能问题，则可以调用架构或设计峰值。
如果团队从一开始就没有持续进行性能测试，那么您可能需要解决大量的技术债务。 一旦应用程序运行，您需要每天继续运行自动化测试，以便您可以了解是否以及何时出现问题。 然后，您可以更好地识别应用程序中的违规更改。
通过运行自动化性能测试，您可以允许测试运行一段时间，通常是几个小时。 稍后可以对结果进行分析，并且使开发人员能够腾出时间来处理其他故事卡，而无需等待大量单独性能测试的结果。
等待是一个障碍。 通过自动化测试消除等待。
Time for a spike Performance has to be built in, not added on. The team should have a set of automated test that can run frequently (daily) in a production like environment. Also, the team should be running a profiler continuously. If you don't have either, time to stop the line and get it done now!!!
If the team finds itself in a situation where performance is an issue, it needs to identify the technical debt and create a set of story cards to address the debt. It would include a set of automate performance test, A set of profiler tests. Daily analysis of the results of the test is a must. An architectural or design spike can then be called should a performance issue present itself.
If an team has not been doing performance testing continually from the start, you could have a significant technical debt to address. Once you have the application performing, you need to keep running your automated testing daily so you can become aware if and when a problem arises. You are then better to identify the offending changes to the applications.
By running automated performance test, you can allow the test to run for some period, generally for a period of hours. The results can later be analyzed and it frees the developers to do work on other story cards without waiting for the result of numerous individual performance tests.
Waiting is a blocker. Eliminate waiting via automated tests.
结对编程与否并不重要。 即使您独自编码，3 分钟对于获得代码更改的反馈来说也太长了。 我会对项目进行概要分析和分解，以便我可以专注于较小的部分。 从这个意义上说，XP 实际上是在帮助（迫使）您改进设计，以免为时已晚。
It doesn't matter if you are pair programming or not. 3 minutes is way too long for getting feedback on code change even if you are coding alone. I would profile and break down the project so that I can focus on a smaller pieces. In that sense, XP is actually helping(forcing) you to improve the design before it's too late.
我会分头完成这些任务。 你们两人分别处理代码，并在做出改进后经常重新组合（30 分钟左右？）。
I would split up for those tasks. Both of you work on the code separately, and recombine every so often (30 minutes or so?) when you've made improvements.