冲刺速度计算

Question

需要一些关于为冲刺计算团队速度的建议。

我们的团队通常由大约4名开发人员和2名测试人员组成。 scrum master坚持认为每个团队成员都应该对速度计算做出同样的贡献，即在计算出sprint中我们可以做多少时，我们不应该区分开发人员和测试人员。根据Scrum的说法是正确的，但这就是问题所在。

尽管有相反的建议，测试人员从不帮助完成非测试任务，开发人员从不帮助完成非开发任务，因此我们根本不是跨职能团队成员。此外，尽管有各种建议，测试人员通常会在每个sprint的前几天等待测试。

最终结果是，通常我们承担的开发工作远远超过sprint实际拥有的能力。例如，开发人员可能需要20天的速度计算和测试人员10天。如果您在sprint计划之后添加任务，则dev任务最多可累计25天，测试任务最多可累计5天。

你们如何应对这种情况？

Answer 1

我们也在努力解决这个问题。

这是我们的工作。当我们将容量和任务相加时，我们将它们一起单独添加。这样我们就知道我们没有超过每个组的总时间。 （我知道这不是真正的scrum，但是我们有QA人员没有编程，因此，为了最大限度地利用我们的资源，他们最终会进行测试，而我们（开发人员）最终会付出代价。）

我们做的第二个想法是我们真正专注于切片工作。我们首先尝试选择要完成的任务，以便快速进入质量保证人员。这样做的诀窍是你必须专注于完成最少的可测试数量并转移给测试人员。如果你试图完成一个完整的“功能”，那么你就错过了这一点。当他们等我们时，他们通常会将测试计划放在一起。

对我们来说，这仍然是一项进展中的工作，但这就是我们尝试这样做的方式。

Answer 2

由于敏捷开发涉及透明度和问责制，因此听起来测试人员应该分配考虑其速度的任务。即使这意味着他们有一个上网等待测试的任务（虽然我认为他们会更好地为开发团队的任务开发测试计划）。这将显示您组织中的低效率，这种效率并不受欢迎，但这就是敏捷的全部内容。其中不好的一点是，您的测试人员可能因组织问题而受到处罚。

我工作的公司有两个独立的（dev和qa）团队，有两个不同的迭代周期。 qa周期被一周抵消了。这种不幸导致了任务接受的复杂性，因为在qa的迭代结束之前，产品还没有真正准备好发布。这不是一个适当整合的团队，但也不是你的声音。不幸的是，qa团队从未真正遵循scrum实践（没有真正的计划，站起来或回顾），所以我无法确定这是否是一个好的解决方案。

Answer 3

FogBugz使用EBS（Evidence Based Scheduling）创建基于现有绩效数据和估算值运送给定项目的概率曲线。

我想你可以用这个做同样的事情，只需要输入测试人员：“浏览互联网等待开发人员（1周）”

Answer 4

这可能会略微偏离你的要求，但现在就是：

我真的不喜欢使用velocity来衡量下一次sprint / iteration中要做多少工作。对我而言，速度更像是投影的工具。

团队负责人/项目经理/ scrum master可以查看最后几次迭代的平均速度，并有一个相当好的趋势线来预测项目的结束。

团队应该通过承诺作为团队来构建迭代。继续挑选故事，直到迭代有大量工作，团队将承诺完成。作为一个团队，你有责任通过挑选少数人来确保你不会懈怠。当团队承诺迭代时，不同的技能水平和专业会自行解决。

在这种模式下，一切都平衡了。团队有一个合理的工作量来完成，项目经理有承诺完成。

Answer 5

让测试人员成对程序成为被动对等体。如果他们没有什么可测试的，至少他们可以留意场上的虫子。当他们有需要测试的东西时，在本周的第二部分，他们将转向功能/“用户故事合规”级别的测试。通过这种方式，您可以使两个组都有效，并且基本上测试人员会在代码中“梳理”代码。

Answer 6

听起来像你的系统正在运行，只是不如你想的那样好。这是付费项目吗？如果是的话，你可以让薪酬成为一种精英。根据他们完成的工作量来支付人员。这将鼓励跨学科工作。虽然，它也可能鼓励人们开始制作不属于他们的作品或内部破坏。

