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

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

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

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

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

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

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

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

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

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

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

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

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

一、人月神话：

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行/人天的数据大致相符。

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

三、人件

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

四、最后期限

我感觉是大家在被无数个最后期限搞的精疲力竭之后，向往的一个神话，也是一个寓言。是个放松的好材料。

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

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

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

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

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

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

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

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

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

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

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

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

------------------------------------