第27章：程序规模对“构建”的影响

为什么需要这一机制

两支同样熟练的队伍，人数和交接面不同，往往会得到完全不同的交付节奏。小队可以在桌边同步决定；人数增加后，等待、解释、集成和返工会挤占真正写代码的时间。如果仍把“大项目”当成“小项目乘以一个倍数”，计划会在最需要反馈的地方失真。

本章把规模当成一组可观察的条件：人数改变协作关系，边界改变证据责任，活动配额改变反馈速度。读者不需要记住一个神奇阈值，而要能先提出预测，再只改变一个条件，最后用同一输入复位重放。

核心合同

本节的符号表只有两个量：n 是需要直接协作的参与者数量，C 是潜在协作关系数量。

这个式子在说：每一对参与者都可能产生一条需要共享上下文的关系，所以协作关系的增加速度高于人数本身。

公式不是工期预测器。它只提醒我们：人数增长会先扩大同步表面积；实际工期还要结合模块边界、工具、专业分工和反馈周期。实验中的每个结论都必须固定版本、输入、单位和观察窗口，不能为了让结果好看而改阈值。

目录节点到四级证据

下面每个官方目录节点都回答四个问题：它改变了哪个工程变量？为什么该变量随规模变化？专属实验能看见什么？读者怎样用练习复核结论？

第27章 程序规模对“构建”的影响

本章总论点不是“规模越大越慢”，而是规模会改变约束组合。人数、交接边界、缺陷反馈和活动配额同时变化时，原先适合小范围协作的做法就需要重新分配责任与证据。判断方法是否合适，必须看它是否能在新边界内维持反馈和集成。

验证时先把团队人数设为 4，再逐步调高；记录沟通关系的理论值、直接构建所占比例和交付证据的缺口。若只看到代码行数增加，却没有记录协作边和复位后的轨迹，说明测到的是数量，不是规模对构建的影响。

27.1 交流和规模

这里的核心是 沟通网络：它不是聊天工具的消息数，而是需要保持共同理解的关系数。四个人有 6 条潜在关系；人数增加到 8 人时，关系数变为 28 条，因而会议、接口说明和决策同步不能再按人数线性追加。

工程上要做的是减少不必要的边，而不是假装边不存在：清楚的模块接口、稳定的决策记录和合适的责任分组，都能降低每条边的维护成本。网络实验的线性误区开关会把当前人数当作沟通量，便于比较一个看似简单、却系统性低估协调成本的模型。

27.2 项目规模的范围

规模必须先有 规模边界。同一个“10 人项目”可能指一个共享仓库，也可能指跨团队的系统集成；若对象、责任和交付物没有分开，人数和代码量就无法解释实际工作量。

定义边界时至少记录对象、外部依赖、接口所有者、验收人和观察窗口。把边界从“单个可交付程序”切换到“含外部依赖的产品”后，验证活动和证据种类应该增加；若读数只变了标题，说明模型没有真正改变边界。

27.3 项目规模对错误的影响

规模会改变 缺陷分布，但不等于规模越大每个模块都按同一比例出错。更多接口会增加集成缺陷的机会；更清晰的边界和更早的验证，也可能降低某些缺陷的暴露成本。

因此应同时看缺陷数量、首次发现阶段、跨边界比例和返工路径。一个通过本地测试却在集成时失败的样本，说明缺陷可能被推迟，而不是不存在。活动比例实验中的“忽略协调”故障会把验证和集成容量压低，帮助读者看到这种遗漏如何改变错误暴露的位置。

27.4 项目规模对生产率的影响

生产率必须和质量、等待、返工、协调以及可交付成果一起解释。把代码量除以人数，可能得到一个漂亮数字，却没有说明这些代码是否可集成、是否重复劳动，或是否把缺陷推到了更晚的阶段。

规模因子升高时，合理模型会为沟通、验证、集成和管理留出更多容量；线性误区则把大部分时间都留给直接构建。比较两种模型时固定团队能力和验收标准，只改变规模因子，并记录直接构建比例、返工信号与最终证据。

27.5 项目规模对开发活动的影响

这里关注 活动比例，而不是给每种方法排一个永远固定的百分比。项目边界、风险和交接面改变后，编码、审查、测试、集成和管理的相对配额也应重新计算。

