估计集成时间，真的是 3 倍吗？ [关闭]答案

【问题标题】：Estimating Integration times, is it really 3x? [closed]估计集成时间，真的是 3 倍吗？ [关闭]
【发布时间】：2010-10-17 09:17:42
【问题描述】：

我在一个神话般的人月中读到，集成所需的时间是开发单个组件所需时间的 3 倍。

你们经历了什么？

【问题讨论】：

标签： integration estimation

【解决方案1】：

是和不是。集成工作量可能仍然是 3 倍，但现在它已分摊到整个开发过程（例如早期集成、集成测试（尤其是 TDD 中）等）

我们仍然需要完成这项工作，但它不再让我们感到意外。

【讨论】：

"是且知道" = "是且否"？
第二次或第三次，而不是第十次或第十一次，我们更有可能做到这一点。
假设解决问题的成本随着编写有问题的代码的距离而增加，我认为 CI 通过更早地发现问题来降低集成成本（时间和精力）。
感谢您的 s/know/no/catch & fix。需要更多的咖啡。我认为早期检测的节省会因幸运休息和后期游戏功能分类的损失而有所减少。我们生成了更好的代码，进度延误更少，但投入的工作量似乎大致相同。

【解决方案2】：

这指的是过去的糟糕日子，他们分别构建所有软件组件，然后尝试将它们全部组合在一起。聪明人不再那样工作了——他们integrate continuously。

【讨论】：

然后是我的公司，它根本没有考虑集成，并希望产品在编写组件的那一刻就可以工作......

【解决方案3】：

我会同意，如果不是更高的话。虽然它确实取决于集成接触点。

我参与了一个在 Siebel 和 SAP 之间集成多个模块的项目。虽然这两种产品都有可用的集成模块，但项目中的所有问题（并且有很多问题）都涉及到集成。

我们使用的大部分 SAP 都是德语，并且传输的消息采用不同的 XML 编码格式 (UTF8 / UTF16)，这无济于事。

一旦我们掌握了 SAP 想要发送和接收的复杂信息，整个项目的进展就会更快。

成功集成项目的关键：

关于集成模块的良好文档（英文！）
关于消息格式的良好文档
良好的项目管理

项目管理位很重要，因为他们提供比萨饼，并且当您连续工作 30 小时从一台机器上的一个文本框中获取帐户名称以显示在另一台机器上的另一个文本框中时，确实表现出一些理解。

我们的项目持续了一年多。我们所做的 Siebel 的其余配置，很多，只是几个月，

所以集成 - 10 个月+，其余配置 2 个月。

【讨论】：

【解决方案4】：

集成时间取决于几个因素：项目规模、团队之间的沟通以及您的集成理念。

小项目需要更少的时间来集成。大型、超大型或大型项目将需要更多时间来集成。我一直在进行集成最少的小型项目。我参与过跨越多个组件团队的大型项目，其中集成需要很长时间。

整合的时间还取决于您在项目间跨团队沟通的能力。如果您的团队没有进行沟通，则可能需要 3 倍或更多的时间来整合和解决所有相关的错误。

持续集成有助于理解集成所需时间更少。使用 CI，集成的时间在项目的整个生命周期中分摊。但是，如果您与其他组件团队的关系不佳，那么所有集成的总时间将花费非零时间。

CI 绝对比替代方案更好。等到开发周期的后期才进行集成势必会给您带来很大的痛苦。越早开始集成，每个团队就越能适应这个过程。

【讨论】：

【解决方案5】：

顺便说一句，Juval Lowey 对此进行了一次有趣的谈话。如果您有许多微小的组件，那么您会增加集成的工作量。如果您只有几个大型组件，则会减少集成，但您需要维护更复杂的组件。因此，您的集成工作取决于架构以及在何处平衡组件数量与复杂性。良好的平衡是关键，因为如果你向一侧或另一侧漂移，所需的努力会成倍增加。如果您有 20 个组件并添加第 21 个组件，那么它不仅会复杂 5% (1/20)，因为您必须考虑潜在的其他 20 个组件的相互作用。因此，添加一个组件会增加 20 种与现有组件交互的方式。当然，好的设计会将这种交互限制在尽可能少的组件中，但这基本上就是 Juval 认为它是指数级的原因。

【讨论】：

【解决方案6】：

Neil 和 Markus 的回答很到位。在 Windows 中，我们不断集成。我们的源代码控制系统（我们称之为“Source Depot”）是分层的，“WinMAIN”位于顶部，其下方的分支树通常对应于组织结构。

通常，更改在“正向集成”和“反向集成”的过程中上下流动。这种情况经常发生 - winmain 下的顶级分支几乎每天都发生，而较低级别的分支则较少发生。每个主要分支每天都以至少四种风格完全构建。顶级分支有六种风格。风味类似于 x86/fre 或 x64/chk。我们还获得了一些日常的伪本地化构建。

“构建”是指从源代码构建完全可安装的 Windows 客户端产品。这种情况每天发生数百次。

这对我们很有效 - 这里有两个重要目标：

在树上下保持良好的代码流（我们称之为速度）。这个想法是任何分支都与 WinMAIN 没有太大的不同。
尽早发现集成错误。

Markus 非常正确，它在项目生命周期内分摊了集成成本。对我们来说，这使得成本比我们将成本更多地推迟到周期结束时的成本低很多。这就是过去的工作方式。不要放太多脏衣服，但是当我大约 5 1/2 年前开始使用 Windows 时，进行构建需要非常非常长的时间。它们现在每天都在发生，就像时钟工作一样。 Windows 工程工具和发布组 (WETR) 对此赞不绝口。

正如许多其他人在各种论坛中所建议的那样 - 定期集成和每日全自动构建对于大多数项目来说都是必不可少的。

请注意，日常和定期自动化测试完全是另一个主题（您可以想象这是一项巨大的努力）。

【讨论】：

【解决方案7】：

如果您在项目计划的项目结束时有一个集成阶段，那么您注定要失败，x3 也不错。

您应该选择持续集成，例如每 2 周发布一个包含一些集成的版本。

【讨论】：