由《人月神话》和《功夫》所想到的

UMLChina 整理 

http://cnweblog.com/asj/

功夫

呵呵，不是观后感，因为我还没看这部片子。不过赶上这个热潮，天天耳边有广告给你喊“功夫，功夫”，不由得有点感想。

现在说起功夫这个词，恐怕任何人第一个想到的都会是双截棍和“啊～～呀～～～～”的一声怪叫，李小龙实在是太成功了，不仅让外国人了解了功夫，也从新定义了国人心中的这个词。让我们几乎忘记了它的更普通的含义。

功夫代表时间：“要作出这么个东西，可得花功夫的。”

功夫代表工作量和主观努力：“不下功夫怎么会作得好呢？”

功夫代表了技术含量和人员的水平：“这活，没真功夫的绝对玩不来。”

忽然发现“功夫”是一个描述软件开发度量的理想单位（终于绕回本行了 ），想想《人月神话》中反复讨论的人－月之间的关系，想想项目管理三角中的资源－时间－功能和三角中间的质量。“功夫”两个字，似乎都已蕴含其中了。

我们的民族有长久而辉煌的工艺史，也有着从长期工艺实践中提炼的哲学智慧。就像武术从文人的个人修养中借用“功夫”这个概念一样，利用我们的文化资源，迎合中国读者习惯的“武侠文化”未必就是一件坏事。

如果我们用“这个软件需要花xx功夫”，而不是代码行、人月、功能点之类的来和客户交流，是否会使得项目的规划更容易避免踏入人月的误区呢？也许，正是一件需要下功夫的事。

http://blog.codelphi.com/huk/archive/2004/11/29/30020.aspx

了解了这个神话, 我们就可以采取主动行动.

1.首先, 不要低估任何一个产品的难度, 难度估计得高点总是没有错的.(我曾经犯过多次这样的错误) 这样, 在确定任务进度前争取更多的时间.

2.很显然, 既然有可能在任意时刻发生问题, 为什么不提前多干点呢? 很少有人愿意这样. 但是我的经验是一定要提前多干. 在最近的2个项目中, 都是提前很多时候完成了大部分的工作. 90%的东西完成了, 而产品交付时间则剩下1个月. 眼看可以轻松了, 却仍然忙着攻克最后的难点, 到了最后一天才真正完成任务. 险得很. 按照时刻表完成进度的程序员都一定会翻船. 不信! 哼, 随便找一个去看看. 我很自信这点的判断.

<<人月神话>>中有着好的程序员可能效率比糟糕程序员高10倍的可能性.在我的人月神话中确实有着好的程序员比糟糕的程序员速度快上10倍的例证. 当时团队中一天无法完成一个极度简单功能的PROGRAMMER.(不知到此人现在怎么样) 但是在人月理论中, 这样的人也照样要占着进度表的一条...

新员工需要培训, 薪水低. 培训好的员工会向薪水高的地方流动, 公司不得不找新人, 再度开始培训. 这是个死结. 这个世界上并没有那么多的熟练工存在. 即使是劳动密集型工厂也是如此, 何况软件公司. 我们的教育体制有2个极端, 要么就是象在培训"科学家"(教学一些似乎很深奥的课程), 要么就是培训"记忆"(除了背诵后能解决考试问题,其他什么也不能解决),我也是这个体制中出来的, 幸亏我还有兴趣看自己喜欢的书... 这样的教学体制很难让我们更强大. 但是目前也没有更好的体制能提出, 谁让我们的人口这么多呢.(关于人口和教育体制的因果关系很复杂, 不是我有兴趣写的范围)（陆麟）

http://think.blogdriver.com/think/225643.html

前几天，把人件看完了。从去年上半年（？）开始到现在，终于把人月神话、人件、最后期限这几本书通读了一遍。因为中间经常被其他的事情打断，所以阅读战线拉的很长。看大师的作品，果然如行云流水，是一种享受。现在凭着记忆，讲一下自已最强烈的一些零星的感受，我的理解也许会有偏差：

一、人月神话：

1、把项目的工作量定义成人月，并认为人和月可以互换，例如认为一个500人月的项目，如果100个人做5个月可以完成，而500个人做只需要一个月就可以完成，这只是一个神话。人类的认识需要时间周期、项目的运行也需要时间周期，这个周期相对固定，不会因为人多而变短；相反，向一个进度滞后的项目中添加人手，只会使项目更加滞后，因为需要额外的培训、交流，需要占用现有人员的时间。

2、项目初期就安排100%的人手是没有必要的，只有设计完成后，才大规模地需要人。我觉得这一点可能适用于大系统，对于像敏捷开发和极限编程这样的方法来说，并不适用。

