Scrum方法论中Sprint末尾的未经测试产品

Question

这里有一个问题。 开发人员有一些任务（开发某些功能），需要完成一个迭代的长度。因此，在迭代结束时，开发人员会感到高兴，因为他们刚刚完成了他们的工作。

但是，由于产品不经过QA测试，因此无法将其识别为“可能可出货物”，因为它很可能会包含一些错误。

那么，问题是：如果没有自动化测试，只有人工QA工程师，我们应该如何规划我们的冲刺？延迟一个冲刺进行QA测试上一个冲刺中开发的项目是否是最佳方法？

在这种情况下，什么可以帮助我们解决问题？开发人员在QA过程中应该做什么？

- 0100110010101

---

在质量保证过程中，开发人员应该做什么？- 为下一阶段编写单元测试吗？ - EBGreen

这是关于TDD的。Scrum并不总是TDD。 - 0100110010101

这就是为什么这是一条注释而不是一个严肃的回答的原因。 :) - EBGreen

这个问题不在本站的范围之内，因此属于不适当的话题。请参阅我可以在这里问什么样的问题？和哪些类型的问题应该避免提问？。你可以尝试在其他 Stack Exchange 网站上提问，例如[pm.se]或[softwareengineering.se]。请务必阅读帮助中心的相关页面，了解您打算发布问题的任何网站的主题范围。 - Makyen

Answer 1

Scrum的一个非常重要的方面是在Sprint期间完成任务并定义完成标准。如果在Sprint期间完成了某个功能，但没有进行测试，则仍然不能算完成。

为了解决这个问题，你不应该增加Sprint的长度。短周期的Sprint仍然是首选。建议有两件事情：

第一件事情非常重要，但不一定容易实现。将QA集成到团队中。拥有一个单独的QA部门，在产品完成后验证产品，这是非常瀑布式的做法。您可能仍然希望在产品发货之前进行QA验证，但是在Sprint期间生产的内容应该在Sprint期间完成和测试。为此，您需要合格的QA人员成为团队的一部分，或者您需要培训开发人员尽可能好地进行QA。在我们公司，我们的QA部门太小了，所以我们无法为我们的团队招募QA人员。相反，我们学习了QA，并在任务板上添加了一个标题为“准备验证”的列。每当一个功能完成时，它就会移到“准备验证”列中，其他开发人员会查看这个功能。即使我们可能没有像专门的QA人员那样熟练，但我们通过这种方式不断发现问题，将其移回修复，再次进行验证。这个过程使我们更加自信地将功能归类为Sprint期间完成的，并且在以后发现的错误数量大大减少。

另一件事是开始定义更小的任务，或者更好地将功能分解为更小的部分。您不希望按照估计需要整个Sprint才能完成的功能进行工作。如果你“几乎完成”，那么你在Sprint期间并没有完成任何事情。相反，将功能分解为更小的部分，逐个解决。当某人正在处理第二部分时，另一位团队成员会验证第一部分，使开发和QA的整个过程更加集成化，从而更有可能在Sprint结束时称呼您的新功能为“完成”。

祝好运！

- stiank81

---

我在某种程度上同意：对于我来说，外部QA进行验证还是不错的，只要产品“可能可交付”。因此，如果在冲刺期间完成了验证（单元测试、集成测试），那么这仍然可以接受。实际上，增加冲刺的长度应该是最后采取的措施之一，而不是第一步。配对编程、测试驱动开发也是缩短交付时间的方法。 - Adriaan

Answer 2

很遗憾，你们并没有在执行 Scrum。你们是在迭代中使用瀑布模型，也就是所谓的 Scrum-fall。

1）将 QA（质量保证）整合到团队中。他们不应该是一个单独的小组，你需要将他们每天与开发人员一起工作来测试他们的工作。

2）让用户故事更小，更小，再小。一个故事应该花费 1-2 天完成（除非你正在制造火箭，否则一周绝对是最长时间，而且只有偶尔需要）。你需要让团队在垂直切分功能方面变得更加熟练，以创建小的可测试、可用和有价值的故事。

3）Scrum 没有职称。如果一个开发人员完成了所有编码，那么他/她会测试其他人的代码。或者致力于创建自动化脚本，这是你说你们缺少的。

4）在主要发布之前，可以有一个“硬化”迭代，但肯定必须在同一迭代期间进行测试。几乎每次提交代码时都需要进行测试。

