冲刺速度计算
我需要一些关于计算冲刺团队速度的建议。
我们的团队通常由大约4名开发人员和2名测试人员组成。scrum大师坚持认为每个团队成员都应该对速度计算做出平等的贡献，也就是说，当我们计算出在sprint中可以做多少事情时，我们不应该区分开发人员和测试人员。根据Scrum，这是正确的，但这是问题所在。
尽管有相反的建议，但测试人员从来没有帮助过非测试任务，开发人员也从来没有帮助过非开发任务，所以我们根本不是跨职能的团队成员。此外，尽管有各种建议，测试人员通常会在每次冲刺的前几天等待测试。
最终的结果是，通常我们承担的开发工作远远超过了我们在sprint中实际拥有的能力。例如，开发人员可以为速度计算贡献20天，而测试人员可能贡献10天。如果你在冲刺计划之后把任务加起来，那么开发任务加起来就是25天，测试任务加起来就是5天。
你们是怎么处理这种情况的？
回答 9
Stack Overflow用户
发布于 2009-08-13 22:05:29
我们也在这个问题上苦苦挣扎。
这就是我们要做的。当我们添加容量和任务时，我们将它们加在一起并分别添加。这样我们就知道我们没有超过每个组的总时间。(我知道这不是真正的scrum，但我们的QA人员不编程，因此，为了最大化我们的资源，他们最终进行测试，而我们(开发人员)最终开发。)
第二个想法是，我们真的专注于切片工作。我们试着选择首先要完成的任务，这些任务可以快速地交给QA人员。这其中的诀窍是，你必须专注于完成最少的可测试量，并转移到测试人员那里。如果你试图完成一个完整的“特性”，那么你就没有抓住要点。在他们等我们的时候，他们通常会把测试计划放在一起。
对我们来说，这仍然是一项正在进行的工作，但这就是我们试图做到的。
Stack Overflow用户
发布于 2008-09-07 14:02:37
既然敏捷开发是关于透明度和责任的，听起来测试人员应该分配任务来说明他们的速度。即使这意味着他们有一个网上冲浪的任务等待测试(尽管我认为他们会更好地为开发团队的任务制定测试计划)。这将显示您的组织中的低效，这并不受欢迎，但这就是敏捷的全部。不好的部分是你的测试人员可能会因为一些组织问题而受到惩罚。
我工作的公司有两个独立的团队(开发团队和质量保证团队)，有两个不同的迭代周期。qa周期被抵消了一周。这一不幸导致了任务接受的复杂性，因为直到qa迭代结束时，产品才真正准备好发布。这不是一个完全整合的团队，但从声音上看，你的团队也不是。不幸的是，qa团队从来没有真正遵循过scrum实践(没有真正的计划、站起来或回顾)，所以我真的不知道这是不是一个好的解决方案。
Stack Overflow用户
发布于 2008-09-07 12:52:18
FogBugz使用EBS (Evidence Based Scheduling)根据现有的性能数据和估计值创建一条概率曲线，表示何时发布给定的项目。
我猜你可以用这个做同样的事情，只是你需要为测试人员输入：“浏览互联网等待开发人员(1周)”
https://stackoverflow.com/questions/48386
复制相似问题
腾讯云开发者