3、最好将项目的完整概念保持在一个人的头脑中，这样可以保持整个项目的概念完整性。如果项目过于庞大，可以由一个小组来充当项目的“大脑”工作，总之整个系统的完整概念（我理解是level0的架构）应该由一个或很少的人来负责。

4、将一个能够运行的项目的程序，提升成产品，工作量的代价是1：9

二、没有银弹

没有任何一种方法或者工具，可以在十年内使得软件开发效率有数量级的提高。根据我最近做过的两个J2EE项目（用到jsp＋java bean＋XML，没有EJB）的数据，我们的人均java开发效率为：

项目A：java 287行/人天 加上 jsp+xml 297行/人天

项目B：java 275行/人天 加上 jsp+xml 149行/人天

因为项目中包含了很多以前积累的现成的框架程序，所以实际的效率可能还要低一些。这个数据跟汇编、c、c++等大概都在250行/人天的数据大致相符。

所以说，软件行业距离成熟的路还很远，软件行业的大幅提高生产率的“工业化革命”还遥不可及，现在基本处于“手工作坊”阶段，差别只是作坊的大小不同而已。

三、人件

软件难就难在人是其中的决定性因素，用传统的工业化管理方式管理软件开发人员是行不通的。

四、最后期限

我感觉是大家在被无数个最后期限搞的精疲力竭之后，向往的一个神话，也是一个寓言。是个放松的好材料。（thinking 2004年07月2日, 星期五 18:21）

http://www.donews.net/bluez/rss.aspx

抽烟看报是可以同时进行的，甚至和“排毒养颜”一块进行都无所谓。

但是抽烟时候你能和女孩打Kiss吗？

游泳洗澡是可以同时进行的，如果你带齐家生，顺便做做护理都行。

但是游泳时候你能看到岸边MM的衣领没扣好吗？

写程序跑客户也是能够同时进行的，如果你腿够快，中间还能抽空去小个便。

但是，各位老大啊，你们有谁能一边写程序一边钻桌子修电脑？

前些天领导训话时候曰的，说很多项目经理都不写程序，对自己也是浪费，又耽误事。。。等等等等。

并举出外科医生手术的例子，把项目经理和主刀医生扯一块。

领导认为：团队里面，项目经理应该亲自编程，其他人都是支援人员等等。

领导认为：一个程序员为什么就不可以多懂点编程之外的事呢？比如说看看客户脸色，揣摩一个客户喜好如程序界面喜欢什么颜色等等。不要固步自封嘛。

领导认为：每一个人都应该出去面对客户嘛！

领导继续认为：程序员的工资应该是浮动的，根据代码质量发放奖金。

领导谈到了《人月神话》

领导说：散会，晚上有空开另一个会。。。

http://babyfacer.computer.mblogger.cn/

经过那个学期我就形成了一种观点，基础永远是最重要的，只要把基础学习扎实了，什么东西很快就能学会，触类旁通！所以花更多时间在学习高级的一些应用上面还不如花在基础上面更划算呢！你见过程序设计都没有学好的同学想通过学习《人月神话》，《Peopleware》这些书来达到高手的境界的么？还有些同学光关注程序语言的学习，关注practical的学习，对其中本质的东西确不闻不问！在这里我又想引用候老师的一段话，个中味道自己去品位吧：程式语言是程式员最基础的功夫，必须熟练它掌握它。但若只是如此，编写不出好程式、大程式、专业程式。大家都会说中文，独独有人旁徵博引，左右逢源，字字珠玑，文思隽永，这是为什麽？功夫在语言之外！

http://www.blogit.cn/rss.php?blogId=748&profile=rss20

我的运气一直就是很好的，出生后就赶上了改革开放，上学的时候有很多书看，这些破烂先不提。

特别是毕业后刚好赶上招工高峰时期，求大于供，去了一家日资企业（很多当时读研的同学现在毕业后，工资福利待遇什么的远不如我一个破本科生），然后就是出国研修，回来时辞职刚好赶上有家公司需要我这样的人，然后项目结束后走人的时候又赶上朋友推荐的猎头公司的挖人招聘，正好有适合的工作岗位，简直不能再幸运了，呵呵。

就连《程序员》杂志，《优快云》杂志，《深入浅出MFC》等书籍的出版时间都是严格的配合我毕业初次工作，技术提高，项目转换等时间的。严丝合缝，分毫不差，精确度令人吃惊。

我编码的时候，市面上主要就都是编码方面的书籍，等我做管理工作了，市面上的管理书籍也开始大量的涌现。连《人月神话》《设计模式》等书籍中文版的出版都是严格的配合我的工作侧重点的。

前一段时间离职的时候考虑想要总结一下小企业项目风险承担如何进行科学量化的问题，结果刚好就出现了《与熊共舞》这本书，都不用我总结了，而且还帮助我学会了不少科学的量化的东西。

