关于项目管理：冲刺速度计算

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

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

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

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

你们如何处理这种情况？

---

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

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

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

对我们来说，这仍是一项正在进行的工作，但这就是我们试图做到的。

---

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

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

---

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

---

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

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

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

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

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

---

FogBugz使用EBS(基于证据的日程安排)来创建概率曲线，该曲线表示您何时会基于现有的性能数据和估算来运送给定的项目。

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

---

测试人员和开发人员共同估算故事点。 冲刺的速度始终是合力。 质量检查人员/测试人员无法进行单独的速度计算。 这根本是错误的。
如果您有3个开发人员和2个测试人员，并且增加了测试人员的能力并将其与您的输出相关联，那么生产率将始终显示较低。 测试人员参与测试用例的设计，缺陷管理和测试，而这些都不直接归因于开发。 您可以针对所有这些测试任务进行跟踪，但是无法分配速度点。

---

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

---

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

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

与您的Scrum管理员交谈，否则速度和估算总是存在问题。

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

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

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

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

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

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

---

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

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

---