需要一些关于制定 sprint 的团队速度的建议。
我们的团队通常由大约 4 名开发人员和 2 名测试人员组成。Scrum master 坚持每个团队成员都应该对速度计算做出同样的贡献，也就是说，在计算我们在 sprint 中可以做多少时，我们不应该区分开发人员和测试人员。根据 Scrum，这是正确的，但问题就在这里。
尽管有相反的建议，但测试人员从不帮助非测试任务，开发人员从不帮助非开发任务，所以我们根本不是跨职能的团队成员。此外，尽管有各种建议，但测试人员通常会在每个 sprint 的前几天等待要测试的东西。
最终结果是，通常我们承担的开发工作比我们在 sprint 中的实际能力要多得多。例如，开发人员可能会为速度计算贡献 20 天，而测试人员可能会贡献 10 天。但是，如果您在 sprint 计划之后将任务加起来，则开发任务加起来最多 25 天，测试任务加起来最多 5 天。
遇到这种情况大家怎么处理？
我们也在为这个问题而苦苦挣扎。
这就是我们所做的。当我们将容量和任务相加时，我们会将它们分别相加。这样我们就知道我们没有超过每个组的总时间。（我知道这不是真正的 Scrum，但我们有不编程的 QA 人员，因此，为了最大限度地利用我们的资源，他们最终进行测试，而我们（开发人员）最终进行开发。）
第二个想法是我们真正专注于切片工作。我们尝试选择首先完成的任务，这些任务可以快速交给 QA 人员。这样做的诀窍是您必须专注于完成最少的可测试量并将其转移给测试人员。如果您尝试完成整个“功能”，那么您就错过了重点。当他们等待我们时，他们通常会制定测试计划。
这对我们来说仍然是一项正在进行的工作，但这就是我们尝试做的方式。
由于敏捷开发是关于透明度和问责制的，因此听起来测试人员应该分配考虑其速度的任务。即使这意味着他们有一项任务是在网上冲浪等待测试（尽管我认为他们会更好地为开发团队的任务制定测试计划）。这将显示您的组织中不受欢迎的低效率，但这就是敏捷的全部意义所在。不好的部分是你的测试人员可能会因为一些组织问题而受到惩罚。
我工作的公司有两个独立的（开发和质量保证）团队，有两个不同的迭代周期。质量保证周期被一周抵消。不幸的是，当涉及到任务接受时，这导致了复杂性，因为直到质量保证迭代结束时，产品才真正准备好发布。这不是一个适当整合的团队，但从它的声音来看也不是你的。不幸的是，QA 团队从未真正遵循 Scrum 实践（没有真正的计划、站立或回顾），所以我真的无法判断这是否是一个好的解决方案。
FogBugz 使用 EBS（基于证据的调度）根据现有的性能数据和估计来创建您何时交付给定项目的概率曲线。
我想你可以用这个做同样的事情，只是你需要为测试人员输入：“浏览互联网等待开发人员（1周）”
这可能与您的要求略有不同，但在这里：
我真的不喜欢用速度来衡量在下一个冲刺/迭代中要做多少工作。对我来说，速度更像是一种预测工具。
团队负责人/项目经理/scrum master 可以查看最近几次迭代的平均速度，并有一个相当好的趋势线来预测项目的结束。
团队应该通过作为一个团队的承诺来构建迭代。继续挑选故事，直到迭代有大量团队将承诺完成的工作。作为一个团队，你有责任确保你不会因为选择少数而懈怠，也不会因为选择太多而过度承诺。随着团队致力于迭代，不同的技能水平和专业会自行发挥作用。
在这种模式下，一切都是平衡的。团队有合理的工作量要完成，项目经理有完成的承诺。
让测试人员结对编程为被动对等。如果他们没有要测试的东西，至少他们可以提防现场的错误。当他们有东西要测试时，在一周的第二部分，他们会转移到功能/“用户故事合规性”级别的测试。这样，您就可以让两个团队都高效，并且基本上测试人员会在代码进行时“梳理”代码。
解决方案绝不是非黑即白的，因为每个 sprint 都可能包含需要测试的故事和其他不需要测试的故事。例如，在敏捷中分配测试人员是没有问题的；50% 的时间在一个 sprint 中，20% 的时间在下一个 sprint 中。试图将测试人员 100% 的时间分配给 sprint 并试图证明这一点是没有意义的。时间管理是关键。
在我看来，您的系统正在运行，只是没有您想要的那么好。这是一个付费项目吗？如果是这样，你可以让薪酬成为精英。根据人们完成的工作量来支付报酬。这将鼓励跨学科工作。虽然，它也可能鼓励人们开始创作不属于他们的作品，或者内部破坏。
显然，您必须留意试图玩弄该系统的人，但它可能会奏效。测试人员肯定不想赚取开发人员所做工作的一半。
测试人员和开发人员一起估计故事点。冲刺的速度始终是共同努力的结果。QA / 测试人员不能有他们单独的速度计算。这是根本错误的。如果您有 3 名开发人员和 2 名测试人员，并且您将测试人员的能力包括在内并将其与您的输出相关联，那么生产力将始终显示为低。测试人员参与不直接归因于开发的测试用例设计、缺陷管理和测试。您可以跟踪每个测试任务的努力，但不能分配速度点。
速度的第一个答案，而不是我个人对 Scrum 非跨职能团队和每个 sprint 早期测试人员的见解。
我看到那里不一致。如果团队不是跨职能的，那么您可以区分测试人员和开发人员。在这种情况下，您还必须在速度计算中区分它们。如果团队不是跨职能的测试人员并不会真正提高您的速度。您的速度将是开发人员可以实现的最大速度，但不会超过测试人员可以测试的速度（如果必须测试所有内容）。
与您的 scrum master 交谈，否则速度和估计总是会出现问题。
现在至于测试人员和冲刺的早期阶段。我在没有 5 个开发人员的跨职能团队中担任测试员，所以这个答案可能有点个人化。您可以通过两种方式解决这个问题：a) 通过添加单独的测试冲刺来改变工作组织或 b) 改变测试人员的工作方式。
在 a) 中，您创建了单独的测试冲刺。它可以与开发冲刺并行发生（只是改变了那几天），或者您可以每两到三个开发冲刺发生一次。我听说过这种解决方案，但我从来没有这样工作过。
在 b) 中，您必须要求测试人员审查他们的测试活动方法。也许这取决于您使用的实践和工具，或者您遵循的流程，但在早期他们怎么可能无事可做？正如我之前提到的，我在非跨职能团队中与 5 名开发人员一起担任测试员。如果我一直等到开发人员结束他的任务，我就永远不会测试给定 sprint 中的所有功能。除非您的测试人员只执行探索性测试，否则他们应该在将功能发布到测试环境之前做一些事情。在测试人员获得功能/代码之前，可以完成（或必须完成）一些活动。以下是我在将功能发布到测试环境之前所做的事情：
- 检查要实现的功能的要求
- 设计测试脚本（高级设计）
- 准备草稿测试用例
- 浏览可能的测试数据（如果正在实施的更改正在操作系统中的数据，您需要制作此数据的快照，以便稍后将其与给定功能将对该数据执行的操作进行比较）
- 总结测试套件中的所有内容
- 在开发功能时与开发人员进行沟通 - 这样您可以更好地了解已实施的解决方案（而不是询问他何时已经考虑过其他功能）
- 您可以对测试用例进行任何必要的更改作为功能进化
然后，当功能完成时，您： - 用您之前不知道的任何细节充实测试用例（这很简单，但按钮名称可以更改，或者出现向导中的一些额外步骤）
- 执行测试
- 引发问题
。实际上，我发现自己花更多的时间在第一部分（设计测试，并在适当的工具中准备测试脚本）而不是实际执行这些测试。
如果他们尽可能地立即而不是等待代码发布到测试环境，它应该有助于解决这个初始差距，并且它将最大限度地减少测试人员在冲刺结束之前没有完成他们的活动的风险。
当然，测试人员在开始时总是做的更少，最终做的更多，但你可以尽量减少这种差异。即使上面仍然让他们在开始时浪费大量时间，您也可以给他们不涉及编码的任务。一些配置，一些维护，文档更新，其他。