最不可思议的，nnd我刚跳槽到咨询管理公司，市面上就出现了一本好评如潮的管理咨询书籍的中文版，叫《咨询的奥秘》。

真邪门了，我都不知道说什么好了。

时势造就英雄还是英雄造就时势，我不去讨论了，但可以肯定的是，当前时势已经有了，我是否是英雄，是否能够成为英雄，还需要我自身的不懈努力。

http://www.surstar.com/blogx/Rss/

关键是我们如何做预防审美疲劳呢？

软件的开发的过程是一个反复的过程，对自己的界面 时时刻刻的面对，一种很简单而豪无意思的说法是：换一个角度来看的产品， 也许有一些人可以做到，但是他们真的做到吗，这和一个人美术细胞有关，一个修养有关，我认为 要做到：吹毛求疵，在《人月神话》里，作者这样说到，程序员是一个天生就有追求完美的天性，这也是在锻炼过程中生成的！（大意），我认为 对自己的产品吹毛求疵是可以做到的

http://blog.javaeye.com/index.php?op=ViewArticle&articleId=98&blogId=41

看《人月神话》得到的一个项目变更决策启示

《人月神话》中有这么一句话：

“每个产品都应该有数字产品号，每个版本都应该有自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。”

之前在处理项目的BUG和小的需求变更的时候，总是会遇到应该归到哪个版本下的问题。因为在这些bug或者小需求出现的时候，总是会有新的开发分支正在进行中，因此常常会为决定这些修复或者改进工作应该放入哪个版本或者分支而费心，而其结果常常导致版本之间的不一致。不过这里仍然有一个问题：如果前一个版本冻结之后，所有的后续工作放入下一个版本，但是假如（事实上通常会这样）后续的版本正在进行重大开发，那么这些小修改和改进也要和新版本一同发布吗？显然客户不会同意，在他们看来那些只是小问题，根本不应该归并到新版本中去，他们并不想要这个结果，只想要尽快能够解决问题。

不过，不管怎么说，尽可能在恰当的时机冻结版本应该是一个好的决策倾向。（youngS）

http://sanwangx.brain-c.com/archives/2004_04/18_5/

（出去旅行时带上《人月神话》…）

整理好家裡，當然接下來要整理後天要出發的行李囉

還真多咧，不過帶回來的行李一定會更多 :p

書本資料類

出發前7天海外旅行英語會語手冊

經學長加持友情贊助的，雖然我英語還可以，不過還是多抱點佛腳才不會太難過咩

The Mythical Man-Month (人月神話)

月初才出版的，正好拿來飛機上殺時間(;-))

前人的Universal Studio和Walt Disney World各theme park的map guide

「知己知彼，百戰百勝。」先熟悉一下到時進園才能玩得盡興囉，不過學長也口頭描述了好幾個小時了，包準到時玩得直呼痛快

http://rockychen.blogchina.com/blog/article_38647.214276.html

引进版书的书名究竟该如何翻译，学界一直存有争议，有的认为要尊重作者，应该直译；有人却认为要入乡随俗，意译比较妥当。其实直译或者意译都不是惟一的选择，只有按需应变才是正解。

意译虽然能入乡随俗，但却需原作者同意后方能修改。万一作者不同意，那也只能沿袭原先的书名。

其实就算是直译的书名，也有一些相当不错的翻法。比如《人月神话》就是非常成功的一个例子。它原名为《The Mythical Man-Month: Essays on Software Engineering》。最初引进的时候，曾有人想翻译成《神秘的人月》或《被神话的人月》，最后是简化成了《人月神话》。为什么要叫《人月神话》呢？因为这本书就是讲的如何统计一个人单月的工作量。

http://chekhovchina.blogchina.com/blog/article_27886.95866.html

产品概念完整性和团队构成（2004年 09月04日）

目前汉化X国人的程序马上就要告一段落，中间顺带读了读X国人的程序，虽然同事都说X国人的程序很臭，但是我觉的X国人的程序很不简单：上百兆的源代码，几十个工程中有大量的重用模块；所有程序的界面风格几乎一致；调用方式一致（但也可以明显看出这是不同水平的程序员写的程序，因为有的程序往往在犯一些很低级的错误，例如写一个错误的SQL语句）。对照一下自己，以我现在的水平，似乎很难作到这一点，在以往的项目中，我们的程序经常会出现N个人通过不同的方式在读取一个INI文件，或是每个人都写自己的身份证号码校验程序，如果一个程序由多个子系统组成，那么各个子系统的界面和调用方式也是根据不同人的习惯而有所不同。整个程序下来，功能可能是都完成了，但是却怎么看怎么别扭，同时由于程序模块的大量重复和风格的不一致，程序的维护也有很多的问题。

