需要一些建议来确定短跑的团队速度。

我们的团队通常由大约4个开发人员和2个测试人员组成。 Scrum负责人坚持认为，每个团队成员都应为速度计算做出同等的贡献，即在确定我们在冲刺中可以做什么时，我们不应区分开发人员和测试人员。根据Scrum的说法，这是正确的，但这就是问题所在。

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

最终结果是，通常我们进行的开发工作要比在sprint中实际拥有的能力要多得多。例如，开发人员可能需要20天才能完成速度计算，测试人员需要10天才能完成速度计算。但是，如果我们是在Sprint计划之后添加任务的，则开发任务最多需要25天，测试任务最多需要5天。

你们如何处理这种情况？

解决方案

回答

FogBugz使用EBS(基于证据的日程安排)来创建一条概率曲线，以根据我们现有的绩效数据和估算值来运送给定项目。

我想我们可以这样做，只是我们需要输入测试人员的内容："浏览Internet等待开发人员(1周)"

回答

在我看来，系统正在运行，但并没有达到我们想要的水平。这是一个付费项目吗？如果是这样，我们可以使薪酬成为精英。根据完成的工作量向员工付款。这将鼓励跨学科的工作。虽然，这也可能会鼓励人们从事与他们无关的作品或者内部破坏活动。

显然，我们必须警惕尝试使用该系统的用户，但这可能有用。测试人员肯定不会希望获得开发人员收入的一半。

回答

由于敏捷开发是关于透明性和责任制的，因此听起来测试人员应该分配能够说明其速度的任务。即使这意味着他们有一个在网上等待测试的任务(尽管我认为为开发团队的任务制定测试计划会更好)。这将显示我们组织中效率低下的情况，这种低效率不是很普遍，但这就是敏捷的全部意义所在。糟糕的是，测试人员可能会因为组织上的问题而受到惩罚。

我工作的公司有两个不同的迭代周期的独立(开发和质量保证)团队。质量检查周期被抵消了一周。不幸的是，在接受任务时，这导致了复杂性，因为直到qa迭代结束之前，产品才真正准备好发布。那不是一个适当整合的团队，但从声音上来说，团队也不是。不幸的是，质量保证团队从来没有真正遵循Scrum的做法(没有真正的计划，站立或者追溯)，因此我无法真正确定这是否是一个好的解决方案。

回答

我们也在这个问题上挣扎。

这是我们的工作。当我们增加容量和任务时，我们将它们分别在一起添加。这样，我们知道我们没有超过每个小组的总时间。 (我知道这并不是真正的混乱，但是我们有不进行编程的质量检查人员，因此，为了最大化我们的资源，他们最终进行测试，而我们(开发人员)最终进行设计。)

第二个想法是，我们确实专注于切片工作。我们尝试挑选任务以首先完成，从而可以快速联系质量检查人员。诀窍在于，我们必须专注于完成最少的可测试量并转移到测试人员手中。如果我们试图完成整个"功能"，那么我们将失去重点。他们等待我们时，通常会制定测试计划。

对我们来说，这仍在进行中，但这就是我们试图做到的。

回答

这可能与要求略有出入，但实际情况如下：

我真的不喜欢用速度来衡量下一个冲刺/迭代中要做的工作。对我而言，速度更像是一种投影工具。

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

团队应该按照团队的承诺来构建迭代。不断挑选故事，直到迭代完成团队将要完成的大量工作为止。作为团队的责任，是确保我们不会因选拔而懈怠，也不会因选拔而过度投入。团队致力于迭代时，可以运用不同的技能水平和专业知识。

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

回答

使测试人员与被动对等程序配对编程。如果他们没有要测试的东西，至少他们可以提防现场的错误。当他们有什么要测试的东西时，在本周的下半部分，他们将转到功能/"用户故事符合性"测试级别。这样，我们就可以使两个小组都富有成效，并且基本上，测试人员会在运行过程中"梳理"代码。

回答

关于速度的第一个答案，而不是我对Scrum非跨职能团队中的测试人员的个人见解以及每次冲刺的初期。

我看到那里不一致。如果团队不是跨职能的，则可以区分测试人员和开发人员。在这种情况下，我们还必须在速度计算中对它们进行区分。如果团队不是跨职能的测试人员，则不会真正提高速度。速度将是开发人员可以实现的最高速度，但最多只能是测试人员可以测试的速度(如果必须测试所有内容)。

与Scrum管理员交谈，否则速度和估算总是会出现问题。

现在，对于测试人员和冲刺的初期。我在不与5名开发人员跨职能的团队中担任测试人员，所以这个答案可能有点个人化。
我们可以通过两种方式解决此问题：a)通过添加单独的测试冲刺来更改工作组织，或者b)更改测试人员的工作方式。

在a)中，我们创建单独的测试冲刺。它可以与开发者sprint并行发生(只是几天而已)，也可以每两三个开发者sprint一次。
我听说过这种解决方案，但是我从来没有这样工作过。

在b)中，我们必须要求测试人员检查其测试活动的方法。也许这取决于我们使用的实践和工具，或者我们遵循的流程，但是在今天的初期它们又如何与之无关？正如我之前提到的，我作为测试人员与5个跨职能团队的开发人员一起工作。如果我等我的工作直到开发人员结束任务，我将永远不会测试给定sprint中的所有功能。除非测试人员仅执行探索性测试，否则在将功能发布到测试环境之前，他们应该做些事情。在测试人员获得功能/代码之前，可以完成(或者必须完成)一些活动。以下是在将功能发布到测试环境之前我要做的事情：
审核要实现的功能的要求
设计测试脚本(高级设计)
准备测试用例草案
查看可能的测试数据(如果正在实施的更改正在处理系统中的数据，则需要对此数据进行快照，以便稍后将其与给定功能将对此数据进行比较)
将所有内容包装在测试套件中
通过这种方式开发功能时，与开发人员进行交流，我们可以更好地了解已实现的解决方案(而不是问他何时已经对其他功能有想法)
我们可以随着功能的发展对测试用例进行任何必要的更改

然后，当功能完成时，我们：
用我们以前不知道的任何细节充实测试用例(这很简单，但是按钮名称可以更改，或者在向导中显示一些其他步骤)
执行测试
上升问题
。
实际上，我发现自己花在第一部分(设计测试和使用适当的工具准备测试脚本)上的时间要比实际执行这些测试花费的时间更多。

如果他们可以立即采取一切措施，而不是等待代码发布到测试环境中，则应该可以弥补这一最初的差距，并且可以最大程度地降低测试人员在冲刺结束之前未完成其活动的风险。

当然，从一开始，测试人员要做的事情总是很少，而到最后，要做的事情更多，但是我们可以尝试最小化这种差异。即使以上情况仍然让他们在开始时浪费大量时间，我们也可以不给他们编写任何涉及编码的任务。一些配置，一些维护，文档更新，其他。

回答

解决方案永远不会是黑白的，因为每个冲刺都可能包含需要测试的故事，而其他则不需要测试。例如，敏捷地分配测试人员是没有问题的；在一次冲刺中花费了50％的时间，在下一次冲刺中花费了20％的时间。
试图将测试人员100％的时间分配给冲刺并试图证明其合理性是没有意义的。时间管理是关键。