我在一个神秘的人月里读到，整合需要花费3倍于开发单个组件的时间。
你们有什么经历？
答案 0 :(得分：6)
是和否。集成努力可能仍然是3倍，但现在它在整个开发过程中分摊（例如早期集成，集成测试（特别是TDD）等）。
我们仍然需要做这项工作，但它不会让我们感到意外。
答案 1 :(得分：5)
这指的是他们分别构建所有软件组件然后尝试将它们放在一起的糟糕的旧时代。聪明的人不再那样了 - 他们integrate continuously。
答案 2 :(得分：1)
我同意，如果不是更高。虽然它真的取决于集成接触点。
我参与了一个项目，在Siebel和SAP之间集成了许多模块。虽然这两种产品都有可用的集成模块，但项目中的所有问题（以及很多）都涉及到集成。
我们使用的大部分SAP都是德语，并且传输的邮件采用不同的XML编码格式（UTF8 / UTF16），这没有帮助。
一旦我们掌握了SAP希望发送和接收的复杂信息，整个项目就会更快地进行。
成功整合项目的关键事项：
项目管理位非常重要，因为它们提供比萨饼，并且当您一直工作30个小时以从一台机器上的一个文本框中获取帐户名称以显示在另一台机器上的另一个文本框中时，确实表现出一些理解。
我们的项目持续了一年多。我们做的Siebel配置的其余部分，很多只是几个月，
So Integration - 10个月+，其余的配置2个月。
答案 3 :(得分：0)
整合时间取决于几个因素：项目规模，团队之间的沟通以及整合理念。
小型项目整合时间较短。大型，超大型或大型项目将需要更多时间进行集成。我一直在进行集成很少的小项目。我参与了跨多个组件团队的大型项目，其中集成需要很长时间。
整合时间还取决于您在团队之间进行沟通的程度。如果您的团队没有进行通信，则可能需要3倍或更多的时间来集成并解决所有相关的错误。
持续集成有助于认识到集成花费的时间更少。通过CI，整合的时间在项目的整个生命周期内摊销。但是，如果你与其他组件团队的关系很差，那么所有集成的总时间将会非零时间。
CI绝对比替代品更好。等到开发周期的后期才能整合，必然会给你带来很大的痛苦。越早开始集成，每个团队就越熟悉这个过程。答案 4 :(得分：0)
有点附注，Juval Lowey就此发表了有趣的演讲。如果您有许多微小的组件，那么您可以增加集成的工作量。如果您只有几个大型组件，则可以减少集成，但是需要维护更复杂的组件。因此，您的集成工作取决于体系结构以及它在何处平衡组件数量与其复杂性。良好的平衡是关键，因为如果你偏向一边或另一边，所需的努力会呈指数增长。如果你有20个组件并添加21，那么它不仅仅是5％（1/20）更复杂，因为你必须考虑潜在的其他20个组件的交互。因此，添加一个组件可以增加20种与现有组件交互的方式。当然，一个好的设计会将这种交互限制在尽可能少的组件上，但这基本上就是为什么Juval觉得它是指数级的。
答案 5 :(得分：0)
Neil和Markus的回答很明显。在Windows中，我们不断整合。我们的源代码控制系统（我们称之为“Source Depot”）是分层的，其中“WinMAIN”位于顶部，并且其下方的分支树通常对应于组织结构。
通常，更改会在“正向集成”和“反向集成”过程中在此树中上下流动。这种情况经常发生 - 几乎每天都在winmain下的顶级分支，而对于较低级别的分支则少一些。每个主要分支至少以四种方式完全构建每天。顶级分支以六种口味构建。味道类似于x86 / fre或x64 / chk。我们还获得了一些每日伪本地化版本。
“build”我的意思是从源代码构建一个完全可安装的Windows客户端产品。这种情况每天发生几百次。
这对我们很有用 - 这里有两个重要的目标：
马库斯非常正确，这可以在项目的整个生命周期内摊销整合成本。对我们而言，如果我们将成本推迟到周期结束时，这会使成本低于它们的成本。这就是过去的工作方式。不要吹太多脏衣服，但是当我在大约5年半前开始使用Windows时，需要花费非常长的时间。它们现在每天都在发生，就像钟表工作一样。 Windows工程工具和发布组（WETR）获得了所有的功劳。
正如许多其他人在各种论坛中所建议的那样 - 定期集成和完整的每日自动构建对大多数项目都是必不可少的
请注意，每日和定期自动化测试是另一个主题（这是您可以想象的巨大努力）。
答案 6 :(得分：0)
如果您在项目计划的最后阶段有一个集成阶段，那么您注定要失败，而x3也不会太糟糕。
你应该选择持续集成，你可以每2周发布一个版本，然后再进行一些集成。