滥用术语“代码冻结”[关闭]答案

【问题标题】：Misusing the term "Code Freeze" [closed]滥用术语“代码冻结”[关闭]
【发布时间】：2009-10-13 01:40:51
【问题描述】：

我只是好奇社区是否认为在我们停止开发（除了测试和修复错误）的情况下使用“代码冻结”一词是可以接受的。

发展情况

我们刚刚完成第三次也是最后一次冲刺，随后将进行“代码冻结”和为期 2 周的 Q/A 测试。这是一个大版本，一些组件的开发已经超越了所有 3 个冲刺。从历史上看，即使我们称之为“代码冻结”，我们仍然会提交代码来修复错误。

问题

每个版本我都会尝试纠正我的经理和同事，我们应该将其称为“功能冻结”，因为很明显，我们会在开始时立即找到错误并提交代码来修复它们重度测试。但他们仍然坚持称其为“代码冻结”。有时我们仍然有已知的错误并声明“代码冻结”。

维基百科的定义似乎与我一致 here

分析

我怀疑将这些情况称为“代码冻结”是某种故意的Double Think 为利益相关者提供虚假信心。或者我们假装处于“代码冻结”状态，因为根据 Scrum 在每个 sprint 之后我们应该有一个可交付的软件，这是我们遵循 Scrum 的期望。所以我们必须按照 Scrum 的期望来称呼它，而不是它的真正含义。

结论

我是否过度分析了这个？我只是发现忽略现实情况是不健康的，应该放弃将其称为不是的东西或解决根本问题。有没有其他人在代码冻结方面有类似的经历？

【问题讨论】：

如果您确实“代码冻结”，即您不会再次更改代码，那么您最好立即发布生产。从今天到您真正执行 RTM 之间没有任何变化，为什么还要等待？因此，只需将其称为 RTM 而不是“代码冻结”。每当我在一个使用它的团队中时，“代码冻结”意味着“除了修复少数剩余的测试失败之外的所有代码更改都应在下一个版本的分支上”。基本上，“除非 QA 和/或产品经理另有说明，否则冻结”。
还有比这更糟糕的双说——如果是双说的话。经常听到人们问“您是否在 2.34.56 版本中包含错误 314159”；他们不是那个意思——他们的意思是“您是否在版本 2.34.56 中包含了对错误 314159 的修复”。而“代码冻结”从根本上意味着“从这里开始对代码的任何更改都受到严格控制”。
“代码冻结”听起来很迟钝，而“功能冻结”更有意义，听起来更酷，因此我更喜欢“功能冻结”这个词。

标签： testing process agile scrum code-freeze

【解决方案1】：

我是不是分析过度了？

是的。

嗯，可能。实际上，在冻结后进行任何代码更改之前，您应该三思而后行。错误应该通过一些严重性测试，如果修复需要对代码库进行潜在危险的更改或使已完成的测试无效，则更是如此。如果你不这样做那个，那么是的，你只是在自欺欺人。

但是，如果您不打算修复任何个错误，那么冻结代码就毫无意义：只需构建并发布即可。

最终，重要的是你们都了解标签的含义，而不是标签本身。一个大快乐的矮胖子...

【讨论】：

既不是代码冻结也不是功能冻结。这只是编码冲刺之后的“仅测试”冲刺。谁在乎你叫什么？严重地。如果因为人们不理解而减慢了工作速度，那么您可能需要考虑一下。但是，如果每个人都知道发生了什么，那么他们可以称之为“去西伯利亚”或“拉普兰时间”或“大寒”，或者——坦率地说——他们选择的任何代码短语。这只是文化和习俗。从字面上看，事实描述对任何人都没有帮助，不是吗？

【解决方案2】：

我们使用“功能完备”一词。所有功能都已编码且功能齐全，但我们正在进入测试阶段以确认没有错误。如果有错误，我们将找到它们，修复它们并重新测试。在我们对结果感到满意后，我们就“代码完成”了。

【讨论】：

【解决方案3】：

实际上，我认为他们的解释更正确。对我来说，功能冻结将停止引入新功能，但目前正在开发的功能可能会继续完成，或者您可以安排一些重构工作以消除技术债务而不产生新功能。代码冻结会停止所有新开发，包括重构——唯一允许的新代码是修复在 QA 期间发现的错误。后者似乎是您的团队正在做的事情。

