人月神话－整体部分和祸起萧墙

1.整体部分(部分如何高质量的集成为一个整体)

根据英文内容这里最好应该翻译为整体和部分。为了得到整体的可运行和高质量的软件，我们需要在哪些方面进行改进和下功夫。这章主要从消除Bug的设计，构件单元测试和系统集成调试三个方面来谈。

之所以谈消除Bug的设计，就让我们更加意识到质量是设计出来的，而不是测试出来的。V.A.Vyssotsky 提出许许多多的失败完全源于那些产品未精确定义的地方。这要求我们在需求和设计阶段要保持高质量，减少缺陷泄漏。对于需求要有详细的需求规格说明书，对于设计我们提倡的是从顶向下逐步求精的设计，而这里面最重要的就是结构化的设计方法和思路，不论是面向结构和面向对象其实都要遵守结构化的设计方法。在需求规格说明书完成后要尽快提交给测试小组编写测试用例，测试小组需要Review需求以确认需求完整，无歧义和可测试。

在构件单元测试中讲的很多内容暂时无法和我们现在实际软件开发所对应，但是现在的敏捷开发方法论仍然强调测试驱动，先编写单元测试用例再开发代码，足见单元测试在敏捷软件开发中的重要地位，它不仅仅起到了测试的作用，更重要的是通过测试用例的编写喜欢需求和完善设计思路。

对于大型软件系统，产品集成和集成测试具有重要的地位，为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施。其中包括了首先对于单个构建必须经过充分的单元测试，否则单元测试的问题将遗留到集成测试阶段导致问题复杂化；其次是搭建充分的测试平台，测试平台往往需要编写测试代码，特别是还可能开发各种伪构件来验证数据集成的正确性。最后是在集成期间要严格控制变更，最好是阶段化的定期变更。

2.祸起萧墙(进度管理和监控的方法)

慢性的进度偏离是士气杀手，这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付，最重要的就是要防微杜渐。重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。

进取对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。为了加强我们对进度的监控，里程碑的定义就至关重要了。里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。以下是一些反面的例子，例如编码，在代码编写时间达到一半的时候就已经“90％完成”了；调试在大多时候都是“99％完成”的；“计划完毕”是任何人只要愿意，就可以声明的事件。(90%的进度具有很大的欺骗性，这里可以参考我原来翻译的进度游戏相关文章)

里程碑有明显边界和没有歧义，比它容易被老板核实更为重要。如果里程碑定义得非常明确，以致于无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告。毕竟，没有人愿意承受坏消息。这种做法只是为了起到缓和的作用，并没有任何蓄意的欺骗。

在进度跟踪和管理上，必须要在整个团队中树立这种观念，就是要尽可能早的完成相关的任务，而不是拖到了最后在来做。类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。

当进度出现偏差后，项目经理往往把问题掩盖起来，而且经常主观的认为可以通过各种赶进度的手段来挽回进度损失，但是往往情况并不是这么简单。因为很多时候引起进度的偏差往往存在一些问题的根源，而这些根源往往是需要老板提前介入并采取一些行动，因此老板必须仔细区分状态报告、毫无惊慌地接收报告、决不越俎代庖，将能鼓励诚实的汇报。