Scrum-在Sprint之外工作的开发人员

Scrum团队

• 3 x开发人员
• 2个测试仪
• 1 x自动化测试分析师

我们不是一个多功能的团队，因为开发人员不进行测试，测试人员也不进行开发。我相信这是问题的根本原因。

我们目前进行两周的冲刺。

冲刺开始时，每个人都很忙，开发人员开始开发工作，而测试人员正在准备测试（编写测试用例等）。

一旦测试人员完成了准备工作，他们现在正在等待开发工作完成，或者开发工作已经完成，开发人员正在等待反馈/错误。

开发人员在这里发痒，开始处理积压中当前冲刺之外的项目。这产生了一种奇怪的影响，即我们总是在当前的Sprint中开发下一个Sprint。对我来说，这感觉不对。

从管理层的角度来看，他们宁愿开发人员做工作，也不愿坐在办公桌前不做任何事情，但与此同时，我觉得Scrum团队的目标和重点应该完全放在当前的sprint上。我希望我们的团队是多功能的，但不幸的是这是无法实现的。测试人员没有进行开发工作所必需的技能，并且大多数开发人员都认为测试在他们之下。

这是Scrum中的问题吗？有针对这个的解决方法吗？Scrum仅与多功能团队一起工作吗？

如果可能的话，我想知道其他人的经验:)

这是由流水线引起的一个相当普遍的问题。团队是多功能的，但是当然存在内部孤岛，这会降低绩效。

首先，我想指出一些我认为很重要的事情：

1. 如果您的开发人员提前进行迭代，那么他们将抢占您的计划会议。您的产品经理和团队需要适当地讨论下一次迭代中最有价值的东西。优先级划分不应由开发人员有效地完成，因为他们无事可做。

2. 无论您如何划分和安排迭代，只要您的团队中有专家在孤岛上工作，您都无法真正让所有人一直忙碌，只有一个团队参加一次计划会议。即使采用纯瀑布式方法，您仍然需要“将东西扔在墙上”并等待反馈。

3. 您还遇到了一个问题，即通常单个故事需要一个开发阶段，一个测试阶段，一个错误修复阶段，然后是...这确实会使您的团队效率低下-尤其是如果他们事先工作， ，因为它们需要上下文切换。

显然，这种情况要付出非常现实的代价：团队没有合作。每当有QA团队参与时，我都会遇到这个问题，所以我有一点时间来尝试不同的解决方案。

这两个工具对我来说非常有效：

1. 强调整个团队负责完成工作的原则。拒绝“开发完成”的故事，因为它们是开发人员说“不再是我的问题”的一种方式，这既不是建设性的，而且显然是错误的。如果一个团队没有交付他们接受的故事，那么整个团队就没有交付。

2. 要占用开发人员和质量检查人员的时间，请将它们配对。到目前为止，这是共享您可以选择的专业知识和领域知识的最佳方法。开发人员可以帮助测试人员自动化他们的任务。测试人员可以向开发人员展示测试代码的重要位置，因为它很脆弱。双方合作和工作总比没有快。

使用这两种技术，团队应该得到更少的孤立和更高的绩效。尽管测试人员和开发人员不太可能交换工作，但他们将能够团队合作并在内部解决问题，而不必互相指责。

与SCRUM和sprint有关的工作方式没有问题，只要它可以在评估时记录下来，即开发人员的工作在比计划的时间短（以及少的时间）内完成。这将使团队在下一个冲刺中承担更多的故事要点。毕竟，冲刺的目的是要更好地进行计划。显然，您仍有改进的空间。

我们一直在开发当前Sprint中的下一个Sprint

哇！这在Scrum中是不可能的。您不知道下一个冲刺中将有哪些积压项目，即在冲刺计划会话中的下一个冲刺开始时要确定的积压项目。

了解组织发明以破坏Scrum的新创意方式仍然很有趣。

Scrum为团队而不是个人优化。整个争夺点在于团队的效率。如果开发人员开始处理当前冲刺之外的事情，那么他们会对团队造成损害。它还表明，如果您没有计划足够的工作来填补弹簧，那么您在计划过程中会有些失败。

如果开发人员用完了开发任务，他们绝对应该介入并帮助测试人员，技术作家或设计师-团队中的任何人。他们不一定必须编写实际测试（尽管应该），但是他们仍然可以参与测试过程。他们可以编写脚本来帮助测试人员提高效率，或者他们可以简单地与测试人员讨论他们的挑战，然后去帮助他们克服这些挑战（例如：向网页元素添加id属性，提供测试人员可以使用的钩子或API）可以在他们的测试中使用，等等）。

我认为问题的核心在于，如果您的开发人员并不总是在当前的sprint上工作，那么他们还没有团队合作。您的Scrum主管应该引起注意，并努力使团队作为一个整体而不是个人的集合而工作。

我还建议这是一个管理问题。如果他们向开发人员施加压力，使其忙于工作，那么他们还没有完全接受Scrum。这是Scrum管理员可以帮助的另一件事。他们可以与管理层合作，以帮助他们了解Scrum的工作原理，从而可以帮助支持和鼓励开发团队，而不是颠覆他们。

我认为这里的关键问题是：

大多数开发人员认为测试在他们之下

我们在公司中处理此问题的方式是，我们问开发人员，如果他们无法证明自己的工作，怎么能说他们实际上完成了工作。当然，证明它的唯一方法是证明他们编写的代码确实有效，并且这是通过测试完成的。应该向他们指出，如果他们同意参加测试，那么测试将更快完成，并且他们将有更多时间编写其他功能（也需要进行测试）。

指出测试代码不在开发人员级别之下。它是开发过程中不可或缺的一部分。它不能与仅编码分开。任何人都可以编码。并非所有人都能编码并证明他们编码的内容确实有效。

保持开发人员忙碌的另一种方法是让他们为在sprint中开发的功能编写自动测试代码。这些测试然后可以用于将定期运行的回归测试。

无论哪种方式，在冲刺开始时都计划不做的事情都是大禁忌。最好什么也不做，比做一些计划之外的事情要好。在这种情况下，他们编写的功能很可能不符合DoD（完成定义）标准，因为它可能没有经过良好的测试，因为测试人员正忙于测试最初计划的内容。这是一种引入错误并降低产品质量的肯定方法，然后使团队陷入回归问题和上下文切换的下行漩涡中，从而导致压力，速度降低，并最终因此退出团队。

从理论上讲，SCRUM团队的所有成员都应具有相同的知识，以便每个成员可以承担其他每个成员的每项任务。如果没有，您应该传播知识。

但是实际上，总会有某种专业化。该软件可能很复杂，团队成员具有不同的技能，等等。将团队分为开发人员和测试人员只是一个（非常常见）的专业化示例。

传播知识所花费的时间可能比管理层希望接受的时间更多。

以我的经验，您可以做几件事：

• 不要使团队太小。例如，如果您有4个开发人员和4个测试人员，则将任务移到另一个开发人员或测试人员要容易得多，而在此示例中只有3/2。
• 尝试分解更大的任务。如果您有更小的任务，您将更加灵活。
• 定义一些可选任务，如果还有时间可以完成。

这些建议可能不是100％SCRUM理论，但首先您必须保持开发正常进行。SCRUM只是一个工具箱。

看来您需要使团队不同步。像那样：

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

如果我理解测试自动化人员必须提前几天开始。

但是我感觉到您的团队中存在一个问题：开发人员遇到了一个问题，即他们没有测试自己的代码。如果测试人员在不检查代码的情况下准备测试，则他们可能仅在进行黑盒测试，而没有考虑已开发程序的决策点。您对软件的质量感到满意吗？