【讨论】：

我们就称之为开发冻结吧。

【解决方案4】：

一些采用像 scrum 这样的自适应和敏捷工程方法的人可能没有意识到你自己陷入了什么。

敏捷工程的原因是向您的客户发布现在可用的任何东西，并逐步建立其可用性和功能。

如果您的项目预计在 18 个月内完成，但如果您可以每 2 个月有更多可用的东西 - 为什么不每两个月发布一次功能，而不是等到 18 个月后的盛大圣日，因为无论哪种方式，项目仍然会过去 18 个月。
您的客户的要求可能会发生变化，因此让您的客户有机会经常改变主意，以免为时已晚，从而让客户兴奋不已。
有人可能会在 10 个月后发布您的某个模块的开源模块，然后您无需做太多其他事情，只需集成该模块。

因此，Scrum 的动态需要 Scrum 人员，或者至少是 Scrum 主管和/或项目经理/架构师来模块化……模块化还不够好；但要细化项目。

您必须将模块细化到合适的大小，并为每个模块提供合同接口规范，以便在模块内管理模块内的更改。如果您的模块本身或由于其他模块的依赖无法满足合约接口，您必须冻结代码以使您能够广播合约接口版本 1，以便其他团队可以继续，尽管功能少于预期在下一个通用产品版本中。

代码冻结就是代码冻结。

如果您的代码冻结时经常遇到解冻延迟，则说明您的 Scrum Master 和产品架构师没有沟通或没有正确地完成他们的工作。也许，试图给您的管理层留下深刻印象或默许他们正在使用一种称为敏捷编程的行业时尚，这可能是没有意义的。或者管理层需要聘请架构师和 Scrum Master，他们能够根据团队的技能以及客户的期望和项目的技术限制来设计和细化项目。

我认为有些管理人员和他们的 scrum 主管没有意识到一个优秀的架构师对于一个 scrum 环境来说是多么重要，并且拒绝雇用一个。一位能够倾听并与团队合作的优秀架构师对于 Scrumming 过程非常宝贵，因为他/她必须不断调整架构以适应不断变化的粒度和期望。

我还认为有一些管理元素和他们的 scrum master 属于编程领域的另一个领域，因为他们在像瀑布这样较长的开发周期中遇到了不好的经验，因此他们认为 scrum 意味着在一个月内生产出一个产品，并且因此，对跨模块效应的细致调查并不是真正必要的。他们坐下来，在空中弄湿手指，然后想出了一个很棒的冲刺。

如果您的团队经常遇到代码冻结问题，那么你们可能需要对整个项目进行代码冻结并重新考虑您的策略，并查看原因是由于您拒绝定义适合模块粒度的模块合同。或者你们是否完全定义了模块合同，以便当前可以精简卡住模块的功能，以使其他团队或模块能够继续。

你们是否有一个 UML 策略来帮助发现项目发布的预计功能并允许您查看搁置模块的影响，然后查看需要关注哪个模块才能达到所需的产品发布级别？您是否参加了 Scrums 和 sprint，并且没有 UML 的图片来显示您的先进或延迟程度，以至于您只是愉快地或盲目地颠簸自己？或者您的 Scrum 主管是否会对房间说“是”或“否”，嗯……那个模块似乎很重要——实际上并没有清楚地了解哪些是与产品发布相关的最容易被搁置的模块。

产品发布代码冻结是通过逐步冻结模块来实现的。一旦一个模块完成，就会进行产品测试以确保该模块满足其合同，并且该模块被代码冻结为 2.1 版。尽管 2.2 的该模块的工作取得了进展，但整个项目不应依赖于 2.2，而应依赖于 2.1。该策略是在测试产品版本以及产品版本是否应该缩减其功能时，尽量减少需要解冻合同的模块数量。如果渐进式模块化冻结对您的开发团队没有帮助......要么产品非常复杂，而您的管理层对实现正确发布的迭代次数预期不足，要么模块化架构和策略需要认真重新考虑。

【讨论】：

【解决方案5】：

我参与了一个项目（瀑布），其中我们有功能冻结和代码冻结。

功能冻结意味着错误修复期的开始。还为新版本创建了新分支，以便我们可以实现功能，即这是公司开始开发新版本的时间点。没有实现新功能，只修复了错误。