5）修改你们对“完成”的定义。完成意味着代码已经编写、测试、可部署，并按需记录文档。

6）你们需要在“团队”和承诺方面做很多工作。你说开发人员只要完成编码就很“高兴”，这与 Scrum 及其原则大相径庭。

根据你的评论，如果你们真的想变得敏捷，团队需要投资培训。

- DancesWithBamboo

Answer 3

您可能需要调整冲刺的长度，并将完成定义为已经提交给QA或准备好进入生产环境。

这很难做到，但这也意味着要确保在看板上有测试任务。

同时，这也意味着要缩小规模，因此在中期检查时，请诚实地删除无法完成的任务，以实现“完成”的定义。

或者，这并不是最理想的方案，基本上需要两个冲刺/功能。第一个应该是让它工作，并进行单元测试，第二个是将其通过QA。因此，第二个冲刺可能会更短，但如果您要这样做，那么只需将它们合并成一个较长的冲刺即可。

- James Black

Answer 4

你的任务太大了。你需要有较小的任务（最多几天）为客户带来价值（以便进行测试）。当一个任务完成时，从开发的角度来看，QA 可以开始验证它。

也许你还需要计划更短的冲刺时间，这样增量就能在冲刺结束时得到验证。

对于转换到敏捷开发的团队来说，QA 验证上一次迭代中开发的内容并不罕见。但他们必须赶上进度。

在 QA 过程中，开发人员应该做什么？

在 Scrum 中没有专门的阶段，开发人员编写代码，而测试人员正在验证，测试人员测试时，开发人员正在写代码。当计划的任务开发完成后，他们可以撰写文档，修复 QA 报告的问题，支持 QA，估计下一个冲刺的任务......

- philant

---

除非您无法将用户故事切分为仍可测试且提供某种实际业务价值的较小块，否则缩小故事规模是正确的解决方案。在我看来，增加Sprint长度是错误的答案。无论如何，请记住，一个故事不应超过您速度的1/2 - 您可以在一个Sprint中完成的工作量 - 否则您的Sprint将会非常冒险。 - Pascal Thivent

Answer 5

我们在开发期间的Sprint中对单个功能进行QA。在该Sprint结束时，我们确保我们的主源代码分支是最新的，然后开发人员继续使用Dev分支。这使得QA可以进行发布测试，并且不会限制时间。任何错误修复都可以轻松应用于主分支，而无需在Dev分支中“撤消”任何新内容。

您更大的问题可能是缺乏自动化/单元测试。这将减少您的QA人员需要做的工作量，因此更有可能让他们更快地完成工作。

我也认为增加Sprint的长度不会有所帮助。这将迫使您添加更多的开发任务，或者让您的开发人员坐在那里等待QA赶上。

- Chris Arnold

Answer 6

将“完成”定义为开发和测试（无错误或任何其他验收标准）。将测试人员整合到您的团队中。在规划Sprint的功能时，将其分解为小任务，并使测试成为其中之一（甚至可以是多个测试任务）。因此，您将拥有由DB更改、UI更改、应用程序更改和测试组成的A特性，所有任务加起来形成一个特性。此外，请尽早让测试人员参与，不要等到开发结束。当测试人员仍在测试时，而开发人员已完成他们的任务（开发和测试之间总会有一些时间差），请将开发人员转移到其他特性的工作上。

- yoosiba

---

由于QA是一个瓶颈，所以没有必要将“已测试”作为完成的定义。我们可以自己掌握。Scrum的好处在于您可以按自己的方式操作DOD。事实上，这确实帮助了我们很多。现在，我们定义范围并放置DOD。这个任务可以在本次sprint中进行QA，也可以在下一个sprint中或甚至由另一个团队进行QA。因此，即使我们没有一个“可交付”的产品，我们也有一部分独立的软件))) - 0100110010101

如果这对你有用，那太好了。敏捷也是关于适应情况，而不是按照一种正确的方式去做事情。Scrum可以以各种方式实现，我只是给出了我的意见。然而，我对你的方法有一个问题 - 你只是把瓶颈推到了房间的角落，你觉得它不会挡住你的路。但它仍然存在。我的建议只是不同的解决方案，攻击问题的方法。嗯，至少对我的团队有用（不仅是DOD的重新定义，还有我提到的每一步）。 - yoosiba