IT项目管理——《人月神话》读后感

这也许是和候红老师的最后的几节课了吧，侯老师是一个颇有思想深度，很关心同窗的好老师。

一开学就布置了阅读《人月神话》的做业，说实话，我没有看，以个人速度可能二、3个小时就看完了，可是我以为没有什么意义，在网上找了一个洗的很好的总结，大概看了看，并加入了一些本身的见解，由于目前才大三，没有什么项目开发经验，因此只能从平时的编程中遇到的问题来看待《人与神话》这本书。

参考：

《人月神话》读书笔记——陈浩要安静（http://www.jianshu.com/p/da8a68354caa）

人月神话读书笔记

　　开头的话：第一次听到《人月神话》是在陈晓江老师的新生导读上，当时对这个专业充满了好奇与期待，因而便立马买了这本书来看，可是当时的我对编程都是一窍不通，更是不能理解这本书的内容了。而现在已步入大三，我再次读了这本书，首先有了必定的编程经验以及小的项目开发经验，其次学习了《软件工程》和《项目管理》，即是对这本书有了初步的理解。不过，我始终相信每次一的读书都会带来新的收获，等我工做了之后再次读这本书的时候确定会有新的感触吧。

　　人是程序员，月是时间，若是1人干10个月若是等同10人干1个月，那就成神话。

　　第一章的标题即是很吸引人“焦油坑”。程序员，就像诗人同样，几乎仅仅工做在单纯的思考中。程序员凭空运用本身的想象，来建造本身的“城堡”。不多有这样的介质——创造的方式如此灵活，如此得益于精炼和重建，如此得容易实现概念上的设想。没错，程序员就像创做者同样，每一次指尖的敲下，即是有一串字符诞生，而这串字符即是蕴含着创做者本身独特的思惟，就如同做家、画家等同样，程序员所作的也是智力创造，不断地推翻之前本身的所想就成为常态。一开始设计上的不完善，再加上后来不断地推翻修改，如果没有在更高的高度上的对总体的把控，就会使得软件架构愈来愈复杂，冗余的内容愈来愈多，还不敢随意删除，这就成为了一个焦油坑，越是挣扎，编越是深陷其中。“Adding mapower to a late software project makes it later.”向进度落后的项目中增长人手，只会使进度更加落后。这是书中提到的Brooks法则，人月神话一文的核心观点。用人月这一观念来衡量项目进度带有欺骗性。由于他使得项目看上去好像人力和时间是可交换的。若是时间不够，那么增长人手就能够加快进度。可是这个衡量方式忽略了新增长人手的培训时间、队员之间的沟通时间等等因素，结果就是，盲目的增长人手只会致使项目落后。因此问题是，如何使得项目进度不落后；要想使得项目进度不落后，就要制定出合理的项目进度。因此，问题是，如何制定出合理的项目进度。

外科手术队伍是指有经验的程序员决定了项目的绝大部份内容，而其余人只完成一些细节的工做，可是这里我认为做者只是从如何高效的完成项目来考虑了，没有从一个公司管理者的角度来考虑。

　　多此一举，我以为这里的翻译有一些奇怪，其实做者是想表达，系统设计师应该足够当心并关注第二个系统，由于第一个系统在设计时是毫无经验的，是一次大胆的尝试，而第二次应该尝试全集与第一次设计的差集，而这种尝试必然是十分危险的。之后的设计中则可参考前两次的设计经验。

为何巴比伦塔会失败？书中列举了一个项目想要成功的一些必要因素。清晰地目标、人力、材料、时间、技术，这些条件所有都达到了要求，可是为何仍是会失败呢？这就像圣经中的巴比伦塔故事同样。当时人类联合起来兴建但愿能通往天堂的高塔，为了阻止人类的计划，上帝让人类说不一样的语言，令人类相互之间不能沟通，计划所以失败，人类自此各散东西。因此他们还缺少什么？那就是交流和组织。他们没法相互交谈，从而没法合做。当合做没法进行时，工做陷入了停顿。经过史书的字里行间，咱们推测交流的缺少致使了争辩、沮丧和群体猜忌。很快，部落开始分裂——你们选择了孤立，而不是互相争吵。

　　成竹在胸。这章讨论一个程序员的生产效率究竟有多高？书中说“对规模平均为3200指令的程序...大约单个的程序员所须要的编码和调试时间为178个小时，由此能够外推获得每一年35800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的四分之一，相应推断出的生产率几乎是每一年80,000代码行1。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。所以，上述小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类能够在3分钟以内跑完1英里的结论同样。”工做量和代码行数不是线性关系，而是指数型关系：工做量 ＝ （常数）×（指令的数量）^1.5。

　　祸起萧墙。项目是怎样被延迟的？就像高中英语老师所说的，你天天比别人早来20min，早点来读读单词、背背课文；每次课间多作两三道单选；天天晚上作一道阅读理解，那么你半年比别人进步多少？虽然当时以为颇有道理，但一直也没这样作......反向分析一下项目进度也是极其类似的，由于种种事情而推迟的计划在最后累积到一块儿，致使整个项目延期到不可思议的地步。虽然咱们都很不想让进度落后，可是一天一天的进度落后是难以识别的、不容易防范和难以弥补的。某个关键人员生病了、公司停电、下暴雪、紧急任务、私人问题——这个列表能够无限被扩展，每件事都会使项目延期半天、一天，虽然都是小的时间碎片，可是整个项目进度开始落后了，尽管每次都只有一点点。

