初读《人月神话》

       在平时的工作中，时常体会到消耗大量时间的往往不是一些难度很高的技术问题，而是一些由于工作流程管理不当及沟通不善造成的时间浪费，比如没有经过深入全面地分析和详细地设计就开始编码，事后常常要花大量的时间返工和修改；比如代码管理混乱，合并代码时常常出现各种小错误，耽误了进度；比如没有撰写清晰完备的文档，后续其他同事在维护之前的代码时，非常费时费力，等等。因此，学习一些项目管理方面的知识非常有必要。抱着这种心态，我翻开了《人月神话》，开始第一次阅读。下面摘录一些本次阅读过程中的一些笔记：

       1、任何创造性活动都伴随着艰苦的劳动，编程也不例外。

       2、关于进度安排，我的经验是1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

       3、Brooks法则：为进度落后的项目增加人手，只会使进度更加落后。

       4、一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了工作量。

       5、“对于非常大型的项目，将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”

       6、纪律、规则对于行业是有益的。外部的体系结构时间上是增强，而不是限制实现小组的创造性。

       7、出于精确性的考虑，我们需要形式化地设计定义；同样，我们需要记叙性定义来加深理解。

       8、团队应该以尽可能多的方式进行相互之间的交流：非正式地进行简要技术陈述的常规项目会议，共享的正式项目工作手册[以及通过电子邮件]。

       9、仅仅通过对编码时间的估计，然后乘以其他部分的相对系数，是无法得出对整项工作的精确估计的。

       10、规模预算必须与分配的功能相关联；在指明模块大小的同时，确切定义模块的功能。

       11、在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。

       12、从系统整体出发以及面向用户的态度是软件编程管理人员最重要的职能。

       13、编程需要技术积累，每个项目需要自己的标准组件库。

       14、战略上的突破常来自于对数据或表的重新表达。数据的表现形式是编程的根本。

       15、对于软件项目，要求的文档有：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。项目经理应该在项目早期对上述的一系列文档进行规范化。

       16、以上集合中每一个文档的准备工作都将注意力集中在思索和对讨论的提炼上，而书写这项活动需要上百次的细小决定。正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。

       17、项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。

       18、用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

       19、软件产品易于掌握的特性和不可见性，导致它的构建人员（特别容易）面临着永恒的需求变更。

       20、高级语言的使用、编译时操作、通过引用的声明整合和自文档技术能减少变更引起的错误。

       21、缺陷修复总是会以20%~50%的几率引入新的bug。

       22、每次修复之后，必须重新运行先前所有的测试用例，确保系统不会以更隐蔽的方式被破坏。

       23、所有的修改都倾向于破坏系统的架构，增加了系统的混乱程度（熵）。即使是最熟练的软件维护工作，也只是延缓了系统退化到不可修复的混乱状态的进程，以致必须要重新进行设计。（许多程序升级的真正需要，如性能等，尤其会冲击它的内部结构边界。原有边界引发的不足常常在日后才出现。）

       24、项目经理应该制定一套策略，并为通用工具的开发分配资源；与此同时，他还必须意识到专业工具的需求。需要安排一名系统程序员，以保证机器上的标准软件是及时更新和实时可用的。

       25、Vyssotsky提出，“许许多多的失败完全源于哪些产品未精确定义的地方。”

       26、Wirth主张，在每个步骤中，都尽可能地使用级别较高的表达方法。

       27、我发现对良好（对交互式调试做出快速反应）系统的正确使用，往往要求每两小时的终端会话对应于两小时的桌面工作：1小时会话后的清理和文档工作；21小时为下一次计划变更和测试。

       28、系统调试仅仅应该在所有部件能够运作之后开始。

       29、系统测试期间，一次添加一个构件。

       30、里程碑必须是具体的、特定的和可度量的事件，能进行清晰的定义。

       31、PERT的准备工作是PERT图使用中最有价值的部分。它包括了整个网状结构的展开、任务之间依赖关系的识别和各个任务链的估计。这些都要求在项目早期进行非常专业的计划。

       32、每个老板同时需要采取行动的异常信息以及用来进行分析和早期预警的状态数据。

       33、老板的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫不惊慌地接收报告、绝不越俎代庖，能够鼓励诚实的汇报。

       34、培训和管理人员基本上没有向编程人员成功地灌输对待文档的积极态度——文档能在整个生命周期对克服懒惰和进度的压力其促进和激励作用。

       35、这样的失败并不都是因为缺乏热情或者说服力，而是没能正确地展示如何有效和经济地编制文档。

       36、每一份发布的程序拷贝应该包括一些测试用例，其中一部分用于校验输入数据，一部分用于边界输入数据，另一部分用于无效的输入数据。

       37、为了使文档易于维护，将它们合并至源程序是至关重要的，而不是作为独立文档进行保存。

       38、最小化文档担负的三个关键思路：

                （1）借助哪些必须存在的语句，如名称和声明等，来附件尽可能多的“文档”信息。

                （2）使用空格和格式来表现从属和嵌套关系，提高程序的可读性。

                （3）以段落注释，特别是模块标题的形式，像程序中插入必要的记叙性文字。