第六周读书笔记——读《人月神话》有感
形象化，这是我翻开这本书的第一感受。作者花了大力气来想出一些形象的比喻来阐述项目中的一些问题，让不同资历的读者都能有所收获。一开始书就将软件危机比喻成“焦油坑”。使我们生动形象地感受到“软件危机”的恐怖，就像史前巨兽在焦油坑中挣扎的惨状，再一次说明了软件开发的过程绝非坦途，而是坎坷不断。
由于作者的关系，这本书对于一个项目管理人员可能会有更大的收获。即便如此，对于软件开发方面的小白我来说，还是有一定借鉴意义的。
人月神话，什么是“人月”？那是一个用来估计工作量单位，大致跟旧时工人出工的“工数”一致。Brooks认为，使用这种方法计量是有失偏颇的，因为1人工作1个月的效率并不等于（实际上远有偏差）30个人干一天的效率，只有当一份可分解且各部分不需要交互时才大致相等。而我认为可能不止于此，因为有些想法需要时间的酝酿，有些环节比较依赖于试错（比如说炼丹？）。但是一个较大的软件必然需要一个较短的工期，所以说集体的配合是必不可少的。这时候首先需要保证设计概念的完整性，无论是怎样的软件，最好由同一个团队主导，有一个清晰明确的模型和目的，之后所有人在这样的框架下努力，也就是“一以贯之”。如果有创新、改变，也应该与基本的概念相吻合，实现团体的合力。然而需要注意的是，客户的需求总是瞬息万变的，就连开发软件的团队的思考都有可能隔三差五翻新。因此凭空思考很可能导致无用功，因此一份公共的框架文档是必须的，一旦发现有抵触的地方，就应该防微杜渐，如果用书中的说法，就是“外科手术式”的开发队伍。其实之前我对项目很难有一个具体的规划，但是一旦记录下来之后，就显得比较丰满了。如果再对项目有所改动的话，心里也会不自觉地谨慎起来，不断地提醒自己要小心。这也是项目文档的另一个作用，让项目正式化，让每个参与者有一种仪式感。
有了一个好的纲领是成功的一半，但这还不够，还要考虑到团队合作中“人”的问题。团队合作首要问题就是交流，Brooks举了圣经中最伟大的烂尾工程——巴别塔为例子，告诉我们不能交流的团队终将分崩离析。那么我们应该如何解决这个问题？我觉得以下几点是不错的选择：第一点，需要团队有一个共同的想法（目的），这样的团队在处理问题时能够避免在根本上发生冲突。第二，团队成员之间应该以尽可能多的形式进行交流，这看起来就是一句废话，然而实际的项目中，许多人往往为了追求个人的进度而埋头苦干，忽视了交流；或者是呆板的定期交流让人倒胃口，不想开口说话。所以说无论是非正式还是正式，是简要的技术陈述还是共享的工作手册，都是可行的交流方式，而且这样可以有效避免人员缺失所带来的严重技术断档。以前和别人和写程序的时候也遇到过这样的问题，各自负责各自的部分，到了整合的时候一旦有一个人缺席，整个组的进度就都停滞了，而且都是对此有心无力。
纵然是大师写的东西，书上的某些东西也有过时之嫌。比如说书中的一些例子，这些例子可能对几十年的读者来说是很好理解的，但是对于现今的我们来说又有些陈旧和难懂了。还有书中提到的“削足适履”一章，主要解决的是存储空间的问题，但是就现在来说一般规模的软件已经可以忽略掉这样的问题了，不需要像几十年前一样非常拘泥于空间问题。总的来说还是获益匪浅，让我从管理层面重新认识了一遍软件开发的过程，以后看问题应当会更全面些吧。