显然，你必须留意那些试图游戏系统的人，但它可能会奏效。当然测试人员不想赚取开发者的一半。

Answer 7

速度的第一个答案，而不是我个人对scrum非跨职能团队中测试人员和每个sprint早期阶段的见解。

我看到有不一致的地方。如果团队没有跨职能，那么区分测试人员和开发人员。在这种情况下，您还必须在速度计算中区分它们。如果团队不是跨职能测试人员，则不会真正提高你的速度。您的速度将是开发人员可以实现的最大速度，但不超过测试人员可以测试的速度（如果必须测试所有内容）。

与你的scrum大师交谈，否则速度和估计总会出现问题。

现在测试人员和冲刺的早期阶段。我作为测试员在没有5个开发人员的跨职能团队中工作，所以这个答案可能有点个人化。 您可以通过两种方式解决这个问题：a）通过添加单独的测试sprint来改变工作组织，或者b）改变测试人员的工作方式。

在a）你创建单独的测试冲刺。它可以与devs sprint并行发生（只是转移了几天），或者你可以在每两到三次dev sprint中发生一次。 我听说过这个解决方案，但我从来没有这样做过。

在b）中，您必须要求测试人员检查他们的测试活动方法。也许这取决于您使用的实践和工具，或者您遵循的流程，但在这些早期他们怎么可能无所事事？正如我之前提到的，我在5名开发人员中担任测试人员而非跨职能团队。如果我等到我的工作直到开发人员结束他的任务，我将永远不会测试给定sprint中的所有功能。除非您的测试人员仅执行探索性测试，否则在将功能发布到测试环境之前，他们应该做些事情。在测试人员将功能/代码交到他手中之前，有些活动可以完成（或必须完成）。以下是我在将功能发布到测试环境之前所做的事情：
- 完成要实施的要求的要求 - 设计测试脚本（高级设计）
- 准备测试案例草案
- 浏览可能的测试数据（如果正在实施的更改是操纵系统中需要对此数据进行快照的数据，以便稍后将其与给定功能对此数据执行的操作进行比较）
- 包装测试套件中的所有内容 - 正在开发功能时与开发人员沟通 - 这样您就可以更好地理解已实施的解决方案（而不是在他已经考虑其他功能时询问） - 随着功能的发展，您可以对测试用例进行必要的更改

然后当功能完成时你： - 使用之前不为您所知的任何细节充实测试用例（这是微不足道的，但按钮名称可以更改，或者向导中出现一些额外步骤）
- 进行测试
- 上升问题
。 实际上，我发现自己花了更多时间在第一部分（设计测试，并在适当的工具中准备测试脚本），而不是实际执行这些测试。

如果他们能够马上而不是等待代码被释放到测试环境中，那么它应该有助于解决这个初始差距，并且它将最大限度地降低测试人员在冲刺结束前未完成其活动的风险。

当然，测试人员在开始时总是会做的更少，最后会有更多，但你可以尝试尽量减少这种差异。即使上面仍然有很多时间浪费在开头你可以给他们没有编码涉及的任务。一些配置，一些维护，文档更新，其他。

Answer 8

解决方案绝不是黑白的，因为每个sprint可能包含需要测试的故事和其他不需要测试的故事。例如，敏捷分配测试仪没有问题;在冲刺期间50％的时间和在下一次冲刺中的20％。 尝试将测试人员100％的时间分配给冲刺并试图证明其合理性是没有意义的。时间管理是关键。

Answer 9

测试人员和开发人员一起估算故事点。冲刺的速度始终是一种共同的努力。质量保证/测试人员无法进行单独的速度计算。这根本就是错误的。 如果您有3个开发人员和2个测试人员，并且您包括测试人员的容量并将其与您的输出相关联，那么生产率将始终显示为低。测试人员参与测试用例设计，缺陷管理和测试，这些测试不直接归因于开发。您可以针对每个测试任务进行跟踪，但无法分配速度点。