质量检查与迭代的困境

在我的公司中，我们成功地采用了敏捷实践，但没有使用迭代。主要原因是我们找不到在迭代周期中适合QA的干净方法。

我们认为质量检查是对特定版本（候选版本）进行额外验证的一部分，然后再将其部署到客户。关键是要避免单个恶意提交会损坏整个发行版。由于您永远都不知道它是哪一个，因此质量检查人员必须等到该版本的所有功能/提交都在构建中。（不允许使用著名的最后一句话“这只是微小的变化”。）

如果质量检查人员在候选发行版中发现错误，则开发人员会在相应的发行分支中修复这些错误（并将其合并到主干中）。修复所有错误后，将部署新版本以进行质量检查以进行重新测试。仅当在某个发行候选版本中未发现错误时，才将其提供给客户进行验证。

每次发布通常需要大约2-3个候选人，大约一周。编写修补程序的时间通常比测试工作要少得多。因此，为了让开发人员忙，他们在版本N + 1上工作，而质量检查则在N上工作。

不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。

我发现这必然导致以下不良结果之一：

（A）开发人员在迭代结束时处于闲置状态，因为质量检查需要时间来验证发布候选版本，并且错误修复工作并未完全使开发人员处于忙碌状态。

（B）质量保证在准备好第一个候选版本之前就已经开始工作。这是Stack Exchange上最推荐的方法。但这不是我公司所理解的质量检查，因为没有经过测试的特定候选发布版本。破坏一切的“微小变化”仍然可以被忽略。

（C）错误将继续进行下一次迭代。在Stack Exchange上也建议这样做。我认为这根本不是解决方案。从根本上讲，这意味着我们永远不会获得经过验证的内部版本，因​​为只要进行了错误修复，就会将未经验证的新提交也添加到同一分支中。

有没有办法摆脱这种困境？

我们认为质量检查是对特定版本（候选发布版）的额外验证，然后再将其部署到客户。

这种形式的质量检查与基于迭代的方法论（例如Scrum）之间并没有内在的矛盾。
在Scrum中，团队在X周期为其客户交付可交付成果。这里的重要部分是，如果开发团队正在做Scrum，那么他们的客户就是质量检查团队，而不是产品的最终用户。

作为开发人员，如果产品有通过所有测试的巨大机会，我会认为该产品可以交付给质量检查人员。这可能意味着某些QA测试已经在日常构建中执行，但是这如何影响QA团队的正式发布测试取决于您的组织。

对于大多数现实生活中的情况，敏捷会停止交付给QA / UAT或其他要求。

在现实生活环境中从质量检查过渡到生产的工作常常被低估了。在许多情况下，这涉及真正的业务用户进行测试，从真正的业务经理行中注销管理，安排带有操作的发布等。这并非易事！

在极端情况下，该软件可能需要外部机构的认证，或者接受严格的安全测试。

在这些情况下，除了错误修复之外，不可能每季度设想一个以上的发行版。

对于严肃的软件产品来说，情况变得更糟。文档需要校对并发布。营销手册需要修改。需要向销售人员告知他们所售的产品（绝非易事！）等。您确实不希望每年进行一次以上的业务。

短期解决方案是在迭代完成后给质量检查人员额外的时间以完成测试。即。如果您有一个为期两周的迭代，请不要在第3周之前发布。无论如何，质量保证将不会在下一个迭代的第一周进行测试。

但是，我会提前警告您会发生的情况（已经在多个团队中看到了此情况）：您最终会遇到这样的情况：一次迭代完成了两周的工作，质量检查超负荷，为此而来的是您整个质量检查周以及接下来的迭代，您只需要完成一周的工作即可。那个迭代，QA无关，您会认为您已经解决了问题。但是，下一次迭代之后，您将再次开始循环。

因此，当您在该周添加完之后，只是为了确保您的发布是稳定的（因为我了解到的一件事是，如果您失去了对业务的信心，则敏捷实施的难度将成倍增加），纳入长期计划。

购买Jez Humble的《持续交付》的副本，逐页阅读，在团队中传递。激发大家的灵感。然后实施您可以利用的一切。

尽可能使构建过程更流畅。实施单元测试策略，并在每个构建中运行它们。使部署过程成为您见过的最漂亮的东西。三击？不够光滑。

一旦完成所有这些操作，偶尔偶然的回归错误就可以解决。你知道为什么？因为您可以（可选）回滚，修复它，重新部署，然后再进行业务分解。实际上，夜间管理员将能够为您回滚，此过程将非常简单。

