《人月神话》、《人件》近期动态
2004年7月，UMLChina 整理
《人月神话》台湾版出版
出版社：經濟新潮社，譯者：錢一一。
《最后期限》台湾版本
讀書有感--人月神話
http://blog.forlady.net/archives/000127.html
看到小女子介紹人月神話這本書，請不要以為是羅曼史小說或者傳奇故事。
它是一本二十年前出的、講三十年前軟體專案管理問題與經驗的書，原名是The Mythical Man-Month。其中的很多事例，現在仍存在，其中很多經驗，現在拿來用都還來得及。這次的版本為20週年紀念版。
曾經接過急迫且大型的網站建置專案，但是進行上卻還算順利，這是由於系統工程師十分有經驗，在分工、次序與掌控上，都做了很好的安排。
但在最近的一個朋友的經驗中，卻是遇到網站的機制改版，在時程與資源運用上卻不斷延遲，還好是內部機制，不用對客戶交代，否則所蒙受的將不是只有金錢上的損失。
我們知道時程延遲，但原因在哪裡？為何會發生？
人月神話的第二章，應該是這本書的精華，也是書名的由來，看完這個章節，發現作者道出很多軟體專案上的管理關鍵。而軟體專案是不可以完全套用傳統產業的專案管理方式。
第一個關鍵 樂觀
首先作者提出了一件常常發生的事情，這也是一個朋友身上發生的故事：『程式設計師都是樂觀的傢伙。』而且我發現越年輕越樂觀，但是無可避免的這是個年輕的產業，很少會遇到很有經驗的程式設計人員，這些年輕人，即使告訴他這樣是會有問題的，他也不改其樂觀。
所以『他們所做的第一個錯誤假設是一切都會進行的很順利』可是沒有想到一個bug，就可以花上一天時間也無法解決。然後，就延遲了後面本來假設可以順利進行的部分。
第二個關鍵 人月
人月，是我們預估和排定時程用的，但是作者提出一個前提：『使用人月必須要在人力與工時可以互換的狀況下。而且要當工作可以切割、投入工作的人不用溝通，人力與工時才能互換。』就是說要可以互換，才能使一個人做30天，與30個人做一天的結果一樣，不然單純用人月去估算時程，一定會有誤差。
為什麼呢？首先軟體專案有其連續性，作者舉了個例子，蠻傳神的，他說，生小孩就是要九個月，你叫多少個媽來生都是一樣。第二點是因為即使工作可切割，但是需要溝通，越多人投入就需要多的溝通與教育的時間，所以一個人做30天的工作不可能用30個人做一天就完成。
所以，Brooks定論說，在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。
因此，要讓一個專案順利進行，首先要有良好的時程規劃，考慮所有的因素，而且，程式人員要有勇氣不要妥協，堅持自己預估的時程。就像是廚師一樣，即使外面的客人在等著上菜，一隻雞要烤多久就要烤多久，不能因為妥協就用大火烤焦了。
外科手術團隊
這個篇章看完突然想到研究所的專案管理課程，三個學分，卻是我們一個學期的研究重心，四個實際運作的專案，大家分組進行，教授不斷的製造專案危機，像是公司被併購、人員流失、專案形式改變、客戶不斷施以壓力等等，但最後大家還是順利的結案。
這是個難以忘懷的經驗，組員們的默契在起初的確造成危機，但是，由於大家的素質還算整齊，很快就可以建立溝通的語言。加上大家熟悉協同科技概念與網路溝通，可以做到分時分地作業，也使得專案進行有效率。
但當我看完這篇外科手術團隊後，我發現其實還有個成功的關鍵在其中，就是同學們各有專長，所以，分工很容易，又因為有選出leader作為掌控者，所以，不會亂。大家不會做重複的事情。每個人按照時程交差，就可以順利完成。
作者認為一個外科手術中，有操刀的大夫，有護士、有麻醉師等等，各司其職。而不是像屠夫團隊，每個人都得拿刀。一個團隊中只有一個人操刀，其他人扮演支援的角色。這樣整件事情就會出自一個腦袋不會亂，也不需要不斷的溝通協調。
這兩個篇章是我比較有感覺的，寫出來跟大家分享。
最後，作者還有一個人月的概念我覺得很重要，這會影響到組織的公平性：一個好手，花一天可以做完，但同樣一件事，庸才卻需要三四天以上，甚至加班趕工，也許還領加班費。如果照這樣去計算人月，一定會差之千里。
有程序员把“人月神话”作为其blog的栏目
http://www.blogbus.com/blogbus/blog/index.php?blogid=14837&cat=1
其实读一本好书也是有要求的
http://blog.joycode.com/aspdian/posts/6356.aspx
前天，我的朋友sniper说他在读《人月神话》，并从中得到了很大的教益。这本书很早以前就听说过，而且还是很受推崇。但自己一直没有去读过，只是感觉自己还没有去读的水平。。如果没有书所设定的认知基础很难读懂，就算是读了也只是过眼就忘。一本好书更值得反复读，“温故而知新，可以为师矣”。为师很难说，但知新一定是有的。
什么是软件开发的核心问题？
http://forum.javaeye.com/viewtopic.php?t=1710
dlee写道：
按照软件工程鼻祖，《人月神话》作者 Brooks 在“没有银弹——软件工程中的根本和次要问题”一章中阐述的思想，软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。这个建模是含义广泛的，不仅仅包括对象建模，还包括数据建模、算法建模等等一系列的内容。总而言之是要先找到解决复杂问题的突破口（先要搞明白需要做什么，然后再考虑如何做）。至于采用什么表示方法（简单文本、UML 图、E-R 图）、采用什么高级语言、是否一定要用面向对象、使用什么开发工具都是次要的问题。
有些人每做一个新项目，不管三七二十一先画一大堆图出来。其实你看《编写有效用例》这本书中用到了很多图形吗（当然我不否认图形在有些场合的重要性）？很多时候可能你只需要把你的想法简单地在纸上画出来（一只铅笔、一张白纸，成本接近于 0）就足以帮助你理清思路了。如果你的想法都无法清晰地画在纸上，那么 ROSE 这样昂贵的工具就能帮助你了吗？还是你只能装装样子，否则混老板的工资于心不忍呢？
软件开发中，工具是非常重要的，完全有必要非常纯熟地掌握所使用的工具。但是一旦掌握以后，就应该进一步思考一些深层次的问题了。按照我的看法，开源软件解决了工具的问题，然而如果你一味依赖开源软件，而不去利用这些很好的基础解决复杂的问题（建造更加复杂的架构），那么等于是把你的明天拱手相送了。
我有很多计算机书，买的和从网上下载的。我把这些书分成两类：可以增加知识的，可以增加智慧的，并且优先阅读第二类书。几乎所有的书只要你买来都能增加你某方面的知识，但是第二类书可以使你变得更聪明。《人月神话》毫无疑问属于第二类书。你要问我读这本书的感受，我的感受就象是大热天踢球后喝了一杯清凉的饮料，套用一句广告词：“从这到这都舒服”。
jlinux写道：
软件开发的核心问题？ 我自己的回答是人.
这里面包括很多, 人, team, 公司等等, 从一个人到一群人, 不管是开发软件的人也好, 使用软件的人也好,都是由人为主体的. 而其他不敢是工具也好,还是方法也好, 不都是人在操作和使用吗.
这正是《人件》中所阐述的思想，我们以后会另开一个线索讨论《人件》中所关注的问题。国外资深的开发人员都读过《人月神话》和《人件》这两本书。国内的开发人员却不屑于读这些“没有用处”的书，而只对一些“神奇”的工具感兴趣（那些追捧 .Net 的文章很少能达到 robbin 文章的深度）。一些软件企业的管理者，更是不读书、不学习（那是我手下人的事情）、刚愎自用、好大喜功（昨天我卖机器很成功，今天做软件肯定也没有问题！？）。从企业高层到开发人员对于思考深层问题的漠视直接导致管理水平的低下，产品质量的低劣。以前我们嘲笑西方人只注重工具和各种奇技淫巧，却不知道人家早就不是这个层次了，而我们显然还停留在只注重工具和奇技淫巧的层次上。
软件开发可以说是因人成事，没有合适的人，你就别指望能做和别人相同的事情（没有金刚钻，就别揽瓷器活。假设给你 100 个开发人员，一年时间，你有把握开发出
JBoss 一类产品吗？我是说与 JBoss 一样好用，你不仅开发出来，还要能卖得出去，别人喜欢用）。张三程序员即使水平很差，如果参与过大量开发，一旦跑掉了，他的工作也不是随便找来一个李四程序员短期内就可以胜任的，所以所谓即插即用的“软件蓝领”纯粹是一个谎言。尊重人才，人尽其用是软件企业首先要解决的问题，也是关系到企业生死存亡的大事。
以下是我给自己制订的近期读书计划：
《人月神话》，已读完。
《人件》，尚未读完。
《测试驱动开发》，尚未读完。
《Java Modeling in Color with UML》，尚未开始。
《特征驱动开发方法》，尚未读完。
《分析模式》，尚未读完。
《数据挖掘——概念与技术》，尚未读完。
软件开发中的审美疲劳
http://dev.csdn.net/article/28/28962.shtm
surstar [原作]
软件的开发的过程是一个反复的过程，对自己的界面时时刻刻的面对，一种很简单而豪无意思的说法是：换一个角度来看的产品，也许有一些人可以做到，但是他们真的做到吗，这和一个人美术细胞有关，一个修养有关，我认为要做到：吹毛求疵，在《人月神话》里，作者这样说到，程序员是一个天生就有追求完美的天性，这也是在锻炼过程中生成的！（大意），我认为 对自己的产品吹毛求疵是可以做到的，现在你打开一个你自己软件，观看自己的界面：
大小是不是合适，是不是可以再小1像素或大1像素，
有没有BOTTON 是不大小不合适，位置怎么样，色彩怎么样
有没有功能上的不完整！
我个人认为审美疲劳不只是软件界面中有这样情况，在软件的代码和功能分析上也有如此的效应，总之，审美疲劳也许是吓唬人，只要我们作到吹毛求疵就可以作到了！
我这几天很烦！(产品概念完整性)
http://www.blogbus.com/blogbus/blog/diary.php?diaryid=226825
2004-06-18
我这几天很烦！
一是因为现在做的项目处于测试阶段，由于一些原因，导致现在发现了很多关于模块交互方面的问题。现在将这些模块“组装”成一个像样的系统，这些问题必须解决，而且目前只能自己与其它开发人员商量解决！
这个项目在设计的时候有七个人参与，应该是开发部所有的开发人员包括在内。当时先是讨论整个框架的设计，然后将各个模块的设计分下来，一人完成一两个，再接着开会讨论，讨论来讨论去，讨论的差不多了，也就是每个人将自己设计的模块接口写成电子表格（模块内部的设计有些有文档，有些没文档，因为每个模块的设计人员基本上就是这个模块的编码人员，所有其它人不会太多关心），然后每个人就开始实现自己的模块。后来因为人手不够，又招了几个写代码的人员，分给各个模块的负责人员协助编码。事实上在真正进入编码阶段时模块的负责人只剩下三个，其它的人呢？两个离职，一个是公司领导，不参与实际编码，还有一个因为考博，没时间亲自参与开发。而剩下的三个人中有一个人是这个开发小组的组长，协调开发小组的开发工作，当然也参与实际的开发。
可以说在整个开发过程中没有一个真正的产品负责人（或者称之为总设计师），用于负责产品的整体结构设计、各模块的交互关系、功能设计和实现方案的取舍。他必须十分了解整个产品及设计方案，他可以不写代码，因为维护整个产品设计方案的工作贯穿于整个开发过程，工作量是很巨大的。他也就是维护产品概念完整性的那个人！
其实存在的问题还有很多！近期我会抽时间将它整理下来，寻找问题的根源到底在哪，避免再犯同样的错误！
还有我去年买的《人月神话》，当时没看懂。前段时间我拿出来，终于将它完整的看完了，而且感触颇多。
为什么《人月神话》在20年后还能再出新版，而且又一次给于业界巨大的轰动，就是因为我们没有吸取前人在20年前总结的经验教训，还在一次次的重犯同样的错误！
……
这个项目是一个二次开发包。完了之后紧接着有很多项目都要依赖这个。二次开发包做成这样，不难预测以后依赖此开发包的项目又将使人进入新的“焦油坑”。我现在也不知道什么时候开发第二个版本，至少今年不太可能。
加班！加班！
2004年6月28日
今天看来又将是一个不眠之夜了，连续鏖战已经有一段时间了，最近这段时间家事国事天下事，扑面而来，真些应接不暇了。
回到加班这件事，记不得在哪本书上曾看到过所谓“应当给软件工程师合理的计划和工作时间，一周工作超过40个小时就视同犯罪”，从《人月神话》到《敏捷开发》，从最基本的软件工程方法论和思想到最细枝末节的计划安排技巧和开发技术，有哪些内容能够在提高开发效率、改善产品质量之余减少我们的加班时间、增进我们的身体健康呢？
书香气围绕身边的感觉
http://140.127.22.156/blog/genius/archives/cat_eae.html
人月神话...我Blog的名称...正如自已所期望的。这是我很想看的一本软体工程的书。而且名字也很优雅，这本书带给我的感觉也相当的不错，在今天我透过诚品的网路书店，买下了这本书。之後要开始阅读这一本，估计在5月1号开始，因为要等中山大学研究所考完，就拥有短暂自已自由的生活，读书是一种痛苦，读书同时也是一种休闲，真难定义自已呢..我想我还是会一直看书，这是我的喜好，逛书店、图书馆也是我的喜好，真想寻找和我相同的人。哈..我就是爱书香气围绕身边的感觉。
概念完整性
http://www.mypm.net/bbs/article.asp?ntypeid=4&titleid=551&page=2
看了《人月神话》，体会到一点：概念完整性非常重要，扩展开来说，pmbok中项目管理体系已经是一个经过验证的管理概念，要做好项目必须要关注项目中的各方面特性，就算你不关注，它们事实也存在。所以我认为一个成熟的项目管理人员，必须在头脑中首先有这样一个完整的项目管理概念，但是在小公司中，由于条件的不充分，可以弱化那些优先级不太高的子概念（比如hr）,但是这仅仅是弱化，不是不存在，在一定时候，你必须关注，它也许会作为最高优先级的项目管理方面出现，毕竟具体项目中的管理是活的。
所以我认为“概念完整性”，是非常重要的，不仅仅在业务方面，在管理方面也是如此。
泥潭
http://www.geocities.jp/baryonlee/weblog/2003_09_01_archive.html
上一个项目已经结束1个多月了，新的项目一直没有下来。最近的一个月，yan一直在设计他的workflow。workflow的思想是去年他们做open cube的时候学到的。那个系统最终还是成为了他们的噩梦。一周只回家一次，月加班时间达到300个小时，持续半年以上。最后的结果还是放弃。完全是《人月神话》里描写的泥潭。一个近百人组成的team就像一个困兽掉进了沼泽地，经常半夜2，3点钟开会，还一个人不缺，一周也不回家一次的人大有人在。开始还用sourcesafe管理，后来sourcesafe都不管用了，改用原始的笔记本，每一个要更新source的人都要先登记，在早上6点的时候，会看到大家排队，手里拿着软盘，等着更新source的场面。我虽然没有经历这些，但我可以想象得到。可笑的是，那个用来登记的笔记本有一天不翼而飞，哈哈哈哈
MVM的软件开发经验谈
http://hedong.3322.org/newblog/archives/000041.html
mvm的“75条”，读来深以为然，特转载于此。
5. 你们的项目组用了你能买到最好的工具么？
应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。（编注：干将莫邪――人月神话）
6. 你们的程序员工作在安静的环境里么？
需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。（编注：在空间上省钱――人件）
7. 你们的员工每个人都有一部电话么？
需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。（编注：电话――人件）
10. 你们的项目组中所有的人都坐在一起么？
需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。（编注：黑衣团队――人件）
13. 你们的开发人员从项目一开始就加班么？
不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。（编注：维也纳在等着你）
22. 你们项目组有Team Morale Activity么？
每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。（编注：黑衣团队――人件）
23. 你们项目组有自己的Logo么？
要有自己的Logo。至少应该有自己的Codename。（编注：黑衣团队――人件）
71. 你在招人面试时让他写一段程序么？
要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。（编注：雇用一个变戏法的人――人件）
73. 你们的程序员都能专注于一件事情么？
要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。（编注：朝九晚五无所为――人件）
《人件集－人性化的软件开发》
http://think.blogdriver.com/diary/think/index.html
《人件集－人性化的软件开发》（The Peopleware Papers）这本书是Larry L. Constantine著， 是对《康斯坦丁人件集》（Constantine On Peopleware）的整理再版。
刚读了将近一半，总的感觉不如《人件》作者分析问题更透彻。但还是有很多收获，尽管有一些内容已经有些陈旧，但是并不影响阅读的价值。而且书由许多短文组成，很适合间断的阅读。
作者认为软件开发中，人的进化速度远远低于技术本身的进化速度，因此多一些对人本身包括团队的研究是很有意义的，这一点我十分赞同。其实不光软件开发如此，整个人类社会的进化中，人自身尤其是思想的进化是很缓慢的，最近走马观花看了两千年前先秦的一点东西，感觉其中对一些问题的论述已经非常成熟，丝毫不比今天的人逊色。《登徒子好色赋》中登徒子和宋玉在楚王面前的辩论简直就是古版的“刘罗锅与和珅”。上世纪30年代林语堂的《中国人》中描述的中国人，今天读前来丝毫不觉得过时和隔阂。
所以，在软件的短短几十年历史中，开发人员的个体和团队的一些情况，确实没有什么大的变化。
《手机》与《人件》
昨天，看了《手机》的DVD，恰好这几天也看了《人件》中关于电话和工作环境的论述，感觉两者有很多的相似之处，我不知道
刘震云和冯小刚是否读过《人件》，感觉上几乎能够肯定他们没读过，因为《人件》毕竟是软件行业的书籍，目标读者群就很窄。
《手机》从社会的角度，描述了手机的出现，对个人隐私（不管是好的还是坏的）空间和时间的掠夺，描述了技术跟人性之间的关系，其实技术只是一种工具，在没有手机的时代，人们一样会撒谎，会受到干扰，只是远没有现在这样激化与明显,技术催化了人性恶的暴露，或者说为人性恶的发展提供了更好的途径。
《人件》更偏重于论述电话对人的干扰，对脑力生产力的破坏，生产率的降低。想一下自己的工作环境，果真如此，每天自己的思考要被许多电话打断，以前却没有意识到，这是一个普遍的现象。人们既是办公室噪音的受害者，也是噪音的制造者。《人件》提到人们在思考时，会进入一种“顺流状态”的愉悦状态，而进入这种状态需要一定的时间，如果被打断就只能重新开始，反复的打断会让人产生挫败感。《手机》提供了一个很好的场景：费老给几个人开会，思路从萝卜、狗熊等将要进入“顺流状态”，却一再被众人的手机打断，后来干脆不知道自己要说什么。我们的办公室里，不是也经常有类似的事情发生吗？
以后，我要推荐我们的同事，多用mail，少用电话。
《人件》中还提到，发明电话时，将规则定为只要被叫方不拿起话筒，电话铃就会一直响下去，而不是给人选择，或者响几声后停掉。这反映了新技术的“霸道”，有很多类似的例子，一种新技术可能彻底改变某种规则，比如：在家里打电话的人比去现场站着排队的人更有优先权，身边很多例子可以证明。我感觉这种新技术的“霸道”，可能有几个原因：1 技术本身的缺陷导致客观上不得不如此，电话铃之所以一直响下去，可能是因为这是最简单、成本最低的实现方法。2 垄断或者技术拥有者商业利益的驱动。手机单向收费就是最好的例子，技术上不存在任何问题 ，还有不同运营商的互联互通。3 新技术的发明者，缺乏深层的人文思想。很多技术型人才往往对技术有着狂热的追求，而对于技术对社会的影响，考虑的相对较少。
总之，《手机》还算值得一看，《人件》更是一本好书。两者有相似，也是英雄所见略同吧。
虚张声势的最后期限
http://ms.mblogger.cn/mars
2004年2月13日
很多项目经理都喜欢对程序员下达最后期限，总是要求工作在某时间前必须完成。我看《人件》中有一节是论述团队自杀的，其中有一条就是虚张声势的最后期限。以我的感受，我觉得最后期限有几个弊端。首先就是产品质量的降低。下达最后期限一般是按照正常进度不能完成的，对于程序员来说，如果要求进度加快，则必然的产品质量会降低。可能项目经理会说，质量要求低点无所谓，只要能完成就行。要求低质量的产品会对以后的维护工作带来更大的麻烦，另外，对于程序员来说，质量降低必然会损害他的自尊，谁都不愿意被人挑出自己产品中的毛病。其次，如果程序员按照要求完成了任务，但是以后的日子，他发现，所谓的最后期限不过是项目经理的一种手段，目的就是能让项目如期的进行。他肯定会有被欺骗的感觉，如果项目经理经常使用这种最后期限的方法，就如同“狼来了”一样，没有人会理会。