Scrum-冲刺期间团队成员忙什么

因此，Scrum冲刺是一个固定的时间段，在此期间应实现一组特定的功能。Scrum团队由致力于提供这些功能的所有人员组成，其中大多数通常是开发人员和测试人员。

建立了这些规则后，您可能会想知道如何在整个冲刺期间让所有这些人都忙。在sprint的开始阶段，没有什么要测试，而在sprint的末尾，通常没有什么东西可以开发/修复。

我已经看到了两种方法可以解决此问题，但是它们似乎都无法正确解决问题。

1）让团队成员决定在任务结束时应该做什么。

缺点：

• 如果他们的工作没有得到充分的计划（例如，重大的重构，改用新的测试框架），那么他们的工作可能会变得毫无用处，或者被困在中间
• 另一方面，计划这样的工作可能要花费大量时间，并且客户可能会失望地看到团队浪费时间在无法带来即时价值的事情上
• 通常无法对这些任务进行彻底的估算，因此，无原则的工作人员很容易花时间看YouTube猫，而不会在Scrum板或其他任何地方反映出来

2）在sprint中留出仅用于开发的空间，并在sprint完成后开始测试（当开发人员开始处理下一个sprint的功能时）

缺点：

• 在为当前sprint开发功能时，开发人员会通过修正前一个bug来分心，而他们可能无法执行估计在当前sprint期间完成的工作量
• 需要两个Scrum板：一个用于当前的sprint功能，一个用于以前的sprint错误

所以我的问题是：如何在开发人员和测试人员之间的冲刺期间正确分配工作，以使任何人都不会负担过多的工作，或者在任何时候都没有任务而最终失败？有什么方法可以改善上述方法？还是有更好的方法？

在冲刺开始时，尚无任何测试

真？您没有验证要求吗？没有与您的客户进行讨论？没有评估的线框？没有要考虑的测试计划？

在冲刺结束时，通常没有任何东西或只有很少的东西可以开发/修复

我从来没有去过那个项目中的那个地方。没有更多工作要做？总有东西。您的所有测试都完全自动化了吗？您的CI看起来如何？能否将数据库访问层重构为更简单？而且我从来没有做过带有空错误列表和未完成订单的工作。您的开发人员在瀑布测试阶段曾经做什么？

我知道有人对什么是“ SCRUM”非常虔诚。我对此一点也不在乎。但我认为您在这里有两个问题：

1. 一个“传统的”质量检查部门，负责在开发人员“完成”代码后对其进行测试，而不是与客户和开发人员合作以确保您构建正确的事物以及正确构建事物。看看Lisa Crispin 的敏捷测试象限。最好的测试人员会参与软件开发生命周期的每个阶段，并且最好的开发人员会编写自己的测试。

2. 尝试过于严格地遵循1周/ 2周冲刺的SCRUM时间表，而没有按优先级划分大小的待办事项，这些积压工作分解成易于在短时间内在单个冲刺中完成的任务。如果您有这个，那么总会有更多工作要做。也许您在此sprint中使用的最后一个功能不会加入该sprint的发行版，但始终可以进入下一个功能。

在旁边。如果您的团队凝聚力很小，那么角色的作用就较小。与其让标签测试人员不允许编写生产代码，或者让标签开发人员认为自己已经超出测试水平，不如让每个人都为团队成功做任何必要的事情，包括在执行任务时所犯的可怕的项目管理任务。他们是必要的，这称为跨职能团队。

@Cort Ammon在评论中提出了另外一点。敏捷宣言谈论的是客户在合同谈判中的协作。你说：

客户可能会失望地看到团队浪费时间在没有带来立即价值的事情上

这可能很难解释，而且我了解客户有时可能非常困难，但这对我来说是一个很大的危险信号。他们相信他们的源代码/客户关系/业务/您为他们开发的内容。如果他们不信任您以他们的最大利益行事，那么您可能会遇到问题，或者他们会这样做。

