大数定理，从功能规模到到人天

陈勇-创业-北京(139107533) 13:40:22
@听说：好，下面就说说这个甚早期估算的用法。
先说说为什么不让资深人员在甚早期做估算？原因是资深人员都是技术专家而非业务专家，所以如果能知道业务是什么并精确描述，这个人估算很准的，可惜做不到业务精确描述。
所以，不得不回到一个现实一点的状态：如果信息很有限，怎么估算？
那么，这个估算可以直接用吗？不行的。刚才说过，有很多问题影响估算。
 

一个是再多一个故事，显然就会更多。
二个是：如果里边的功能比“看上去多”（就是Lastwinner说的），也会影响。
三个是：如果这个产品有很强的质量要求。
四个是……

问题一，解决了（后面还会复活），反正你列出来，我就能数清楚。
问题二：就是Lastwinner的问题，难度问题，很难解决，但是有大数定理在。
 

大数定理，就是说数据多了，个别太难和太容易的故事，就是小误差了。
 

听说-码农-SH<**j90@hotmail.com> 13:43:55
为什么不能培养出 技术和业务都比较熟悉的人？ 做应用这边技术专家应该懂业务的，不然很难做， 这里的技术应该是广义的
 

陈勇-创业-北京(**9107533) 13:43:58
早上不留神看了一眼CSDN博客排行榜
这个是周排行：

这个是月排行：

听说-码农-SH<**j90@hotmail.com> 13:44:42
信息一般都不可能100%完善的，在不完善的信息下做出分析和决策是资深人员应该有的一种能力

陈勇-创业-北京(139107533) 13:44:58
发现没有，浏览量中，月排行严重地不等于周排行×4
好像乘以7还差不多。
但是，这个是年排行：

仔细注意 月×12 = 年！

从第一，到第十，几乎都满足，误差可能只有10%。
 


陈勇-创业-北京(**9107533) 13:47:22
这个就是大数定理，如果一个产品包含300个用户故事（比如我们的产品就这么多，才1人年），那么基本上可以不讨论个别问题的难度，而直接上。
三个是：如果这个产品有很强的质量要求。这个怎么办？


听说-码农-SH<**j90@hotmail.com> 13:48:02
我有一些疑问， 有一些项目明显难度比另外一些项目来的高的
例如说 依赖很多外部接口
或者很多研究性项目
 

陈勇-创业-北京(**9107533) 13:48:23
@听说：对，正说你这个话题，就是问题三
还好，人们研究了其他影响的因素，发现有三样东西还影响FP和人天的对应关系
1. 应用类型（比如OA和高铁控制相差很大）
2. 规模（越大越慢或越快，最近世界的统计是：越大越快！）
3. 质量和其他特性要求。
研究这个最彻底的，是韩国。
 

韩国说，3大约会导致不到10%的误差，这里就不提了。
2呢，是个非线性曲线，但拟合程度很烂，大家先按线性计算吧。除了很小或很大，误差不大。
1是重点。
韩国把应用类型分为若干种（大约不到50种），又归了几个大类，大致如下：
陈勇-创业-北京(139107533) 13:51:52
1. 选择 OA / MIS类作为最简单的，可以认为1 FP = 9小时（中国）
2. 简单的科学计算类的 再×1.3～1.4
3. 实时系统监控类的 × 1.7
4. 指挥管控类的 ×２.０～２.２
这个大类是我会议的，具体请参考年底的国标。
 

陈勇-创业-北京(**9107533) 13:54:05
３和４的区别：３基本上是生产线、ATM、ERP这类东西；４则是地铁、武器系统、航空管控。
 

lastwinner(**810932) 13:54:37
啥会议？是某个敏捷大会么？
Tom-Cat(**963589) 13:54:40
这样的估算方法呢：如果1个FP计划需要10 人·日，实际上用了20 人·日，则很可能未来的几个FP也是 20 人·日 的进度。当然要考虑到后期的学习效应。

陈勇-创业-北京(**9107533) 13:55:16
所以火星人刚才那个功能就是：４２×１（算MIS）　×９　＝　４００人小时＝１０周，两个半月。
当然有人会问：要吗？我怎么看这几个功能，很快就能完成呢？
这就涉及到这个时间算到什么时候为止。
一般咱们敏捷估算，只计算从需求描述好了（用户故事写好了）到集成测试之前，这个只能算大约５０％的时间
而FP的统计时间，则从合同签订后，一直忙到上线验收。所以比我们的感觉要多一些。