需要一些关于制定冲刺队伍速度的建议。冲刺速度计算
我们的团队通常由大约4名开发人员和2名测试人员组成。 Scrum大师坚持每个团队成员都应该对速度计算作出同样的贡献，也就是说，在计算我们在冲刺中能做多少时，我们不应该区分开发者和测试者。根据Scrum的说法是正确的，但这是问题所在。
尽管有相反的建议，但测试人员从不帮助开发非测试任务，开发人员也从不帮助开发非开发任务，所以我们根本不是跨功能团队成员。此外，尽管有各种建议，测试人员通常会在每个冲刺的前几天等待测试。
最终的结果是，我们通常会承担比我们在冲刺中的实际能力更多的开发工作。例如，开发人员可能会为速度计算贡献20天，测试人员可能贡献10天。如果在sprint计划之后添加任务，则dev任务最多可以添加25天，而测试任务最多可以添加5天。
你们怎么处理这种情况呢？
FogBugz使用EBS（Evidence Based Scheduling）根据现有的性能数据和估算值创建了何时发运给定项目的概率曲线。
我想你可以做同样的事情这一点，只是你需要为测试输入：“浏览互联网等待开发商（1周）”
的声音，我喜欢你的系统是否正常工作，只是不如你想要的。这是一个付费项目吗？如果是这样，你可以使薪酬成为精英分子。根据他们完成多少工作来付款。这会鼓励交叉纪律工作。尽管它也可能鼓励人们从事不属于他们的内容或内部破坏。
很明显，你必须寻找人们试图游戏系统，但它可能会工作。测试人员肯定不想赚取开发人员所做的一半。
由于敏捷开发是关于透明度和问责性，听起来像测试人员应该已经分配任务来说明他们的速度。即使这意味着他们有上网等待测试的任务（尽管我认为他们会更好地为开发团队的任务制定测试计划）。这将显示您的组织中效率低下并不流行，但这正是Agile所关心的。其中不好的部分是你的测试人员可能因为某个组织问题而受到处罚。
我工作的公司有两个不同的（dev和qa）团队，有两个不同的迭代周期。 qa周期抵消了一周。这个不幸导致了接受任务时的复杂性，因为一个产品直到qa迭代结束时才准备好发布。这不是一个适当整合的团队，但你的声音也不是。不幸的是，qa团队从来没有真正遵循过scrum的实践（没有真正的计划，站起来或回顾），所以我不能确定这是否是一个好的解决方案。
我们也在处理这个问题。
这就是我们所做的。当我们将能力和任务加起来时，我们将它们分别加在一起。这样我们知道我们没有超过每个组的总时间。 （我知道这并不是真正的混乱，但我们有质量保证人员不会编程，所以为了最大限度地利用我们的资源，他们最终会进行测试，我们（开发人员）最终会放弃。）
第二种认为我们做的是我们真的专注于切片。我们尝试选择首先完成的任务，以便快速转到质量检查人员。诀窍在于，您必须专注于获得最少的可测试数量，并将其转移给测试人员。如果你试图获得一个完整的“功能”，那么你就错过了这一点。当他们等待我们时，他们通常会制定测试计划。
对于我们来说，这仍然是一项正在进行的工作，但我们正是这样做的。
这可能是稍微偏离你问什么，但这里有云：
我真的不喜欢使用速度为多少工作在未来冲刺/迭代做的措施。对我来说速度更像是投影的工具。
团队负责人/项目经理/ scrum master可以查看最近几次迭代的平均速度，并有一个相当好的趋势线来投影项目结束。
团队应该按照承诺作为团队来构建迭代。继续挑选故事，直到迭代完成团队承诺完成的大量工作。这是你作为一个团队的责任，要确保你不会因为挑选少数人而懒惰，也不愿意挑选很多人。当团队承诺迭代时，不同的技能水平和专业会自行解决。
在这种模式下，一切均衡。团队有一个合理的工作量来完成，项目经理有承诺完成。
使测试人员配对程序为被动对等体。如果他们没有什么可以测试的东西，至少他们可以留意现场的错误。当他们有一些东西要测试时，在本周的第二部分，他们转向功能/“用户故事合规性”测试级别。通过这种方式，您可以使两组都具有生产力，并且基本上测试人员在继续进行代码梳理时会“梳理”它们。
速度的第一个答案，比我个人对scrum非跨职能团队和每个冲刺初期的测试人员的洞察力。
我看到那里不一致。如果团队不能跨职能，你可以区分测试人员和开发人员。在这种情况下，您必须在速度计算中区分它们。如果团队不是跨职能的，测试人员不会真正提高你的速度。您的速度将是开发人员可以实现的最大速度，但不超过测试人员可以测试的内容（如果所有内容都必须测试）。
与您的scrum master交谈，否则总是会出现速度和估计问题。
现在作为测试者和冲刺初期。我作为测试人员与5个开发人员不交叉功能团队，所以这个答案可能有点个人化。 您可以通过两种方式解决此问题：a）通过添加单独的测试冲刺来更改工作组织或b）更改测试人员的工作方式。
在a）你创建单独的测试冲刺。它可以平行于开发者的冲刺（刚刚移动那几天），或者你可以每两到三次开发冲刺就发生一次。 我听说过这个解决方案，但我从来没有这样工作过。
b）您必须要求测试人员检查他们的测试活动方法。也许这取决于你使用的实践和工具，或者你遵循的过程，但是在早期他们怎么能做到无关呢？正如我之前提到的那样，我与5名开发人员一起担任测试人员，而非跨职能团队。如果我等待开发人员结束自己的工作，我将永远不会测试给定sprint中的所有功能。除非您的测试人员仅执行探索性测试，否则在功能发布到测试环境之前，他们应该做些事情。在测试人员将特征/代码放入他的手中之前，有一些活动可以完成（或必须完成）。下面是我做的功能被释放到测试环境之前：
- 经历要求的功能被实现
- 设计测试脚本（高层设计）
- 准备草案测试用例
- 经历可能的测试数据（如果正在执行的更改是操纵系统中的数据，则需要对此数据进行快照，稍后将其与此数据的特定功能进行比较）
- 将测试套件中的所有内容合并起来
- 通信开发人员作为功能正在开发 - 通过这种方式，您可以更好地理解已实施的解决方案（而不是询问他何时已将自己的思想放在其他f eature）
- 你可以作出必要的变更作为特征的发展
然后测试情况下，当功能完成后，您： - 充实测试用例与早不知道你的任何细节（这是小事，但按钮名称可以更改，或者出现向导中的一些额外步骤）
- 执行测试
- 上升问题
。 事实上，我发现我的自己比第一部分花费更多的时间（设计测试，并在适当的工具中准备测试脚本）而不是实际执行这些测试。
如果他们所有，他们可以马上而不是等待代码被发布给测试环境应该帮助这个初始间隙，它会减少的冲刺结束前测试没有完成他们的活动的风险。
当然总是会有更少的测试人员在年底开始和更多做，但你可以尽量减少这种差异。即使上述情况仍然让他们在开始时浪费大量时间，您可以不给予任何与编码有关的任务。一些配置，一些维护，文档更新，其他。
的解决方案是从来没有黑色和白色作为每个冲刺可能包含需要测试的和其他人不的故事。例如，在分配测试人员的敏捷中没有问题;在冲刺中有50％的时间，在下一次冲刺中有20％。 尝试将测试者100％的时间分配给冲刺并尝试证明它是合理的。时间管理是关键。
测试人员和开发估计故事点数在一起。冲刺的速度总是一个综合的努力。质量保证/测试人员不能进行单独的速度计算。这是根本错误的。 如果您有3个开发人员和2个测试人员，并且您包含测试人员的能力并将其与您的输出相关联，那么生产力总是会很低。测试人员参与测试案例设计，缺陷管理和测试，这不直接归因于开发。您可以对这些测试任务进行跟踪，但无法分配速度点。
好了，什么测试人员的一周的第一部分吗？填字游戏？ :) – 2009-08-14 01:36:05
如果上一次冲刺没有结转，我们让他们设置测试计划。 – Vaccano 2009-08-20 04:36:27