如果质量检查需要12周，我们是否应该放弃尝试敏捷？

我公司中的某人最近提出了对核心产品的更改，经理们认为这些更改应触发我认为我公司认为完整的质量检查周期（即，从头开始测试整个产品套件）。显然，我们的质量检查需要12周才能完成产品的完整质量检查周期。我的问题是我们正在尝试进行敏捷开发（尽管在我看来，这大多是半估的）。我们将完成一整套冲刺，然后发布，我想质量检查将永远花费那一次。问题是，如果我们的质量检查要花12周才能完成工作，我们是否就应该放弃尝试敏捷开发？在这种情况下尝试敏捷的意义何在？

好吧，恐怕您的问题的直接答案将是Mu-只是没有足够的细节来做出明智的猜测，您是否应该放弃尝试。

我唯一能肯定的一点是，敏捷性水平应该由客户/市场需求（您没有提供任何信息）决定。

• ^{例如，作为IDE的用户，我非常高兴每年一次或两次升级到新版本，而我从来不着急这样做。也就是说，如果他们的发布周期为3个月（12周），那么我对此非常满意。
   
  另一方面，我可以轻松地想象，如果金融贸易公司的软件要花一个多月才能适应市场变化，它就会破产- 在这种情况下12周的测试周期将是一条通往地狱的道路。现在-在这方面您的产品需求是什么？}

要考虑的另一件事是满足您的客户/市场需求需要什么级别的质量？

• ^{恰当的例子-在我曾经工作的公司中，我们发现我们需要某些软件供应商许可的产品中的一些新功能。如果没有此功能，我们将遭受很大的损失，因此，是的，我们确实希望它们能够敏捷并在一个月内交付更新。
   
  是的，他们似乎很敏捷，是的，他们在一个月内发布了该更新（如果他们的质量检查周期为12周，那么他们可能会跳过该更新）。而且我们的功能运行得很好-猜猜我们应该很高兴吗？没有！我们在某些功能中发现了showstopper回归错误，该错误之前还可以正常工作-因此我们不得不忍受旧版本。
   
  又过了一个月-他们发布了另一个新版本：我们的功能在那里，但同样存在回归错误：再次，我们没有升级。又一个月又一个。
   
  最终，我们仅在半年后就对其敏捷性进行了如此大的升级。}

现在，让我们仔细看看您提到的这12周。

您考虑过哪些选择来缩短质量检查周期？从上面的示例中可以看到，简单地跳过它可能无法满足您的期望，因此您最好保持敏捷，并考虑采用其他方法来解决它。

例如，您是否考虑过改善产品可测试性的方法？

或者，您是否考虑过采用蛮力解决方案来雇用更多质量检查人员？无论看起来多么简单，在某些情况下这确实是必经之路。我已经看到经验不足的管理人员试图盲目地雇用越来越多的高级开发人员来解决产品质量问题，而这些人员中只有一对普通的专业测试人员就足够了。真可悲。

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

根据评论中的说明进行更新

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

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

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

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

...您提出的最重要的观点是在响应的最后，即如果需求不是敏捷的，则不应用敏捷。我认为这是正确的。当我们开始进行敏捷时，我们就拨入了敏捷，这种情况是合理的。但是自那时以来，情况发生了巨大变化，我们一直坚持这一过程可能不再有意义。

您完全正确。同样从您的描述看来，您已经了解了状态（团队/管理的成熟度和客户关系），从而可以使用常规的迭代模型开发来代替Scrum。如果是这样，那么您可能也想知道，根据我的经验，在这种常规迭代中，比Scrum更有生产力。更富有成效-根本就这么少得多的开销，它只是这么容易把重点放在发展（QA为分别着重测试）。

• ^{我通常以Ferrari（作为常规迭代）与Landrover（作为Scrum）的角度来考虑。
   
  在高速公路上行驶时（您的项目似乎已经到达那条高速公路上），法拉利击败了Landrover。
   
  在越野车上，人们需要吉普车而不是跑车-我的意思是，如果您的需求不规律和/或团队合作和管理经验不是那么好，您将不得不选择Scrum-仅仅是因为尝试规律性会得到您陷入困境-就像法拉利会陷入越野一样。}

我们完整的产品实际上是由许多较小的部件组成，这些部件都可以独立升级。我认为我们的客户非常愿意更频繁地升级这些较小的组件。在我看来，我们也许应该专注于在冲刺结束时发布和质量检查那些较小的组件……

以上听起来是个好计划。我曾经在这样的项目中工作过。我们发布了每月发行的版本，这些更新包含本地化的小型低风险组件，并且针对这些组件的质量检查签字非常容易。