　　另一面。这一章主要阐述了文档在项目开发中起到的做用是多么重要。可是什么样的文档才是好的文档呢？文中给出了一些参考内容：1. 目的。主要的功能是什么？开发程序的缘由是什么？2. 环境。程序运行在什么样的机器、硬件配置和操做系统上？3.范围。输入的有效范围是什么？容许显示的合法范围是什么？4.实现功能和使用的算法。精确地阐述它作了什么。5.输入——输入格式。必须是确切和完整的。6.操做指令。包括控制台及输出内容中正常和异常结束的行为。7.选项。用户的功能选项有哪些？如何在选项之间进行挑选？8.运行时间。在指定的配置下，解决特定规模问题所须要的时间？9.精度和校验。指望结果的精确程度？如何进行精度的检测？

　　没有银弹。There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.Fred Brooks提出的注明论断。在民俗传说里，全部能让咱们充满梦靥的怪物之中，没有比狼人更可怕的了，由于它们会忽然地从通常人变身为恐怖的怪兽，所以人们尝试着查找可以奇迹似地将狼人一枪毙命的银弹。咱们熟悉的软件专案也有相似的特质（以一个不懂技术的管理者角度来看），日常看似单纯而率直，但极可能一转眼就变成一只时程延误、预算超支、产品充满瑕疵的怪兽，因此，咱们听到了绝望的呼唤，渴望有一种银弹，可以有效下降软件开发的成本，就跟电脑硬件成本能快速降低同样。第一次看到这个标题的时候，感受很奇怪查了一下才明白其中的寓意。好比面向对象编程，只能解决一些非本质的困难，对于软件工程的根本问题无事于补，即复杂性、一致性、可变性、不可见性、遗留问题。所以，如今的技术中最有但愿的，而且解决了软件的根本而非次要问题的技术，是开发做为迭代需求过程的一部分——快速原型化系统的方法和工具。快速原型之因此能够解决根本问题，是由于快速原型有助于澄清软件工程的概念结构，从而下降了后期变动的幅度。基于快速原型进行增量开发，目前已经成为实际开发的标准流程。我以为这是做者首次明确地作出确定。

　　软件重用。做者提出“重用是一件提及来容易，作起来难的事情。它同时须要良好的设计和文档。即便咱们看到了并不十分常见的优秀设计，但若是没有好的文档，咱们也不会看到能重用的构件”。这一点我算是体会深入，在Python中模块（包）的概念可谓深刻人心从，一开始接触的Django，Web.py，到requests，bs4，unittest，coverage，以及他们的管理工具pip等等还有不少。这些优秀的模块抛开它们自己优秀的设计思路，以及强大的功能。你会发现这些优秀的模块都有一个共同点——文档写得十分优秀。好的文档能极大的提升开发效率，例如Django的官方文档，体系十分庞大，并且对于每一个版本都有对应的文档，每次更新的内容也会在首页展现，只不过纯英文看的我有点头痛，由于不少术语即便翻译了也感受怪怪的，大部分都是专业词汇。再说一个依赖模块而诞生的强大工具Atom，这个是github推出的一款编辑器，他的强大之处在于它的可扩展性，比较知名的有elemet，minimap等等，这些下载量惊人的扩展或是主题抛去自己十分好用不谈即便没有像Django的官网，去看他们的gihub的README，写的十分清楚，什么快捷键，快速入门，写的明明白白，由于atom的开发者是良莠不齐，不想pypi那种有严格的审核，致使一些明明十分好用的扩展和主题，由于烂的一比的文档（这里我不得不说一些很粗俗的话，我当时下载了一个主题的扩展包，可使用透明的自定义背景，十分好看，可是我怎么都不知道在哪里改，甚至去他的源码里替换了一些我也不知道是什么的.jpg文件，弄了有两天，都没有弄好，后来在特别偏僻的论坛里发现了一条，有一个快捷键‘ctrl+shift+e’这你不说谁能想到啊，真的很生气）致使根本没人用，甚至被骂。因此在软件重用这里，顺便说一下文档的重要性。

　　20年后的人月神话。做者说“今天，我比以往更加确信。概念完整性是产品质量的核心。拥有一位结构式是迈向概念完整性的最重要一步。这个原理不只限于软件系统，它适用于全部的复琐事物” 20年后的人月神话有些结论获得验证，有些状况已经变化，下面是这些状况的简单归纳：1.第二系统定律获得验证：开发第二个系统老是由于盲目的功能致使易用性、甚至是可用性的灾难。图形界面的成功2.瀑布模型被证实是错的了，由于没有构建舍弃原型。事实上增量开发与快速迭代才是理想的开发方式。3.增量开发和快速原型，渐进地精华，让软件像生物进化那样逐渐演化成更为复杂的结构，演化出更多的功能。4.信息隐藏：Parnas是正确的，我是错误的。20年前关于信息隐藏的两大观念，其一是Brooks主张的，全部的程序员应该了解全部的材料。而Parnas则认为代码模块应该采用定义良好的接口来封装，这些模块内部结构应该是程序员的私有财产。Brooks认可，Parnas所主张的方案确实更符合实际。5.对人月神话实际研究发现，向进度落后的项目中添加人手会增长项目的成本，可是不必定会使项目更加落后。若是在项目早期添加额外的人比在后期添加额外的人更安全些。6.人就是一切。这一点能够从《人件：高生产率的项目和团队》能够见出。7.放弃权利的力量——公司经过将权利下放到具体的团队，事实上使得组织机构变得更加“融洽和繁荣”。8.最使人惊讶的新事物——数百万的计算机。9.使用塑料包装的成品软件包做为构建：成熟的模块和对象组合提高了软件复用的层次。

　　软件工程的将来。做者说“软件工程的焦油坑在未来很长一段时间内会继续地令人们举步维艰，没法自拔。软件系统多是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业须要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及可以使咱们认识到本身不足和容易犯错的——上帝所赐予的谦卑”。