我写了一篇文章，谈到软件开发人员不被视为专业人员。专业的医生，律师，土木工程师面对客户，他们在整个过程中改变了对他们的要求，这不仅会降低质量，还会抱怨。他们会告诉客户这将是一个问题。如果客户推了推，那么专业人士将不会只是盲目地以低劣的低劣标准来做，因为他们将承担责任。我们不参加专业的入学考试，因此不承担任何责任。这并不意味着我们不应该尝试变得更好。

总而言之，我不会太担心在冲刺的开始和结束时让人们变得更有效率，而是将其视为团队中更广泛问题的征兆。您是否听说过eXtreme编程（XP）。我想说XP中适用的原则是沟通和尊重：

• 尊重您的团队做他们认为最好的事情。我会说，如果有很多观看猫的视频，那么您要么开发人员欠佳，要么对待他们的待遇不佳。
• 通讯。如果您的开发人员正在互相交谈，与测试人员，与管理人员以及与客户进行交谈，那么每个人都应该对接下来发生的事情有很好的感觉，如果没有，他们可以问问。

第一点是，Scrum只是为了优化团队，而不是每个人。如果团队高效且高效，那么在任务开始或结束时有人闲置就没有关系。

但是，在我所服务的每个团队中，总是有很多工作要做。让我解决您的一些具体问题：

在冲刺开始时，尚无任何测试

尽管从字面上看可能是正确的，但这意味着您认为测试人员的唯一工作就是“测试”。在他们开始测试之前，有很多事情可以做。首先，他们可以与产品所有者和开发人员会面，以充分了解需求。他们可能会忙于制定测试计划，收集测试数据等等。如果他们拥有一个好的框架，那么他们可以提前开始编写自动化测试。

在冲刺结束时，通常没有任何东西或只有很少的东西可以开发/修复

我还没有看到一个开发团队用光了要修复的东西。但是，这不是他们在冲刺结束时应该做的。在冲刺即将结束时，他们应该帮助测试人员测试产品。他们可以帮助编写自动化测试，可以对测试人员编写的测试和装置/关键字/代码进行代码审查。他们可以与文档团队合作，以帮助他们完成工作等。

我已经看到了2种方法来解决此问题... 1）让团队成员决定在任务结束时应该做什么。

您的思维缺陷是个人无法完成任务。任务总体上属于团队。只要当前的Sprint中还剩下团队需要的故事或任务，他们就不应该做其他工作。

在冲刺中腾出空间仅用于开发，

这种方法不在Scrum或Agile的传统定义之内。敏捷的全部要点是整个团队都致力于实现一个共同的目标。这意味着完成故事所需的所有工作都必须以冲刺的方式表示-设计，开发，测试，文档等。

最后，这不是唯一可行的解​​决方案。您忽略了真正的解决方案，那就是每个团队成员都应按需介入以帮助完成冲刺中的故事。

目标是团队目标，但您正在写作，好像每个人都有各自的目标（“完成任务”）。如果某人无事可做，他们可以看到当前正在做什么，并愿意提供帮助。或者，他们可以接下一个任务或故事并开始进行工作。

在我工作过的所有敏捷商店中，测试人员都被视为鸡，因此它们不会像开发人员那样被限制在sprint中。在尝试使用该软件之前，测试人员应编写计划，并确保正确设置了环境以接收该软件。为此，他们应该关注所有设计文档。

接下来，您应该寻求填补冲刺。如果估算不错，则冲刺结束时不应有任何空闲时间，尽管估算当然是一种妖术，所以很少准确地填满。

如果开发人员在冲刺结束时确实有空闲时间，则仍应跟踪该时间以确保它正在增加价值（学习新框架，进行分析，进一步测试等）。

修复错误是进入sprint的一种完全可以接受的活动。它有助于功能，因此增加了价值。这不应视为从下一个冲刺中偷走了时间-更恰当地完成一项功能。

在理想的世界中，您的团队将是跨职能的。每个人都有自己的专业领域，但每个人也都可以作为另一个专业领域工作。如果您的测试人员无法编写最简单的任务，那么您就没有跨职能团队。

SCRUM方法将使您的团队具有跨职能的能力。无论如何，您的测试人员都应该具有测试自动化的技能，这是编码一些不太复杂的事情的一小步。