我知道您在想什么：我们没有时间做所有这些事情。我告诉你，你愿意。如果您超载了质量检查，则每次迭代都部署过多。所以不要这样 如果您还没有使他们过载，请问他们为什么他们还没有自动化测试套件。你很快就会。

做到这一切时都具有对业务的完全可见性。降低估算值并将部分工作注入迭代中。或者，更好的是，将其分解为故事，并使其与其他所有事物一起优先处理。

向他们解释：a）它将提高发行版的稳定性，并且b）将提高您对他们的问题做出响应的能力，并且c）它将在以后提高他们的速度。这是一家罕见的公司，不需要这些东西。当然不是一家不希望他们这样做的敏捷公司，如果您遇到阻力，就会知道您遇到了其他问题。

连续交付完成后，您可以开始缩短迭代结束时质量检查的时间。尽快将并行返回迭代符合每个人的利益。也许您会在迭代结束时有一天的时间需要填写时间。我已经在其他地方回答了该怎么做。

不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。

您如何决定确切构成的方式似乎存在问题work for release N。

由于某些奇怪的原因（我只能猜出对某些特定敏捷配方的误解），您以某种方式决定了敏捷方法要求将所有QA团队的工作纳入迭代中。

• ^{如果真的是这样，我想敏捷的普及程度甚至不会接近我们现在所看到的。我无法想象有许多项目可以“生存”开发团队迭代与QA测试周期的强制同步。}

下面是关于敏捷性的更多内容，但首先，让我们整理一下work for release N...

看起来，开发团队没有必要以这种方式定义工作。恰恰相反，从您的描述中可以很明显地看到，有几个这样的单元而不是整体的“工作单元”，它们具有易于感觉的里程碑……

• ^{例如，候选人建立时，第一个“单位”由明显的里程碑表示传递给测试人员，其他里程碑对应于QA等执行的测试周期中涉及的更改。}

还要注意，您定义的方式 work for release N也不是质量检查工作流程所强制的。从您所描述的事物来看，它们似乎有自己的（并且非常合理）的时间表。

鉴于以上所述，在您的情况下定义工作单元的更现实的方法如下所示：

1. 直到将构建传递给QA为止的开发活动
   Release Candidate N
2. 与第一个质量检查测试周期有关的开发活动
   Release Candidate N patch 1
3. 与第二个质量检查测试周期有关的开发活动
   Release Candidate N patch 2
4. 等，直到最终版本

上面是您的工作单位，无论您是否执行敏捷或其他任何操作。

这些是自然的，可以方便地定义，跟踪和跟踪。这也与质量检查计划很好地融合在一起，从而便于odf开发人员和质量检查人员进行协调。

但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。

以上了解与敏捷的兼容性看起来根本上是错误的，这就是为什么...

您所做的假设与敏捷无关，如果我们将敏捷的哲学视为其名称所指的面值，那么这是一种支持并实践敏捷的方法。。

从这个角度来看，坚持特定的“固定”工作流程，而忽略它是否方便，恰恰与敏捷的精神相矛盾。亦步亦趋地遵循“程序”导致实践诋毁的雄辩半Arsed敏捷宣言 “......我们有强制性的流程和工具来控制如何将这些个体（我们更喜欢用‘资源’）相互作用”。

您可以在下面引述的另一个问题的答案中找到有关此内容的更多信息。看一看关于“可发布的版本”的注释，看起来OP曾经以类似的方式被混淆了：

一个应该是敏捷关于敏捷原则非常适用。我的意思是，如果项目需求不够灵活（稳定或变化缓慢），那又何必呢？我曾经观察到高层管理人员在没有进行得很好的项目中强迫Scrum。真是浪费。不仅交付没有任何改善，更糟糕的是，开发人员和测试人员都感到不满意。

对我来说，敏捷最重要的部分之一是在每个sprint的末尾都有可发布的版本。这意味着几件事。首先，如果您认为可以将构建版本发布给客户，则必须进行一定程度的测试，以确保没有显示一流的错误...

我看到了可发布的版本。嗯 嗯 考虑增加一两个精益在您的敏捷鸡尾酒中。我的意思是，如果这不是客户/市场的需求，那么这仅意味着浪费（测试）资源。

我一个人认为将Sprint-end-release视为满足团队要求的检查点没有任何犯罪。

• ^{dev：是的，看起来不错，可以传递给测试人员；QA：是的，如果需要进一步的可交付测试，那么这种情况看起来足够好。团队（开发人员+质量检查人员）很满意，仅此而已。}