自从买了《人月神话》后，当每个项目结束时，我都会重新读一次这本书，因为从这本书里，的确可以找到很多在项目进行中碰到的问题的答案。这次重读《人月神话》，我觉的我在它的3，4，5，6，7章中找到了部分答案，即如何保持产品的概念完整性，而要保持产品的概念完整性，又和整个开发团队的构成密切相关，所以在3，4，5，6，7章中，也涉及到了开发团队的构成和沟通方式，当然，团队构成和沟通是个很大的话题，但是这次我只写写同产品概念一致性有关的团队构成的一些感想，其他就不提了。这篇文章，就算是《人月神话》这几章的读书笔记吧。

以前研究所的软件开发中，往往是以这种方式进行：团队中骨干人员写出需求，然后骨干人员进行一个分析，画出ER图并且划出各个功能模块，然后根据模块功能不同，骨干人员完成最复杂或最核心的那部分，其他复杂的模块交给其他骨干，一些简单的模块交给新手。最后一个综合，交付了整个程序。这种开发方式带来了很多问题，主要表现在：

l         模块的可重用性差,整个程序依据功能模块的不同交给不同的人开发,因此经常出现一个程序中有十多个身份证号码校验函数的情况.

l         程序风格严重不一致,虽然在开始开发前,整个团队会规定一些规格说明,例如背景色,字体,程序风格等,在开发过程中,不同的开发人员也会对这些风格不断的调整,力求一致,但是因为人的差异,最后交付程序的风格还是差异很大

l         需求无法最后贯彻执行到程序中,当程序人员根据需求完成程序的开发时,需求人员却发现功能虽然完成,但是却没有贯彻需求的整体意图(往往体现在界面和操作方式上),当需求人员要求开发人员改动时,因为界面和操作方式的改动往往是个体力活,没有人愿意作重复工作,所以造成了开发人员的抵触.

后来去公司混,又感觉到了一种新的概念,就是在写方案和写需求时,头儿往往要求往大了写,具体就是,在写一个方案时,为了打动用户,能想到什么就写什么,能怎么吹就怎么吹,头儿提的要求是,”想到不写出来,是能力问题,写不出东西来,就代表你水平差,至于写出来了作不作,能不能作,那另说”.这样带来的后果就是 方案,需求,和开发完全脱节,开发人员面对给客户看的方案和需求,不知所措,按需求来吧,方案写的天花乱坠,作下去要死人的;不按需求来吧,那就不成体统了,所以最后也没有人把需求当回事。

对于研究所那种方式,我以前想的解决方案是,通过增强设计能力,用一个好的系统设计,来保证模块的可重用性,按我以前的设想,在需求结束后,设计是个很重要的阶段,我希望能够达到的目标是,在设计阶段,就能事先规划好程序模块的重用;设计,可以直接指导编码.所以,当时看到UML后,如获珍宝,整天琢磨着边界类,实体类,控制类等等,以为按这套东西,就可以达到设计这个境界.可是时间一长,发现自己的力道的确不够,怎么也达到不了这个境界,也许有的大牛可以,但是我到不了.

在《人月神话》第3，4章中，Brooks提出：

l         概念完整性是系统设计中最重要的考虑因素

l         为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成

l         要得到概念上的完整性，就必须有人控制这些概念，这实际上是一种无需任何歉意的贵族专制统治

当然，在Brooks的概念中，概念完整性和体系结构，更多是指的是需求上概念，这里我扩展一下，我想表达的概念完整性，是指在整个系统开发过程中，需求，设计，编码的一致性。也就是说，在最后交付的程序，能够很好的表达需求人员的设想；整个程序具有统一的风格，所有的程序具有统一的结构（例如相同的调用方式，可重用的模块）；开发人员能够很好的贯彻需求人员和设计人员的意图。

但是，在实际中，概念完整性却很难执行，这主要表现在：

l         设计的不确定性，也许有人能进行很好的设计，但是我更接受源代码即设计这个概念（或者说我只能达到这个层次），只有在编码时，才能发现大量可重用的模块。这个时候谈模块的重用有点晚。例如，大家很容易把通讯模块交给A开发，B开发业务模块1，C开发业务模块2，B,C都调用A开发的通讯模块，但是B，C却都自己写自己的身份证代码校验模块。

l          对执行的漠视，国内有句俗话，四等人员CPP，三等人员DOC，二等人员PPT，一等人员TMD。有经验的成员，不到万不得已，往往不愿意进行具体的开发工作，他们往往让新手或一般程序员来完成编码工作（CPP），自己热衷于写出各种设计文档（DOC）来指导新手或一般程序员进行开发，而产品的设计人员多用一个PPT来说明产品的概念，当最后交付程序时，发现产品的概念和现状差别太大时，最高领导大骂TMD一顿后，继续把任务交给新手来开发。实际上，我觉的，越是高层，越是有经验的人员，越要深入到开发一线，通过细节的执行来贯彻整个产品的完整性。

