进度落后时的应对行动
立即停止加人。 项目一旦开始延期，第一个动作不是增加资源，而是重新评估任务分解。问三个问题：哪些任务真的在关键路径上？哪些任务可以并行化？哪些任务可以简化或推迟？
重新估算，但用三点法。 不要只给一个"最可能"的时间估算，而要给出最乐观、最可能、最悲观三个数字。然后用加权公式：(最乐观 + 4×最可能 + 最悲观) ÷ 6。这能帮你更诚实地面对不确定性。
如果必须加人，只在这些条件下进行： 新任务可以完全独立开发，新人有相关经验不需要长期培训，项目至少还有3个月以上周期让新人产生净贡献。同时，指定专人负责新人培训，这个人的其他工作要相应减少。
建立每日构建和集成流程。 延期往往是因为最后阶段的集成工作被严重低估。从项目开始就建立自动化构建，每天都要保证代码能编译运行，即使功能不完整。
团队组织的执行步骤
确定首席程序员。 不是技术最强的人，而是既有技术能力又有整体视野的人。首席程序员的工作是：核心架构设计、关键算法实现、代码审查、技术决策。不是项目管理，不是进度追踪。
配置支持角色。 每个首席程序员需要这些支持：一个副手负责代码实现，一个专职测试员，一个文档编辑，一个工具管理员。支持人员的作用是让首席程序员专注于最核心的工作。
建立清晰的沟通机制。 每周一次架构讨论会，每天一次进度同步，每月一次代码审查。沟通内容有固定格式：这周完成了什么，遇到了什么阻塞，下周计划做什么。避免开放式讨论会。
需求管理的具体动作
冻结核心需求。 项目开始后的前三分之一时间内，核心功能需求不能变更。可以调整实现方式，但不能改变功能边界。所有变更请求都要走正式流程：影响评估、时间成本、替代方案。
建立需求优先级矩阵。 把所有功能按照"用户价值"和"实现复杂度"分为四象限。优先做高价值低复杂度的功能，推迟低价值高复杂度的功能。这个矩阵每个月更新一次。
设立功能削减触发点。 提前定义什么情况下开始削减功能：进度延期超过20%，核心功能测试通过率低于80%，团队加班超过连续4周。触发后立即砍掉低优先级功能，专注核心功能。
代码质量控制行动
实施强制代码审查。 所有代码提交前必须有另一个人审查。审查标准：逻辑正确性、命名规范、注释完整性、测试覆盖。审查不通过的代码不能进入主分支。
建立编码标准文档。 不是详细的格式规范，而是设计原则：函数长度不超过50行，类的职责要单一，公共接口要有完整注释。标准要简洁明确，能自动化检查的就自动化。
定期重构会议。 每月一次，团队坐在一起识别代码中的问题区域：重复代码、复杂函数、不清晰的命名。不是立即重构，而是列出清单，在正常开发中逐步改进。
测试策略的执行框架
分层测试，从小到大。 单元测试覆盖核心算法，集成测试覆盖模块接口，系统测试覆盖用户场景。每一层都要有明确的通过标准，下层不通过就不进入上层。
建立测试数据管理。 准备三套测试数据：正常场景、边界条件、异常输入。每次修改代码后，这三套数据都要跑一遍。测试数据要版本化管理，就像代码一样。
设立发布准则。 明确什么条件下可以发布：核心功能测试100%通过，性能测试满足指标，文档更新完成，回归测试无新问题。不满足条件就延期发布，不降低标准。
这些行动指南的核心是：用明确的标准和流程来替代临场判断，用结构化的方法来应对复杂性。布鲁克斯最大的贡献不是告诉我们软件开发很难，而是告诉我们如何系统性地应对这种困难。