利用功能点数据对业务数据和业务操作进行早期快速估算
陈勇-创业-北京(**9107533) 13:25:06
好，暂停一下，看大家有没有什么问题？
中惠 李-GZ(**215419) 13:26:17
你所描述的业务数据，可能需要加以区分
陈勇-创业-北京(**9107533) 13:26:36
比如？
中惠 李-GZ(**215419) 13:26:44
哪些是基于系统才产生的业务数据，哪些是基于企业业态所产生的业务数据
chuner_wang-PMO-BJ(**580305) 13:26:46
我是外行啊，这种描述用户故事的结构，是火星人的规矩，还是敏捷的规矩？
lastwinner(**810932) 13:27:01
暂无，就是把“临时加工”看成“临时工”了。
不过，用户和权限的逻辑关系设计，会在哪里体现呢？
陈勇-创业-北京(**9107533) 13:27:09
呵呵，是FPA和火星人的规矩，敏捷“没规矩”。
敏捷开发组织代(**963589) 13:27:21
这些故事，如何确定工作量的？
chuner_wang-PMO-BJ(**580305) 13:28:10
同TOM问，描述一个故事的时候，是否要考虑必须在多长时间内能完成，记得敏捷，是以天为单位出成果的吧？
陈勇-创业-北京(**9107533) 13:28:13
@chuner：待会会说说，这个规矩的好处，以及哪些企业可能最容易从中受益。
chuner_wang-PMO-BJ(**580305) 13:28:37
嗯，我觉得这个规矩很好，至少，加速了我对用户故事的理解
陈勇-创业-北京(**9107533) 13:28:56
好，下面说说“工作量”的问题。
说到估算，其实有很多环境需要估算。
敏捷里边说的最多的，是大约每月一次的计划会上的估算，具体形式可以是“扑克牌估算”。
lastwinner(**810932) 13:30:07
工作量和我提的“用户和权限的逻辑关系设计”非常相关。比如不可以给用户组授权和可以给用户组授权，工作量就有比较大的差别
陈勇-创业-北京(**9107533) 13:30:07
敏捷估算，是开发人员“夺权”的一部分内容
但是这个权利，经常无法得到授予，原因是老板提前就答应了客户另外一个时间表，所以，你们的估算……我尊重，但不遵守……
这就使得如果要想能真的自组织地做估算，那么远在立项（无论产品研发还是项目开发）之时，就能为老板提供一个大致的估算出来，日后就主动了。
@Laswinner：恩，后面有答案。
陈勇-创业-北京(**9107533) 13:32:17
当然下一个问题是：在项目的甚早期，我们手里有什么可以用来估算的内容呢？
在计划会上，我们是有用户故事的，可以讨论，可以比划一下。在甚早期有什么？
FPA发现，一般而言，在甚早期有两样东西：文件，操作。正好就是我们刚才提到的内容。
比如老板指着上面这个表问：开发这些东西要多久？（我们只看用户和下面的几个功能）
这时候有几样东西影响工作量。
一个是再多一个故事，显然就会更多。
二个是：如果里边的功能比“看上去多”（就是Lastwinner说的），也会影响。
三个是：如果这个产品有很强的质量要求。
四个是……
越想越多，就想不完了，还好，统计学家已经替我们完成了一些积累工作。
FPA的历史统计数据发现（大约有3000+6000+20000 + 其他几个未知的数据，但都很接近）
每个文件（比如用户 Users），是10个功能点（具体数字下面再说），每个操作（编辑，分配，查看……），是4～5个
这样用户下面我们数一下：10+4×8 = 32个。
（注意“用户首页”是“查看用户首页”的意思，这个用词后面讲MVC的时候会讲到，是我的一个遗留问题）
32个FP（Function Point，功能点，有点类似故事点）
32个FP=？人天 是个问题。
lastwinner(**810932) 13:38:41
10+4×8 = 42个
陈勇-创业-北京(**9107533) 13:39:11
不过，还是有历史数据。澳大利亚公布的156个政府项目计算的结果，1FP = 13小时。
呵呵，对，是42个，把10漏了。
听说-码农-SH<xwj90@hotmail.com> 13:39:23
这个不能直接套用把
不同项目的难度 团队 都不一样
应该是团队里面资深人员来估计出工作量？
lastwinner(**810932) 13:39:48
统计数据是可以参考的，初期只能简单套用
陈勇-创业-北京(**9107533) 13:39:51
中国也统计过一些数据，大致是1FP = 9小时，所以42FP～50人天吧。