l          开发人员水平的不一致性导致产品的不一致性，由于在开发过程中往往是按功能模块划分，如果开发人员水平高，那么这个模块可能看起来会比较舒服，也比较稳定，反之，另外一个由新手开发的模块就看起来很丑陋。

l          团队成员沟通上的障碍，当需求人员完成需求后，如果交给其他人员设计，中间会丢失一部分信息，设计人员在交给开发人员后，也会丢失一部分信息。最后就导致产品的设计概念和交付产品的严重不一致性。

所以，从上面的分析看出，如果想保持产品概念的一致性，关键在于要建立起一个成功的开发团队。按Brooks的说法，应该建立起一只外科手术队伍，这个队伍包括

l          外科医生（也就是首席程序员）来定义说明书，设计程序，编制源代码，测试和书协技术文档。

l          副手：能完成外科医生的任何一部分工作，但是主要是作为设计者，讨论者和评估人员，我的理解上这个人主要是同外科医生进行沟通，通过强强交流来保证设计的正常进行

l          管理员：替外科医生节省管理上和行政上的时间。类似PM

l          编辑／文秘：协助外科医生和管理员完成文档等工作

l          程序职员：他把程序员从文书等杂事中解放出来，同时保证文档等其他杂事的质量，我感觉应该是配置管理员。

l          测试人员：不多说

l          语言专家：对技术进行研究，为外科医生解决技术上的问题

l          工具维护人员：我没有理解这个人的作用。

毫无疑问，这是一只很理想的队伍，通过外科医生，来保证概念的一致性，同时大量的辅助开发人员，把外科医生从繁琐的日常事物中解放了出来。但是，这太理想了，我估计国内的开发中几乎不可能形成这么一只队伍。实际情况往往是：

l          项目经理：这个人多半是技术出身，他制定计划，写出需求，作出设计方案，和客户进行沟通，有时还要亲自动手，完成若干核心模块的开发。也有的时候，这个项目经理是不动手的，只作所谓的管理，但是却拥有技术的决定权。

l          骨干：如果项目经理在这个团队中搞技术，那么骨干的作用多半是负责某个模块，或是某个模块的核心，如果项目经理不搞技术，那么这些骨干多半就写需求，或写设计方案等等。

l          新手或一般人员：他们就是编码。

这样带来的后果就是：：

l          无法保证概念完整性，需求人员，设计人员没有精力去深入到编码，也就是产品的细节当中，因而也就无法在最后的产品中体现概念的完整性，同时，也无法进行模块的重用

l          造成人员之间关系的紧张与对立，在开发前期，由于沟通问题，产品的需求和设计人员（PM或骨干）无法和实现人员（新手或一般人员）就琐碎的细节进行沟通，在交付产品时，项目经理或骨干发现产品的不一致性，要求实现人员返工，导致2方关系的对立和紧张。

l          结构设计人员制定出无法实现，或代价高昂的需求或设计，使所有的人陷入困境。

l          最低层开发人员觉的工作无聊，因为涉及不到核心工作，他们会觉的自己是在进行着无意义的体力工作，他们的创造性和构思被项目经理或骨干剥夺，从而士气低落。

Brooks似乎已经给出了答案

l          尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

l          牢记是开发人员承担创造性的实现责任；结构师只能提出建议。

l          时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法。

l          对上述的建议保持低调和平静。

l          准备对所建议的改进放弃坚持。

l          听取开发人员在体系结构上改进的建议

我对此的总结和补充是：

l          产品的一致性必须在制度上给予保证，不能分割需求，设计和开发的一致性，这个产品的技术负责人（无论他是PM还是架构师）必须建立技术上的绝对权威来保证产品的一致性。

l          技术负责人必须严格的贯彻执行能力，也就是说，在需求，设计完成后，技术负责人必须深入到编码的细节中，他应当指导一般开发人员编码并帮助他们解决具体的问题，而不是命令或要求他们解决问题。

l          不要把编码变成一种体力劳动，编码才是真正的创造产品的决定性部分，在编码过程中，保证编码人员与技术人员的良好的沟通和交互，不要等到产品提交测试时才由设计人员提出这样不行。而是由一开始就由开发人员和设计人员来决定什么样才行，实现也是一种快乐。

l          在不同阶段，都要保持所有人员的持续参与与沟通，鼓励开发人员对设计提出意见，并迅速作出反馈。让开发人员也参与设计，但是不决定设计，通过这种持续的反馈和沟通来实现模块的重用

l          加功能由结构师（PM或设计人员）来决定，减功能由开发人员来决定。

上面这五点应该体现出3个关系

设计与实现

管理和技术

集权和放权

但是在实际中，要想处理好这3个关系，仍然存在这很多困难，主要表现在