• ^{此策略要牢记的一件事是进行可验证的验证，以将更改本地化在预期的位置。即使就未更改的组件进行逐位文件比较而言，也可以这样做，否则您将无法获得它。问题是，质量保证负责发布质量，而不是我们的开发人员。
   
  确保不会发生意料之外的变化是测试人员的头疼-因为坦率地说，作为一名开发人员，我有足够多的其他东西来担心这对我来说更重要。因此，他们（测试人员）确实确实需要有确凿的证据证明事情在他们进行测试的发布过程中得到了控制。}

哦，我确实感觉到你的痛苦。您需要对质量检查小组进行一些认真的更改才能使其生效。

我的建议是将团队分为三个团队：

功能测试 -快速测试新开发的产品。

回归测试 -在产品出厂之前进行全面测试。即使减少了团队规模，这也不需要花费3个月的时间，因为大多数错误都将由第一团队发现。

自动化测试 -编写全套回归测试以加快回归测试团队的工作。

第三支球队是一笔奖金，但是如果您不能拥有前两支球队，那么您也很可能是瀑布。

举例说明：

请注意，您的质量检查小组可能正在（ATDD）圈子之外工作，而您正在内部工作。

我认为可以这样工作。如果您可以在自动化测试中证明您在每个冲刺中都满足客户的要求，则可以允许质量检查人员在闲暇时进行他们的测试，并提出缺陷，然后您可以进行下一个冲刺。

听起来您有“完成的定义”问题。

鉴于您的质量检查小组是外部人员，并且仅涉及客户发布，因此您不能依靠他们及时就问题进行反馈。这意味着，如果您需要快速的反馈，则必须为团队进行一定程度的“内部”测试。

将质量检查小组视为不存在。行动是，如果您在sprint末尾发布的版本将在第二天部署到您最关键的环境中。在准备好将其提供给客户之前，该软件尚未完成。

质量检查一无所获。

这将很难实现。您可能会遇到一些前几次偷偷摸摸的事情。自动化的验收测试和“回归”测试是您最好的朋友。TDD将帮助您建立此类套件的大部分。您应该能够迅速知道是否损坏了任何东西。

您是否有客户代表/产品负责人，可以在完成质量检查之前查看给定的版本并给予权威性的反馈？如果是这样，您可以在将QA视为次要的，有些缓慢的反馈源的同时，使用敏捷方法，并从中获得最大收益。在进行质量检查后，发行版只能“正式准备就绪”，但您不必等待下一个版本就可以开始下一个版本。

但是，如果公司规则说客户在完成质量检查之前一定不能看到发布，那么您几乎可以忘记敏捷，直到您设法更改这些规则。

您描述的过程不是敏捷过程。具有高度敏捷性的团队能够在每个Sprint中交付可靠且可能发布的版本。在大多数敏捷实施中，QA功能是在敏捷团队内部构建的，有助于实现这一目标。

如果您，您的项目负责人，您的产品所有者和开发人员没有一起工作，并且您没有改进计划（回顾性的），请为流程命名，然后继续。您的团队问题似乎不是经理或质量检查人员的错。他们似乎正在对开发组织中出现的一些系统性问题做出反应。如果团队愿意承担责任并开始与利益相关者合作，那么一切都不会丢失。

您可以尝试三件事。第一，确保每个利益相关者具有明确定义的角色，并且每个人都了解自己的责任。第二，稳定构建，然后在不引入更多更改的情况下获得质量检查的批准。三，研究所测试自动化。质量检查团队会为此而爱您。

遗憾的是反馈花费了这么长时间，但是我不认为敏捷就值得停止。在冲刺（或一对冲刺）结束时，您发布一种产品，并确信它可以投放市场。敏捷为您的团队带来了专注于要完成的工作并保持产品可发布的能力。当质量检查人员发现问题时，我建议为这些问题创建错误报告，并在下一个冲刺中解决（如果它们具有足够高的优先级）。

我们的产品现场测试需要整整8周的时间，而且我们依赖外部种植者。通过敏捷，我们仍然可以专注于手头的工作，并在需要时快速地制作新版本。

问题在于（您认为）质量检查部门可以在那里解决问题？你讨论过了吗？

12周的时间很长，但是希望质量检查人员能够在这段时间内（而不是三个月之后）为您提供反馈和错误报告。

然后，您仍然可以敏捷地响应最重要的问题，并且甚至可以在还没有完成之前就解决许多问题！

执行多个冲刺时，质量检查人员在做什么？听起来他们觉得需要在每次更改后测试所有内容（这就是为什么他们等待一堆更改的原因。）。

开发团队是敏捷的，但公司的其余部分则不是。

负责质量检查的人要么不知道他/她在做什么，要么他们在高层管理人员中担任绝地绝招，并允许他们度过美好的时光。质量检查如何比开发花费更长的时间？