我在一个使用Scrum的团队中，我们正在考虑添加结对编程，以帮助提高团队的跨职能技能，并通过“两个头脑比一个头脑好”的哲学来帮助减少缺陷。
在我们的团队中，每个团队成员通常在sprint计划期间签约一个完整的工作负载（“完整”是每周少于40个小时的数字，允许开会，协作等），并且只有一个专门的所有者负责每个任务。我相信这在Scrum团队中很常见，但不一定是本书所讲的。
特别是，我希望避免因团队成员有自己的任务而对团队成员感到犹豫的情况，如果团队只是自我组织而没有为配对留出时间，恐怕会发生这种情况。
鉴于此，在配对情况下考虑工作量/小时/故事点的最佳方法是什么，以确保我们为配对分配了适当的时间？
考虑的一些选项是：
Answers:
我认为其他人已经提供了很好的答案，但是我只添加我的原因是因为我认为您的团队刚刚过渡到Scrum，现在你们的位置与我们刚开始时非常相似。
首先，我们对敏捷（尤其是Scrum）的介绍不是很顺利。从根本上讲，管理层下来了，并说，从今天开始，您将进行Scrum，这是您将遵循的整个过程。对于处理过程的人们来说太多了。
我们最初遵循的过程（盲目的，我可能会补充）最终与您所描述的过程非常相似。人们得到分配的任务，每个人都被预订，我们都回到办公桌前插电。然后，我们每天都有一个无聊的站立会议。
要意识到的关键是，敏捷（包括Scrum）实际上与人有关。当团队进行迭代计划时，不要让您的Scrum主管（可能是您的经理）为您分配时间，故事和任务。这完全取决于团队。我认为对于很多人来说，这是一个很难理解的概念，因为在开始工作之前的很多年里，他们都会有一个老板（经理，技术主管...）来干脆分配工作。他们进入了Scrum，但是每个人（包括Scrum大师本人）继续以相同的模式进行操作。
有一天，您会对此感到厌烦，因此您将开始阅读书籍，博客，并在堆栈交换中不断提出这样的问题。您将获得的认识是，作为开发人员和您的团队成员应该成为致力于故事和分配任务的推动力。如果你们觉得您将从配对编程中受益，请务必为每个工程师创建2个任务，并分配他们两个小时的时间。Scrum管理员唯一要做的就是对照您在先前迭代中作为AS TEAM交付的完整故事来衡量速度。
令我烦恼的另一件事是，人们被告知他们的能力始终是总工作时间的75％，这就是他们所承诺的，然后在整个迭代过程中，他们抱怨a）他们不能帮助您或b）他们不能做正确的事，因为他们被分配了太多的时间。人们不应该被告知要花多少小时，而且如果Scrum管理员试图拉这样的东西，他们当然应该推迟！每个人都应该致力于自己所喜欢的东西。例如，我是团队负责人，经常我会参加一个随机的，未经计划的设计讨论，或者帮助某人提供代码或对怪异的东西进行故障排除，因此我的工作能力永远不会超过50％。
我们的团队花了4个发布周期来学习不做我刚刚提到的事情，即使我们确实有所改进，但如果您问专家，我们甚至还没有敏捷。因此，仍有很多学习要做。
更新1：回应Cliff的评论 嗯，您伸出了耳朵，所以这里...
没错，文化转变是关键，但这种转变无需在执行层进行。您自己的团队经理可以改变您团队中的文化，并将您与他必须处理的公司BS隔离开。您所描述的恰好是我们从2007年到2010年的事情。我们的团队（以及其他团队）发布后都失败了。在使用管理层“敏捷过程”的发行版中，我们设法让9个人完成通常由一个人完成的工作，这使我们花费了两倍的时间。我有很多空闲时间，甚至更新了我的简历。
然后，我与老板进行了交谈，并向他解释了所有这些事情，他对人有多敏捷，如果您希望我们关心产品，那么请让我们做出影响我们开发和交付产品的决策。我认为他决定将其做为实验，他对我们进行了每一个更改……很好，主要是我本人，但是我与团队的其他成员进行了很多交谈，因此提出了50％的能力：）。他可能认为，如果他进行了我们所要求的所有更改，但我们仍然失败了，他将以胜利的“我告诉过你”的名字回来。
因此，在过去的12个月中，我们消除了太多“愚蠢”的现象，这甚至都不是好笑的。现在，我们的站立会议实际上很有意义，因为我们可以一起工作，而不是孤立地工作。我们仍然拥有（至少到目前为止）产品特定部分的所有权，但我们也经常会相互了解对方的代码。我们不断进行代码审查，以便团队成员不仅学习其他代码，而且还学习更好的编码和设计技术。我们将庞大的巨型“敏捷”团队分成了3个不同的团队，因此，计划会议和其他会议要短得多，并且人们实际上在乎他们，因为他们不坐在那里听他们不在乎的事情。一世' 我们见过晚上，当五分之四的人（其中一个团队）晚上11点上线时，没有人真正告诉我们我们必须努力工作，或者曾经迫使我们工作40个小时以上。半年前不在乎的人突然间对他们所做的工作充满了参与和兴奋。我们的经理要做的就是说：“你们决定什么是对的，做您需要做的事，我将尽我所能将公司BS排除在团队之外。”
它最初是作为实验（我怀疑，他从未告诉过我），但是现在与部门中的其他开发小组相比，我们的小组正在迅速发展，甚至我们现在还有其他开发人员试图加入我们。
自从发生这种变化以来（今天仍然是一个问题），对我们来说最大的障碍是，在正常公司环境中的工程师就像被关在笼子里的实验老鼠。即使您的经理决定真正地“敏捷”并卸下笼子，每个人都已经呆在笼子里了这么长时间，他们甚至没有意识到自己有空。因此，即使拥有所有的自由，他们仍会继续表现得好像仍然受到约束。我认为这将对团队中至少有一些人（例如您自己）有所帮助，这些人会超出团队的界限并寻求更好的做事方法。然后回到该组并进行一点搅拌。
在您的情况下，如果您正在寻找其他外部力量来帮助团队并告诉他们如何工作，那么配对编程可能不是解决方案。取而代之的是扔掉规则，在没有管理的情况下与他们坐下来，问他们想做什么？什么会让他们开心？有生产力吗？找出最大的问题，然后问团队他们认为解决方案应该是什么。
Scrum并没有要求将任务分配给个人-远非如此。整个团队负责完成任务。如果团队想要进行结对编程，每个结对都承担一项任务，那么他们肯定会这样做。
从Scrum指南：
开发团队通常从设计系统以及将产品待办事项转换为工作产品增量所需的工作开始。工作可能会有所不同，也可能会有所估计。但是，在Sprint计划会议期间，为开发团队计划了足够的工作，以预测它认为在即将到来的Sprint中可以做什么。在本次会议结束之前，开发团队在Sprint的第一天计划的工作将分解为一天或更短的时间。在Sprint计划会议期间以及整个Sprint中，开发团队都会自发组织以完成Sprint Backlog中的工作。
在计划会议上分配任务恰恰与时间决策和团队授权背道而驰。这也与sprint的敏捷性背道而驰，因为从sprint的第一天开始，每个开发人员都已经完全调整了他应该做的事情。这也意味着必须非常正确地估计每个任务，几乎从来没有这样。
Imho估计任务是多余的。您已承诺要编写故事，并计划会议2足够的时间将这些故事拆分为任务并为这些任务创建卡片（或将它们填充到某个系统中）。没有足够的时间来估计每个任务，并且这些估计不应浪费时间进行实际开发。
为什么？估计是垃圾。怎么可能是垃圾？因为进行更多的估算不会带来更多的业务价值=这是垃圾，应该减少到必要的最低限度。最小的是估计/确定故事的大小，这有助于您做出承诺。做出承诺后，您无需进行其他任何估算。您只知道您有确定的日期交付您已承诺的东西。您将能够传送或不传送已提交的故事。估算任务将不会对您的交付有所帮助。
跳过任务估计绝不会影响对sprint进度的可见性，因为进度的唯一实际衡量标准是已完成故事（故事点）的数量，并且仍可以在sprint进度表中显示。
为了清楚起见。承诺意味着= 我们将做到。不，我们会尝试这样做。是的，您可能无法兑现您所做的承诺，但是您的承诺应该基于您的信念，即根据您目前的知识，您将交付选定的故事。如果您有这种信念，则不需要其他估计。
我总是以Scrum的方式使用，即开发人员在完成最后一个任务后会选择一个新任务。开发人员通常会在站立会议上说出要选择哪一个。通常没有任何规则，他应该选择哪个任务。这取决于团队的自我组织和团队成员之间的讨论（站立会议之外）。这将决定推迟到了最新的可能点，使您可以对某些更改和问题做出反应，而不会影响您的假想计划。如果有人在完成任务时遇到问题，任务本身甚至可以更改所有者-或者，可以成对开发此类任务。
配对编程如何参与其中？容易。团队会做出承诺，团队必须以这种方式为交付产品工作增量所需的所有开发技术腾出空间。您是否估计任务或任务开发以及任务测试？后一种方法是完全错误的。测试是开发的一部分，并且如果需要，以相同的方式，代码审查或配对也是开发的一部分。
进行配对编程应该可以更快地完成任务，并减少错误数量并提高代码质量。它不会快两倍，所以仍然会有一些开销，但是偶尔配对对承诺的实际影响应该很小。这不是指导或教学的情况。如果您有需要指导或教导的开发人员，则不应在学习产品代码库或某种技术的情况下完全规划他的冲刺能力。