l          对技术负责人压力过大，在中小型团队中，往往是技术负责和管理负责是同一个角色，同时具有管理技能和技术技能的人很难找到，同时具有思想家和实干家就更难找。很难有人能够同时处理好管理与技术，宏观与微观的关系。

l          一般编程人员一开始就没有热情，现有的工作对他们没有多少吸引力，他们只是为工作而工作，因而在项目中拒绝沟通，对项目也没有多少的兴趣。

http://lilybbs.yaoge123.com/vd953334/blogdcon?userid=photogis&m=9&d=24

每当想对程序与程序员的职业发表看法，就想起了人月神话的第一章，然后就长出一口气，我所想说的，都被人家说过了。

http://teacher.zjnu.cn/lester_ruan/more.asp?name=zjlester&id=2

 [偶尔发酸]这几日看的几本书

五一的假期可以做一次很好的精神旅行，因为没有打扰且没有体力劳损之虞

。。。。。。

也看了一本关于合作学习学术著作，只是尚未完工，引文甚丰富，文字也不见晦涩，算是学术类书籍类中不错的一本。

只是中国学者在这方面大多缺乏自信，自己的体系没有太多坚持。

有时候我想：类似〈人月神话〉的随笔风格写学术说不定更会受欢迎。<人月神话>单就行文风格就很让我们怀念

http://threeseven.mysmth.net/pc/pccon.php?id=342&nid=101241&s=all

你看到我今天穿了仔裤滑雪服蹬着翻毛皮鞋背着我结实的包迈着大步进电梯的模样

我坐在椅子上一手搭在那小小的台面一手托着下巴痴想

没有窗户的教室冷气对着我嗖嗖作响

谁知道我现在构思我要去西藏

幻灯片里讲的是几个人对着项目拍拍脑袋画着圈圈线线

什么Eearly start Late finish资源有限人工有限赶紧交货时不我待

人月神话

这真的只不过是个神话

http://www.51one.net/info/6909784635566102.htm

不过另一个我现在依然不得其解的问题是有关开源团体如何协作开发的问题（请原谅，我还是跑题了）。像JBoss那样有数十人专业团队者自不待言，而至于Apache那样的数万人开发规模（甚或Linux），他的协作方式，至少Brian的解释（《程序员》2003年第5期）并没有解除我的疑惑。因为，正如Brooks在《人月神话》里所提到的，人越多并不代表越容易完成既定任务，沟通的成本，最主要的是某些任务具有不可分割的特性，又岂能轻松“摊派”给多人呢

http://blog.onweb.idv.tw/mt-comments.cgi?entry_id=365

相信我，在台湾，我还没看过哪家软体公司能做到对时程实务的估算，往往 PM 所做的所谓 "人/月"，那根本叫造假应付，一点都不切实际。(可参考：人月神话 一书)

而所要求要团队成员所写的 "工作报告(TimeSheet)"，我们团队都戏称为 "黑奴系统" ^_^

http://wenj.blogchina.com/blog/article_672.30197.html

《人件》-一本让中国老板害怕的书

这是一本可与《人月神话》相媲美的书，是一本让擅于给员工洗脑的任某某、柳某某害怕的书，是高举人本主义大旗的书，我特别推荐给工作狂们阅读。中国员工看过本书后的反响见详细内容。（射木，2004年 07月31日）

http://brandworker.blogchina.com/blog/month.6742.200407.html

刘亚东的“软件恐惧症”与计算机科学家布鲁克斯的论断不谋而合。这位曾获得图灵奖的学者在其著名的作品《人月神话》中说道，无论哪种方式，过去几十年的大型系统开发就像一个焦油坑，很多大型和强壮的“动物”在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队——大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中……

在中国，这个“焦油坑”其实不仅仅在刘亚东所熟悉的电信业，伴随各行各业信息化的加快，这样的“焦油坑”随处可见。尤其是在那些金融、电子政务、大型制造行业等，往往因为竞争与效率的要求，他们的信息化走得更为积极与迫切。“而这，也就有更多的机会去制造一个又一个的‘焦油坑’。”

http://www.popsky.com/bbs/viewthread.php?tid=1010

已然不记得2003年的元旦是如何过的了。当时的心情彷徨而茫然，心乱如麻。随手翻开《人月神话》，赫然印的是“焦油坑”！真是焦油坑啊，无论是工作还是感情，感觉自己在不断下陷，下陷……

那段日子想来十分不堪：一直到过年，几乎没写一行代码，没看一页书，每天不是往别的办公室跑就是木然的对着电脑扫雷。对一个以程序为天职的人来说，这是很可怕的事情，感觉上接近崩溃的边缘。

http://www.flashanywhere.net/mxna/blogview.cfm?blogid=98http://www.flashanywhere.net/mxna/blogview.cfm?blogid=98