读图时先问“哪类风险没有容量承接”，再问“怎样让直接构建更快”。如果为了提高编码占比而删掉集成和验证，短期数字会变好，后续等待和返工却会把成本推迟。活动实验把这种选择变成可操作的对照，而不是凭印象争论。

活动比例和项目规模

活动比例与规模的关系是一个反馈回路：边界越多，协调和验证越不能被当成零成本；反馈越晚，返工越可能跨越更多边界。真正有用的计划会给每项活动写出目标风险、输入、输出和验收信号，而不是只报一个编码百分比。

先预测规模因子从 1 倍变为 5 倍时四类活动如何变化，再打开“忽略沟通与集成”故障。若故障模型看起来更快，却失去边界证据和回归反馈，结论应判为不通过。

程序、产品、系统和系统产品

同一句“完成了”在不同对象上含义不同。程序边界可能只需要局部测试和审查记录；产品边界还需要需求基线、集成构建和验收样本；系统边界则需要跨团队合同、发布窗口和运行证据。系统产品尤其不能用单个程序的通过来代替整体证据。

恢复实验让读者选择程序、产品或系统边界，再注入一次“跳过边界复核”的故障。首个红色节点应出现在验证活动，而不是最后的交付文字；修复后必须用同一对象边界和同一输入重跑，证明证据没有随着边界偷偷改变。

方法论和规模

方法不是按团队人数自动切换的菜单，而是一组与风险、边界和反馈速度相配的决策。小范围任务可以依靠即时沟通；跨团队系统则需要明确接口、异步记录、分层验证和可追溯交付证据。规模变化触发的是方法选择条件变化，不是某个流派必然胜出。

用三个实验交叉检查方法选择：网络图看同步表面积，活动图看容量是否承接风险，恢复图看交付边界是否保持一致。只有三者的输入、状态和输出能互相解释，方法调整才不是事后合理化。

额外资源

额外资源的价值取决于它是否补足当前规模缺口。团队缺接口协商，就优先补边界和决策记录；团队缺集成反馈，就补自动化构建和验收样本；团队缺故障定位，就补缺陷分类与复现记录。链接本身不是资源价值，能否转成下一次实验的输入才是。

选择资源时写出要解决的问题、使用期限和复核产物，并在相同观察窗口重跑一次。这样可以区分“阅读过材料”和“方法真的改变了可观察行为”。

关键点

• 规模增加会改变关系、边界和反馈成本，不只是增加代码数量。
• 生产率必须和质量、返工、协调、集成及可交付成果一起读取。
• 程序、产品与系统产品需要不同的责任范围和验收证据。
• 最可靠的调整是先预测、只改一个直接条件、保存首个偏离，再复位重放。

最小可重放实现

# 第27章：程序规模对“构建”的影响：固定输入后比较正常与故障模型
people = 4
expected_channels = people * (people - 1) / 2
observed_channels = run_network_model(people, linear_model=False)
assert observed_channels == expected_channels
assert reset_and_run(people) == expected_channels

这段伪代码只表达本章的教学合同，不复制原书代码。实际记录应包含输入人数、规模边界、活动模型、故障开关、首次偏离、拒绝理由和复位结果；同一输入无法回到同一读数时，不能把一次通过当作稳定结论。

专属因果实验

猜一猜：把团队人数或规模因子调大会发生什么？先写下沟通关系、直接构建比例和首个失败节点的预测，再操作控件。三步实验分别固定基线、注入单一误区、选择交付边界；每一步都保存读数，最后点击“重置实验”并核对初始状态。

故障诊断与误区

术语与边界

本章的六个操作术语是沟通网络、规模边界、缺陷分布、生产率、活动比例和系统产品。它们分别指向网络图、边界选择、故障读数、活动比例图、恢复路径或状态文本；如果一个词只能指向标题，说明解释和验证仍未完成。

本页小结

• 用 n(n - 1) / 2 识别协作关系的非线性增长，并把它当作风险提示而非工期答案。
• 把规模边界、缺陷分布、生产率和活动比例放进同一条可观察的因果链。
• 依据程序、产品或系统产品的边界匹配方法与证据，并通过故障—修复—复位闭环验收。