软件规模度量的功能点分析法

度量的难度不在于实施，而在于定义标准。
所以量化管理才这么困难

好比罗那尔多，上一场穿粉红球靴，进球了，下一场比赛的时候，罗拿多也会再穿上粉红球靴，这叫心理暗示，给自己下一场进球找一个理由。而软件规模度量的，也类似于寻找这样一个理由，或者暗示，让pm和老板们心里有一些慰藉──“起码我是有依据的”。

不能象建筑一样用长宽高来度量，成为软件从业人员心中永远的痛，于是通过LOC,通过Feature points来进行“毛咕咕”的度量，当然，这种度量永远带有不确定性，所以有了争吵。

但没有pm在投标的时候不去做这样的一个“毛估估”，无论是在脑子里间或一轮还是利用微软的计算器运算抑或是打开一个excel表格输入几个数据最后得出结果或者有一套super的系统专门来分析。

问题不在于毛估估，而在于毛估估的方法，如让一个没有完整做过项目的人毛估估一下肯定相差十万八千里，印度阿三的大型外包软件公司通常都有历史项目数据库，细分到功能点，当手头有一个近似的项目时，阿三们就可以把数据调出来做参考，那么当数据积累越来越多的时候，当然毛估估的质量也越来越高──但这些都需要积累专业和成本！！！

也有人用代码经济学的思路去搞，比如加一些权重因子进去，也有老外专门搞了程序出来，通常你把数据如是敲进去后得出的结果却令你异常失望，比如你发现老毛子们是用美刀算的，你却用rmb，而且工钱还践得要死，四个字──极不靠普，你想自己编一个吧，但是好像中国人又不太喜欢造汽车轮子。代码行数有个极其伪善的面孔，比如ruby们经常吹虚的代码行数能让java们嫉妒得发狂，你用以个java的代码经济软件来跑ruby项目你要吐血。

所以还是拿个现成的东西毛估估把，回到前面，找一个理由让自己或者老板踏实一下,但是别太当真。