前天，我的朋友sniper说他在读《人月神话》，并从中得到了很大的教益。这本书很早以前就听说过，而且还是很受推崇。但自己一直没有去读过，只是感觉自己还没有去读的水平。其实读一本好书也是有要求的。如果没有书所设定的认知基础很难读懂，就算是读了也只是过眼就忘。一本好书更值得反复读，“温故而知新，可以为师矣”。为师很难说，但知新一定是有的。

http://rmwz.blogchina.com/blog/category.php?id=925&pageno=2

［转载］为了学习技术而失去了很多东西的人进来看看

学习不单单是学技术的，学习怎么和人相处，学习怎么让人开心也是学习的，怎么和人协调，怎么样让别人注意到自己，怎么样去表现自己，这都是要学习的，然而这些东西在书上是学不来的，特别是在计算机科学类的书里，更是没有。

不知道来这里的人有多少是看过《人月神话》、《人件》的？如果看过的话，而且承认里面的观点的话，就应该知道，项目的成功，以及个人的成功，并不是单单依靠技术的，很大程度上是依靠社会科学的。

而且，看样子，好多人想一下子成为行家里手，拼命的学习，节假日，正常的休息，等等时间，都投入了学习，好像都想在多少多少岁之前把所有的东西都学全，于是埋头于书本和程序之间，忘记了人间，说起来真的好感动，在感动的时候却带着些许的同情和悲哀。

为什么要那么拼命学习呢？仅仅因为兴趣吗？如果是兴趣，那为什么要拼命的赶时间的去学呢？怕比别人落后吗？也许吧，如果你真的是在走自己的路，那为什么要以别人的目标为自己的目标呢？

如果，你编程的目的是为了那诱人的工资，为的是职业的发展；如果，你想升经理；不要全情投入到技术当中去吧，已经有了太多的例子说明单单是技术不能让你得到这些，仅仅靠技术得到这些的人实在是太少了，但是，却有很多的例子告诉我们，高工资，当经理不需要精湛的技术。去跟不是程序员的朋友去走走，不用整天的学技术，跟女朋友去看看电影，逛逛公园，去做做这些无聊的事情吧，跟朋友去喝喝酒，聊聊天，可以让平淡的心多一些色彩，可以让自己不那么郁闷。把你学习的时间分一部分出来吧，用在生活的琐事上。

如果，你编程是为了挑战难度，好吧，你更是应该看看《人月神话》和《人件》了，在这两本书里，都提到了技术并不是最难的，什么比技术更难？这两本书里也有答案，还是各位看官自己从里面找答案吧，找到了之后，你在去挑战这个比技术更难的事情。会让你更有成就感的。

程序员们，美好的生活就在身边，升职的机会也就在身边，只不过，需要你们暂时放下手中的技术，走出去看看。

另外就是，把上网聊天的时间用在身边朋友的身上吧，更应该把这个时间放在自己的女朋友身上。（2004年 10月22日）

http://bbs.gameres.com/showthread.asp?threadid=1749

Re: 痛定思痛.......大规模游戏的设计

大规模软件开发，如同在焦油坑中垂死挣扎．软件开发虽然可以给人很大的创造力和想象力，但这是一条曲折之路．经验告诉我，一个和谐统一的架构是从血与泪中锻造出来的．看看Brooks博士的＜＜人月神话＞＞，他能给你很多启发，在某种程度上他也解脱了我被束缚的心灵．

http://noslopforever.blogchina.com/blog/rss.php?blogId=29875&profile=atom

如果有人想学炮轰韩寒的那位老师那样，做好了准备对"我曾说过"四个字大加批判的话，我只能说"有人曾说"："人总是在创造未来的同时创造历史，人总是在歪曲历史的同时歪曲未来，即便认识到这一点也无济于事"。让我想想，《人月神话》中好像也有一句"无济于事"："项目总会超期，即便认识到这一点也无济于事"，虽然这句话被骂得不行，但是事实是大部分项目都是在超期的基础上完成的。

http://www.msnspaces.net/members/beloved/feed.rss

我今天去预定了下周二回北京的票，出差都一个多月了。感觉已经疲惫到了极点，没有心情继续工作下去了。《人月神话》中说的那样，如果程序员过于疲惫的去工作的话必然会导致编写的程序漏洞百出，工作效率低下，所以应该只在不得以的时候才考虑进行加班。可是很少有管理人员意识到这一点，在原来做计划的时候，计划的时间不够，最终只有采用加班加点的方式进行赶工，而这样的结果必然是程序bug百出。维护成本极高。

http://libnetnt.cosoft.org.cn/linglei/archives/000275.html

