在测试人员和开发人员之间处理sprint周期的结束

Question

我已经说服我们的组织采用“完成”的完整团队定义，即包含QA测试而不仅仅是代码完成的定义。因此，我们现在可以更准确地知道瓶颈在哪里，并查看我们的实际速度。此外，该项目不断集成和定期部署。在此之前，代码完整的项目被认为已经完成，QA通常会接受3-5冲刺前的故事。他们只会在sprint结束时得到交付的代码。

所以，正如你所预料的，事情进展得更顺利，但是我有一个问题在我的搜索中还没有得到很好的回答。即使使用sprinting，在sprint中似乎也有一个最大的时间，即一个故事可以由开发人员完成并在没有足够的时间进行QA之前进行部署。取决于故事和数量的事情，仍然需要测试，这似乎是2-3天前冲刺结束。

目前，我们只需继续工作，只需将QA不接受的所有项目(即正在进行和部署但尚未测试的内容)移到下一个sprint，如果它们无法完成测试。这是个好的练习吗？一些习惯于在旧系统下工作的开发人员抱怨说，这并不能为开发人员完成分配给他们的工作提供荣誉，但我觉得这样做是为了了解整个团队所做的事情，而不仅仅是开发。最终用户没有从未经测试和部署的东西中获得任何价值。然而，这个过程有预加载下一个sprint的倾向，这使得规划问题稍微多了一些。

此外，我还听说，结束sprint开发人员的间歇实际上是可以的。我们是否应该在最后留下一些开放的开发者时间呢？

Answer 1

这是你的团队的责任--整个团队--确保一切都完成。如果devs已经完成编码，并且仍然需要编写或执行测试，那么他们应该投入并帮助测试人员。

不应该有“开放的开发人员时间”--为什么给开发人员空闲时间来惩罚您的测试人员？开发人员需要帮助进行测试。它将使您的产品更好，它将使您的开发人员成为更好的开发人员，并使您的测试人员感到更有价值。

在完成当前sprint中的所有工作之前，开发人员不应该“预加载”下一个sprint。当然也有例外，但是一般来说，在所有现有的工作完成之前，他们不应该开始任何新的工作。

一些习惯于在旧系统下工作的开发人员抱怨说，这不能为开发人员完成分配给他们的工作提供信任。

这很好，因为开发人员根本不应该得到任何信用。球队获得了荣誉，不给开发人员荣誉，整个团队就变得更强大了。

Answer 2

一些习惯于在旧系统下工作的开发人员抱怨说，这不能为开发人员完成分配给他们的工作提供信任。

当sprint中没有足够的时间来完成测试周期时，他们真的及时完成了工作吗？也许，QA需要比预期更多的时间，谁知道，但是客户不感兴趣的是，谁是您的团队的责任。

敏捷的核心思想之一是通过每一次冲刺调整您的计划。如果您的VCS和分支模型使您能够简单地将功能实现从一个sprint移动到另一个sprint，那么使用它--不交付未经测试的代码肯定会给您提供更好的产品，您的客户将非常重视这一点。只要确保你没有污染你发布的产品与“开发，但未经测试”的代码-这样的代码总是未完成。

而且--正如你在你的问题中已经指出的--你必须确保你为下一次冲刺调整你的计划。当您的开发人员已经在新sprint的第一个小时提供了一个新实现的特性(因为它实际上是在上一个sprint期间开发的)时，那么QA人员将需要更多的时间在当前sprint中进行测试，或者需要更少的额外特性来测试。如果这种情况经常发生，而且您的devs所产生的输出超过QA所能测试的输出，那么您必须在您的流程或组织中更改某些内容(可能您需要更多的QA人员，也许您应该在测试自动化领域为您的devs分配更多的任务)。