读《人月神话》有感
今天读了《人月神话》中间章节，《人月神话》是软件工程方面的一本经典著作，作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。
我认为，学习编程最困难的地方，是将做事的方式向追求完美的方向调整。事实上，只有实际需要时，才会用到最新的设想，因为所实现的系统已经能满足要求，并体现了回报。实现落后与否的判断应根据其他已有的系统，而不是未实现的概念。因此，我们所面临的挑战和任务是在实际的进度和有效的资源范围内，寻找解决实际问题的切实可行方案。首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。 第二，我们采用的估算技术隐含的假设人和月可以互换，错误地将进度与工作量相互混淆。 第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。 第四，对进度缺少跟踪和监督。第五，当意识进度的偏移时，下意识（以及传统）的反应是增加人力。对于软件任务的进度安排，以下是我使用了很多年的经验法则：1/3计划；1/6编码；1/4软件测试和早期系统测试；1/4系统测试，所有的构件已完成。开发并推行生产率图表、缺陷率图表、估算规则等等，而整个组织最终会从这些数据的共享上获益。向进度落后的项目中增加人手，只会使进度更加落后。项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。经验和实际的表现没有相互联系。实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上机型集成的产品。Mills建议大型项目的每一个部分有一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，有一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。（32）外科医生（他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档）； 副手（它的主要作用是作为设计的思考者、讨论着和评估人员。他需要详细了解所有的代码，研究设计策略的备选方案）； 管理员（他（外科医生）需要一个控制财务、人员、工作地点和办公设备的专业管理人员，该管理员充当与组织中其他管理机构的接口）； 编辑（编辑根据外科医生的草稿或者口述，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护，并监督文档生成的机制）； 两个文秘（管理员和编辑每个人需要一个文秘。管理员的文秘负责项目的写作一直和非产品文件）； 程序职员（他负责维护编程产品库中所有团队的技术记录）； 工具维护人员（他的工作是检查他的外科医生所需要的工具，而不是其他团队的需要。工具维护人员常常要开发一些实用程序、编制具有目录的函数库以及宏库）； 测试人员（外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对整个工作进行测试）； 语言专家（语言专家则寻找一种简洁、有效地使用语言的方法来解决复杂、晦涩或者棘手的问题）。