当 QA 认为产品处于可发布状态（即他们不知道有任何严重错误）时，就会出现代码冻结。在最终测试周期之前，会宣布代码冻结（请记住，测试周期可能需要一周时间）。如果测试成功，这将成为发布的产品。如果失败，则修复新的错误。这些签到由架构师和管理人员监督，每条线路的风险都被记录在案。然后再次开始测试循环。

总结：功能冻结后，您只能检查错误修正。代码冻结后，您只能在特殊情况下签入。

【讨论】：

【解决方案6】：

是的，这是多虑了。是的，用词不当。

如果代码没有损坏/混乱，您就不会碰它，如果是，那么您将修复它。这与您没有处于代码冻结状态完全相同。是的，它是反模式的“需求冻结”或“集成中断”。这是停止在下一个版本中包含新功能的点，这在销售/营销/客户支持方面很有价值。但他们可能应该称之为“预发布”。

应该发生的是，在版本控制中总是有几个可发布的系统版本，公司会选择一个来发布。

“代码冻结”的精益名称是“浪费”。

【讨论】：

"是的，我修复了缓冲区溢出问题，所以我们可以发货了。顺便说一句，我还彻底改变了 UI，我希望 QA 不介意重复所有的可用性测试. 测试是自动和即时的，对，因为我们有一个敏捷的开发过程”;-)

【解决方案7】：

在您的评论中，您提到了“冲刺”这个词。这告诉我你可能正在使用 Scrum（或任何其他敏捷）方法。在 Scrum 中，您几乎不会“冻结”任何东西 :) 灵活性、风险识别和缓解，最重要的是，就工程而言，持续集成在 Scrum 中非常重要。

鉴于此，团队应该是跨职能的，并且代码将不断集成。结果，您可能没有“代码冻结”之类的东西。在 sprint 结束时，你只有一个可发布的产品。它应该已经过持续测试，并且您应该已经收到了应该已经修复的错误报告。

嗯，这是理论。然而，好的 Scrum 团队离理论并不远，因为 Scrum 主要是关于原则的。没有太多的规则。

我个人不会在术语上分裂太多头发，而是在术语背后的意图。最肯定的是，该术语用于在您的组织中标识 SDLC 中的一个阶段。按照 Scrum 严格来说，它没有错误修复阶段。如果您将一个或多个 sprint 用于修复错误，那么这个术语可能意味着“没有功能积压将包含在 sprint 中，而只有错误修复”。这可以在 sprint 计划（和预计划）会议上轻松处理，团队甚至不必担心术语。更好的是，这个术语/意图甚至不必超出产品负责人的范围。

【讨论】：

【解决方案8】：

虽然“代码冻结”可能有一个模糊的含义，并且如前所述，在考虑单个项目/版本时更恰当地是“功能冻结”，但它确实在另一个实体负责的更大的集成部署中占有一席之地用于打包和/或部署来自不同团队的多个软件版本。 “代码冻结”让他们有时间确保环境排列整齐并考虑所有包。 “代码冻结”还意味着除了“显示停止”更改之外没有其他内容。其他所有内容都将在下一个维护版本中处理。

在一个完美的世界中，脚本测试会在此之前完成，并且会有时间部署任何最后的修复和重新测试。我还没有看到任何“全球公司”发生这种情况。（业务）测试人员在部署之前甚至之后进行测试，“代码冻结”成为他们加紧努力并记录他们一直坐在的所有内容的信号。在某些情况下，这是他们开始测试的信号。

真的，“代码冻结”只是“这里有 Tygers”的商业代言。 ;-)

【讨论】：

【解决方案9】：

当我们冻结代码时，repo 被锁定，希望所有您想要修复的错误都已修复，并且测试人员可以在分支和构建到生产之前进行另一轮测试。如果本次迭代有任何未解决的错误，那么潜在客户将在你的脖子上喘不过气来，直到它被关闭，或者被认为是非关键的并推迟迭代。所以，是的，它真的被冻结了。

【讨论】：

我有点失望，我总是在“冻结时间”标记冻结点，然后继续其他工作，将其签入其他分支的 repo，以后可以合并。锁定回购听起来是一个很好的借口，可以在下午剩下的时间里去酒吧；-)