直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。
敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故事点，在老板眼中更接近生产率绩效。
这时候就需要功能点估算。
功能点估算
由来
功能点估算是另外一个世界的事情。每100个懂敏捷的人中，可能才有1个懂CMMI；而懂CMMI的人中，可能才有100个懂功能点，而100个懂功能点的人中，也只有1个人懂敏捷……这就是三个世界，但每个世界都和敏捷世界一样热闹，一样有可操作的方法，只是互相不通信而已——结果是，每个世界都不知道别人已经早就解决了自己冥思苦想的问题。
用功能点度量软件的目的，是在早期获知软件开发的工作量，进而推算开发成本。 由于这个目的，使得它实际上是与开发工作量的相关性也最强（远远超过Delphi/代码行/故事点/用例点……多个国家的政府使用此估算采购软件，中国大约2年就后采用），而且居然和用户故事还有很好的对应关系。
功能点本身很复杂，大家可以在网上查到一些资料，这里不多说了。标准功能点分析尤其复杂，有一次有一个欧美发包商来到中国，问“我们现在已经有100多页文档，谁看过之后知道这个项目要多少钱才能开发出来，以及为什么，我们就把这个项目给他。”笔者介入了此事，也知道标准功能点能解决这个问题，但是却不能在给定的时间内完成（只有2天的时间解决此问题，而用功能点至少需要10～15天）——国外ISBSG也转发度量Guru Capers Jones的邮件称“只有极少数的项目采用了功能点估算，因为成本太高”。这件事情促使笔者尝试找简单的功能点估计方法，直到后来在另外一个世界发现有人早就解决了大约10年了……那就是NESMA的简化功能点，如果不嫌麻烦请参阅http://www.nesma.nl/section/fpa/（点击左边 Advanced 下面的 Early&Fast FPA）。
不过建议直接看下面。下面的概念作了很大的调整以便于用有限的文字理解，如果有懂FPA的读者看出破绽不要奇怪（本人是正规做FPA培训和研究的）。
什么是简化的功能点估算
在我们的开发工作中一共有两类东西要开发，一种是数据，一种是操作。
所谓数据，就是比如要编写一个CRM，其中有“用户、角色、权限”这三种东西，就是要管理的数据，这里权且记下用户有“3个数据”要管理。
所谓操作，就是对用户，应该有增、删、改、查、加入角色……这些称之为操作，这里权且记下对用户，用户会做“5个操作”。
倘若角色和权限没有操作（虽然这是不可能的），那么在NESMA简化方法中由于每个数据是7点，而每个操作是4点左右，那么就可以算出来一共有：
3 × 7 + 5 × 4 = 21 + 20 = 41点。
ISBSG/IFPUG包括中国的CSBSG等都有不同行业/不同类型软件的生产率统计，如果你在中国，用C#或Java开发一个类似OA/CRM这样的业务流转软件，那么生产率大约是9小时/功能点（来自于10多个学员的课后数据），也就是上面那个小软件，要用9×41 = 369小时大约是46人天。
“什么？这点内容我不到一星期就能做完。”是，也不是。这一时间的包含了需求分析/设计/编码/测试/集成/上线部署期间的所有时间，还包括开会讨论的时间，和别的功能联调的时间，培训的时间，修改万恶的Bug的时间，提升性能的时间，改善易用性的时间，上网找图标的时间，上班看博客的时间——总之一个真实项目中可能发生的时间全都平摊在这里。
听起来够简单了，但其实还不够。
谁能拿出2页纸的需求文档（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。
怎么办？请看下文。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
