Project management 短跑速度计算

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

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

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

最终的结果是，通常情况下，我们承担的开发工作远远超过我们在sprint中实际拥有的能力。例如，开发人员可能为速度计算贡献20天，测试人员贡献10天。但是，如果您在sprint规划之后添加任务，那么开发任务总计为25天，测试任务总计为5天

你们是如何处理这种情况的？

FogBugz使用EBS（）根据现有的性能数据和估计，创建一条关于何时发布给定项目的概率曲线

---

我想你也可以这样做，只是你需要为测试人员输入：“浏览互联网等待开发人员（1周）”

听起来你的系统正在工作，只是没有你想要的那么好。这是一个付费项目吗？如果是的话，你可以让薪酬成为一种精英统治。根据员工完成的工作量支付薪酬。这将鼓励跨学科工作。尽管如此，这也可能会鼓励人们创作一些原本不属于他们的作品，或是内部破坏

---

显然，你必须注意那些试图玩这个系统的人，但这可能会奏效。当然，测试人员不希望获得开发人员一半的收入。

因为敏捷开发是关于透明性和责任性的，所以听起来测试人员应该分配任务来考虑他们的速度。即使这意味着他们有一项在网上冲浪等待测试的任务（尽管我认为他们最好为开发团队的任务制定测试计划）。这将显示出您的组织中的低效率，这并不受欢迎，但这正是敏捷的意义所在。糟糕的是，您的测试人员可能会因为组织问题而受到惩罚

---

我工作的公司有两个独立的团队（开发和质量保证），有两个不同的迭代周期。质量保证周期被一周所抵消。这一不幸导致了任务接受的复杂性，因为直到qa迭代结束，产品才真正准备好发布。这不是一个完整的团队，但从它的声音来看，你也不是。不幸的是，qa团队从来没有真正遵循scrum实践（没有真正的计划、站出来或回顾），所以我真的不知道这是不是一个好的解决方案

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

我们的第二个想法是，我们真正专注于切片工作。我们试着选择首先完成的任务，这些任务可以很快交给QA人员。其中的诀窍是，您必须专注于完成最少的可测试量，并将其转移到测试人员。如果你试图完成一个完整的“功能”，那么你就没有抓住要点。在他们等待我们的时候，他们通常会制定测试计划

---

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

这可能与您的要求略有出入，但这里是：

我真的不喜欢用速度来衡量在下一个sprint/迭代中要做多少工作。对我来说，速度更像是一种投影工具

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

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

---

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

让测试人员结对计划成为被动的同行。如果他们没有什么要测试的，至少他们可以在现场留意bug。当他们有东西要测试时，在本周的第二部分，他们会转到功能性/用户故事遵从性测试级别。通过这种方式，两个小组都会有效率，基本上测试人员会“梳理”代码。

关于velocity的第一个答案，而不是我个人对scrum非跨职能团队和每个sprint早期测试人员的见解

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

和你的scrum大师谈谈，否则在速度和估算方面总会有问题

现在是测试人员和sprint的早期阶段。我在not cro做测试员