《QUML：量化需求分析与建模》节选之三：一个量化管理项目的一生（2）

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。

电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 

第一个月

从用例到用户故事，从用户故事到代码

在敏捷计划会上——是的，他们采用敏捷开发，确切说是Scrum——产品经理正在给开发人员讲解需求。

他并不是空手来的，而是带来了几张图，比如下面这张收发货子系统中的“结帐记录”的“用例-流程图”。这是他在计划会前，会同几个客服、运维以及开发骨干讨论绘制出来的。

这张图表明对于“结帐记录”这个数据实体，共有4个不同的业务操作，也大约对应4个不同的页面——至少多数时候如此。在讲解完成整个图形及单个页面的详情之后，产品经理提醒大家，从图中的业务依赖关系来看，这4个业务操作必须同时被完成，这个功能才得以上线。

开发人员们纷纷点头，在一个名为CheckRecordsController的类里边写4个方法——Pay（付款），Details（单个详情），IndexOfShop（查看所有本店铺的支付记录），IndexOfExpress（查看所有本物流公司的收款记录）——不是一个非常艰巨的工作。

简短估算

图中的圆圈，做估算的人把他们叫做拗口的EI/EO/EQ（外部输入/外部输出/外部查询），做需求的人喜欢叫用例，做前端的人喜欢叫页面，不过在习惯了敏捷开发的开发人员眼中，他们更喜欢称之为4个用户故事。这4个用户故事组成了1个必须完整交付的史诗故事——“必须完整交付的一组故事”，这是他们给史诗故事的一个新定义。

每个故事的功能点数是4.3点，上图中共有4×4.3=17.2点；不过每个史诗故事本身要额外多计算7点，来自背后要设计数据结构、进行联合测试等工作，一共是24.2点。这比之前说的平均值35点要小一些，不过只是个例。

若干这样的图形被讲解、分析、估算完成后，500个功能点中的200个被确定在这个迭代内完成开发和测试。为什么不是500/3=167？根据经验他们知道第一个迭代应该完成较多的功能，而之后的迭代则会因为功能耦合、联合测试等原因导致生产率下降，同时也可能会出现修改和删除功能的情况。