第6周读书笔记——读《人月神话》有感

第六周读书笔记——读《人月神话》有感

形象化，这是我翻开这本书的第一感觉。做者花了大力气来想出一些形象的比喻来阐述项目中的一些问题，让不一样资历的读者都能有所收获。一开始书就将软件危机比喻成“焦油坑”。使咱们生动形象地感觉到“软件危机”的恐怖，就像史前巨兽在焦油坑中挣扎的惨状，再一次说明了软件开发的过程绝非坦途，而是坎坷不断。

因为做者的关系，这本书对于一个项目管理人员可能会有更大的收获。即使如此，对于软件开发方面的小白我来讲，仍是有必定借鉴意义的。

人月神话，什么是“人月”？那是一个用来估计工做量单位，大体跟旧时工人出工的“工数”一致。Brooks认为，使用这种方法计量是有失偏颇的，由于1人工做1个月的效率并不等于（实际上远有误差）30我的干一天的效率，只有当一份可分解且各部分不须要交互时才大体相等。而我认为可能不止于此，由于有些想法须要时间的酝酿，有些环节比较依赖于试错（好比说炼丹？）。可是一个较大的软件必然须要一个较短的工期，因此说集体的配合是必不可少的。这时候首先须要保证设计概念的完整性，不管是怎样的软件，最好由同一个团队主导，有一个清晰明确的模型和目的，以后全部人在这样的框架下努力，也就是“一以贯之”。若是有创新、改变，也应该与基本的概念相吻合，实现团体的协力。然而须要注意的是，客户的需求老是瞬息万变的，就连开发软件的团队的思考都有可能隔三差五翻新。所以凭空思考极可能致使无用功，所以一份公共的框架文档是必须的，一旦发现有抵触的地方，就应该防微杜渐，若是用书中的说法，就是“外科手术式”的开发队伍。其实以前我对项目很难有一个具体的规划，可是一旦记录下来以后，就显得比较丰满了。若是再对项目有所改动的话，内心也会不自觉地谨慎起来，不断地提醒本身要当心。这也是项目文档的另外一个做用，让项目正式化，让每一个参与者有一种仪式感。

有了一个好的纲领是成功的一半，但这还不够，还要考虑到团队合做中“人”的问题。团队合做首要问题就是交流，Brooks举了圣经中最伟大的烂尾工程——巴别塔为例子，告诉咱们不能交流的团队终将分崩离析。那么咱们应该如何解决这个问题？我以为如下几点是不错的选择：第一点，须要团队有一个共同的想法（目的），这样的团队在处理问题时可以避免在根本上发生冲突。第二，团队成员之间应该以尽量多的形式进行交流，这看起来就是一句废话，然而实际的项目中，许多人每每为了追求我的的进度而埋头苦干，忽视了交流；或者是呆板的按期交流让人倒胃口，不想开口说话。因此说不管是非正式仍是正式，是简要的技术陈述仍是共享的工做手册，都是可行的交流方式，并且这样能够有效避免人员缺失所带来的严重技术断档。之前和别人和写程序的时候也遇到过这样的问题，各自负责各自的部分，到了整合的时候一旦有一我的缺席，整个组的进度就都停滞了，并且都是对此有心无力。

纵然是大师写的东西，书上的某些东西也有过期之嫌。好比说书中的一些例子，这些例子可能对几十年的读者来讲是很好理解的，可是对于现今的咱们来讲又有些陈旧和难懂了。还有书中提到的“削足适履”一章，主要解决的是存储空间的问题，可是就如今来讲通常规模的软件已经能够忽略掉这样的问题了，不须要像几十年前同样很是拘泥于空间问题。总的来讲仍是获益匪浅，让我从管理层面从新认识了一遍软件开发的过程，之后看问题应当会更全面些吧。