我只是在那本书Scrum and XP from the Trenches的中间，阅读我们如何测试一章，特别是关于验收测试阶段（我将其称为 ATP ）。作者建议采用一种方法：
方法2：“可以开始构建新的 东西，但优先考虑旧的 东西投入生产“
但是（在我看来，或者我没有得到什么）这种方法根本不涉及ATP。有一个冲刺，然后是另一个，但ATP在哪里。或者也许在作者心目中，第一个sprint中包含ATP。如果是这样，那么它如何引用声明表格子章节验收测试应该成为sprint的一部分吗？之前几页：
我们在这里动摇了很多。我们的一些团队 包括验收测试 短跑。然而，我们的大多数团队 不要，因为两个原因：冲刺是 时间盒装。验收测试（使用 我的定义包括调试 并且重新释放）很难 时间盒。如果时间用完了怎么办？ 你还有一个关键的错误吗？你是 准备发布到生产 关键的bug？你要等吗？ 直到下一个冲刺？在大多数情况下都是 解决方案是不可接受的。所以我们 离开手动验收测试 外。如果你有多个Scrum 在同一产品上工作的团队 必须进行手动验收测试 两个团队的综合结果 工作。如果两个团队都做了手动 在冲刺中接受，你 仍然需要一个团队来测试 最终发布，这是集成的 建立两个团队的工作。
所以伙计们，（这是问题）：你如何理解这一章？
除此之外我的想法是：作者提到由于严重的错误问题，ATP不应该成为Sprint的一部分？好吧，如果没有ATP冲刺，我们不能有这样的问题吗？我们可以。无论哪种方式（我们在Sptint中都有ATP）我们都遇到了麻烦。底线：如果Sprint时间框足够长（也许这是作者在方法2 中的想法），它也可以处理ATP。它将消除发布后到达的大量错误。
谢谢，Pawel
P.S。您是否知道有哪些页面可以与图书作者进行实际聊天？
P.S。 2在发布之前阅读我的问题时，我只是开悟了：也许是说：
方法2：“可以开始构建新的 东西，但优先考虑旧的 东西投入生产“
作者：Sprint 1完成，代码库（1.0.0版）进入ATP。与此同时，我们将在1.1.0版本上启动Sprint 2，同时修复1.0.0版本中出现的错误。当在Sprint 1期间准备的代码库一尘不染时，它就会上线。所以在这里，我们有一些重叠之王。但是，如果这是作者的意图（我确信它不是），那么它就违反了基本原则：
总而言之，那本书很精彩，但那篇章节如果有点模糊（我在阅读过程中读到的那个很酷的词）也给了我。
答案 0 :(得分：1)
验收测试与构建软件几乎没有任何关系。
你尽可能快地建立。
用户接受某些功能（或拒绝某些功能）。
您没有通过验收测试找到“严重错误”。该软件已经运行。用户只是不喜欢它的工作方式。这不是一个错误。这是一个错误的沟通，将在下一个冲刺中修复。
您可以（通过一些调整）部署Accepted软件，这是测试软件的一个子集。人们一直这样做。
我们经常隐藏功能，页面，按钮，屏幕等等，因为它们不被接受。他们通过了单元测试。他们工作。但由于某种原因，他们没有被接受。所以他们没有部署。
通常，用户的原始定义有问题，需要修复单元测试，以便在下一版本中修复和部署代码。
对功能的接受没有与它是否有效以及内置的sprint有关。如果它是一个平滑的包，可能会很好。但是，它通常不是一个顺利的包。那就是为什么我们必须敏捷。
答案 1 :(得分：0)
在冲刺接受标准开始时的IMO应该是众所周知的并且针对每个用户故事进行修复。为了能够在冲刺回顾中将故事标记为“完成”，验收测试必须成功。因此，IMO属于冲刺！
我想提及Mike Cohn的“敏捷估算和规划”。他提倡在其后的用户故事中写出验收标准。它们是冲刺审查中批准的基础。从这个声明中我得出了在冲刺中拥有ATP的必要性！
更改要求或验收标准会产生新的用户故事。但你永远不会改变正在进行中的那些。
如果验收测试要自动化，这项工作可以在冲刺期间完成。但是，潜在的标准应该已经在冲刺开始时得到解决。