想当年，在黑客是建设而不是破坏的那个时期，黑客就意味着突破一切不可能到可能。黑客们走在程序语言和逻辑的平衡木上，创造了GNU、Linux、Emacs、Perl，影响了一代人。黑客的精神是一种古典精神。布鲁克斯的《人月神话》里认为，黑客行为提供了五种乐趣：创建事物的快乐；开发对他人有用的东西的乐趣；将零部件组装在一起，看到它们以精妙的方式运行的乐趣；面对不重复的任务，不断学习的乐趣；工作在单纯的思考中，工作在如此易于驾驭的介质上的乐趣。简而言之，黑客享受着造物主的快乐。它聆听着天籁之音，为存在本身构造着对象。

http://ymvivian.blogone.net/

培训第二天

昨天还信誓旦旦要好好听讲,结果今天带了一本书去,结果就可想而知了.

这本书叫<人件>,是一本很畅销的讲管理的书,放在我书柜里好久了,一直都没有机会看,结果今天培训的主要内容成了这本书的阅读过程,不过,我收获良多.

(一本厚厚的书,我居然马不停蹄的在一天之内看完了,连我自己都觉得惊讶-看来阅读并非难事,难的只是没有时间和决心.)

和这本书齐名的还有一本,叫<人月神话>,那本注重于软件开发的过程和控制,而这本则关注从事这项工作的人-光从内容上,我更倾向于后者,因为凡事我都喜欢从人的角度出发,更关心人的生存环境和思维模式.

在听课的过程中,惭愧的很,老师的话只当耳旁风,倒是读到有意思的观点时想大笑起来,或是击节赞赏.那是种被认同或者被理解的痛快淋漓.

http://blog.jxppp.com/rss2.php

其实我也一样。我每天只有两三个小时的高效时间。看着别人那么卖力的干，还有点不好意思。不过呢，我总是组里出活最多。由此可见，“人件理论”和极限编程都坚持不加班，每周只干40小时，还是有点道理的。他们都清楚这么做不会降低一个小组的生产能力。

每天只能干两小时还没让我太担心，真让我担心的是完全干不了活的那些天。

http://reallike.mblogger.cn/

买了五本《人件》，自己留一本，送给四个头一人一本。

http://blog.joycode.com/5drush/archive/2004/01/08/11027.aspx

我记得李维的〈Borland传奇〉中有段〈人件〉的作者对于微软的评价，很是经典。对于为什么那么多人瞧不起微软，他只引用用当时IBM做PC行业龙头老大时，被人控诉垄断。IBM最后胜诉，理由是， IT行业不象传统行业，它是一个充满风险和竞争的行业。任何小企业随时都可以发达，任何大企业随时都可以倒闭。而在这个充满风险和竞争的行业里，微软居然还能做十几年的，而且越做越好，不得不让人敬佩。

http://spaces.msn.com/members/alinnb/

12月11日加班之另类心情

今天加班，整个公司就两个人，很安静，气氛很好，没有平常的压抑感（画外音 boss：平常压抑吗？你自己的心理问题吧 ）。静静地坐在电脑面前，头脑无比地轻松，思维特别敏捷，工作效率也特别地高，让我感到原来加班也是一种享受啊。

前阵子看到国外作者出的一本书，中文叫《人件》，名字还真是有趣，应该是从software和hardware改的吧 。其实是一本关于项目管理的书籍，探讨软件开发中关于人以及团队的管理。里面提到了一个公司应该给员工足够好的工作环境，包括技术低迷期不解雇员工；维系同事间的友谊；把“看得见风景”的窗口留给员工；允许员工调换岗位；不限制员工的办公地点和时间；帮助员工在家里安装宽带；员工平均每年参加6个培训班等等。看到这些，就不仅为这些国外的公司所折服，呆在这样的公司里，员工是无论如何也不会感到工作的压力，在他们看来，工作就是一种享受，所以，还有什么理由离开这个公司呢？

要想所有的公司都做到这些无疑是困难的，但是如果公司能够尽自己的努力给员工更好的环境，让员工感受到工作的乐趣，这就已经足够了。庆幸的是，我现在就有这种感觉 ，我只想说：我要更加努力的工作！

http://veijerd.mblogger.cn/posts/5149.aspx

项目估计是进度延迟，老板和师兄们心情都不好，已经连续2天开会了，明天还要开会。据说老板曰“项目你们拖着，毕业就拖着”，唉~~~师姐的意思好象是 “拖着就拖着”，有什么办法，做这种项目，需求总是在变，企业那边简直就是他们说“加这个字段”，你就要加这个字段。唉~~要不人家说做产品好呢。以后我得总结一下为什么陷入泥潭的因素。

以后我们也要朝九晚五了，郁闷~~~你这样可以，但你怎么发钱呢？有没有奖励的机制？做的多了是不是给钱多？给多少钱？等这个学期结束了，偶要问老板，银子以后怎么给法。偶不愿意去做parttime，可偶还有自己的负担，如果实验室里解决不了的话，偶不会去理会什么朝九晚五。老板也该去读读“人件”哈。