《人月神话》读书笔记

        中国科学技术大学软件学院   杨洋  原创作品版权所有转载请注明出处

       

         读《人月神话》这本书，让我第一次从软件项目管理者的角度去思考软件开发过程中遇到的一些问题。虽然文中提到的部分观点自己没有切身体会，但是能够从整体上获得对软件项目有一个重新的认识。软件开发的过程是一个有趣且复杂的过程，从设计到软件的实现，经历了计划，变化，再计划，再变化等循环迭代的过程，就像在写代码时修复bug,引入新bug,修复新bug,再引入bug的过程。如果有一个环节处理不恰当，可能会使问题越来越难以解决或在某个地方偏离主题，甚至导致整个软件项目的延期或失败。本文探讨“人月神话”，产品概念完整性，项目成员之间的交流和协作等软件项目管理的问题。

        

        本书作者作为一个经验丰富的软件项目管理者提供给我们很多发人深省的观点。先从书名“人月神话”开始探讨，人月即早期用来度量软件开发工作量的一个单位。具体为将每个人每月的工作量作为一个基本单位。用人月的量来衡量整个项目的规模与工作量。并且早期认为人月的模式简单符合线性关系。即：10人*月的项目等价于5人*2月等价于1人*10月。但是这种看似简单完美的模型却是一个美丽的神话,人员和时间是不能简单替代的。

        软件项目的进展并不能用简单的线性关系抽象。软件开发不是一项简单重复的体力劳动。设想如果一个人要扫雪，假设他一个人需要一个小时扫完，但是如果他再找来5个人一起扫，可能只需要十分钟。软件开发比这要复杂的多；如果一个人用十天能做完的一个项目，他做到第五天后想找人来一起做，这就不是找五个人一天就能做完的事情。也许完成项目花费的时间比十天还要多。他要花时间为新加入的队员介绍项目，为他们合理分工，如果有一人没按时完成，所有人都要停下等待……由此引出一系列不可预估的问题。复杂度大大提高。总之：从项目的人数和时间两个维度考虑，都不能以人月作为软件开发度量：1.人数的增加对软件开发的贡献不是线性增长的（队友之间有协作交流的问题）。2.每个人在项目开发中的工作量也不是线性递增的（开发的过程中复杂度提高）。他们可能会是log（o）或更复杂的情况。总之，在软件开发中，合理评估参与人数和时间是一项很有挑战并且需要经验性的工作。同时，应该尽量减少或避免人员的改动。

         此外，文中一个核心的观点就是保持软件产品的概念完整性，概念完整性是产品质量的核心。“一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作的各种参数的用户界面使用策略。”对于大型的软件产品，较好的实现概念完整性并不是一件简单的事情。

        大型编程项目参与的人数较多，不同人对项目的理解很难达成一致。甚至对于同一件事，一个人在不同时间往往也会有不同的理解。因此产品的整体架构必须在极少设计架构师在经过深思熟虑后达成一致的理解的情况下完成，所有人在同一个框架下完成产品。精巧缜密的设计能在开发中减少工作量和复杂性。从学生的体会来讲，往往实践课程都是3~5个人的小组完成，就几个人之间对一个较复杂项目的理解都会存在偏差，更无法想象一个十百千人的项目在开发上会遇到多大的困难。

        作者也从程序员的角度给出一些精准有趣的总结：

        1. “所有编程人员都是乐观主义”，这点深有体会，程序员对自己都比较自信，大家都相信自己的程序这次肯定会运行。这样往往在工作时间的估计上出现偏差。计划好一个下午写好的代码可能会因为程序员自己认为的“最后一个bug”花费一个晚上的时间去修改。由此晚上的计划只能推迟到明天，系统编程进度安排背后的一个假设是：一切会运行良好，每一项任务仅花费它所应该花费的时间。这样的进度安排存在很大的问题。

        2.书中提到：在编程队伍中，“最好的和最差的程序员在生产率上有10倍的差距”，虽然“平庸的”程序员很不愿接受这样的事实，但是事实不能改变，优秀的程序员不是几日功夫就能练就的。软件开发中的个人英雄还是存在的。我们需要思考如何在承认事实的基础上提高团队的效率。虽然最完美的团队是由最优秀的程序员组成的小型的精英团队。但是并不是所有公司能达到的要求，同时对于短期较大工作量的项目并不适用。个人认为，提高团队的工作效率应该把重心放在如何提高交流和协作的效率以及如何使最差的程序员对项目的影响降到最低。

        团队内部的合作与交流是软件开发中很重要的事。架构师和具体负责某模块编码员工的交流，模块内部成员的交流都需要彻底高效。本书中也讲到交流的重要性和交流方式。此处结合自身讨论：去年在A公司实习，A为小型创业公司，有十人左右的精英团队，整体架构由一人负责，同时协调下面所有模块的工作进度。公司每日有站立会议，同时每周有总结性的周会。个人认为，该公司有很高的工作效率，是较有代表性的软件开发的管理范例。但是随着规模的扩大，管理难度也会增加。

        另一个比较案例是学校的实践，如果没有有效的组织者，3~5人的小团队有时都很难在互相交流。大家对事情的理解参差，更难以协同工作。有时是三个和尚没水喝的困境，更多的时候，项目是组内执行力较好的同学按自己的想法完成，其他人协助（这样也就分化出大牛和平庸的程序员）。

        我自己的理解，从菜鸟成长为IT精英的过程是逐渐学会用计算机的思维转化问题的过程。人通过计算机解决问题是把人对此问题的解决方式转化成计算机的思维方式，然后用程序语言实现。程序员做了人与计算机的桥梁。人脑和“电脑”有很分明的特点。人脑能进行更复杂高级的思维，但是“内存”和“速度”有限。而“电脑”只能进行很简单的几种逻辑思维，但是有很大的存储和速度。比如计算一个斐波那契数列：它是一个有规律的计算，“电脑”只需要一个循环和一个开始结束点，就可以计算出来，而人脑只能一步一步计算，虽然是一个重复的过程，但是不能一次算出来（电脑虽然也是一步一步算，但是是机器完成，我们不需要关注过程）。再举一个例子：两张类似的照片，人脑很快能判断出相同和不同，但是对于电脑这是一项复杂而且困难的工作。虽然现在人工智能的发展使得计算机也越来越智能，但是人还是要从计算机的角度去思考处理问题的方式。

        管理是一门艺术，软件开发的管理是科学的艺术。作为一个还未真正涉足实际项目的学习者，对软件开发管理的理解只是皮毛，只有随着不断的学习和经历，才能对这些有更深入的理解。

        欢迎点赞，谢谢~