IT项目管理——《人月神话》读后感
这也许是和候红老师的最后的几节课了吧，侯老师是一个很有思想深度，很关心同学的好老师。
一开学就布置了阅读《人月神话》的作业，说实话，我没有看，以我的速度可能2、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.使用塑料包装的成品软件包作为构建：成熟的模块和对象组合提升了软件复用的层次。
软件工程的未来。作者说“软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑”。