如何做最有效的敏捷版本度量？ 第1页

谢邀！

这个话题有点大，一般的公司到目前来说很多数据都是不全的，所以，真实的度量无法推进，国内大部分包括cmmi4级以上的公司的度量，我只能客气的说很多都是假的，杜撰的。

从你提到的几个点分别先说一下：

ucp：应该是use case point的缩写吧？其实从uc来说，连ivar都没有较好的度量方法，所以，依靠ucp的度量基本上是没有什么依据的。

2000年底我问过rational加拿大的咨询师，一个项目多少个uc比较合适，答复是大约40-50个。

2004年底我第一次见到ivar也询问了类似的问题，答案同样是40-50个。

可是，实际上呢？项目的大小规模各不相同，如果我把一个城市作为一个项目来看待，每一个区级汇总事务差不多就要定义为一个UC，否则就会超出40-50个的范畴，而如果把一个区里的某个大楼作为项目，那估计可以细化到具体的门窗的工程实现作为uc了。这个类比也许不够精确，但是足够说明问题。

后来在我的时间中正式提出了元用例的概念，并提出了通过元用例的组合来定义uc大小的方式来确定uc，然后衡量项目的uc数量，这样才是比较客观的。这个方法在我那本书的2010年版本中已经有较为详细的说明，去年在武汉大学珞珈山庄举行的亚太区需求工程论坛上我做了一个专题，名字是：需求工程中的量化问题研究，首次在学术论坛上正式提出了这个概念和初始的操作方法，目前在我所在的公司推动着基础数据的积累。

工作量：这个词比较麻烦，工作量用什么计算，单说这个词是无法描述的，时间，人月（人月神话已经被无数次证明是无效的）等等方法，所以，有效的工作量描述一定应该是基于可计算的数值基础的，这里至少目前世界上对于抽象化脑力劳动是没有有效的工作量度量方法的。

但是初步的度量方法是存在的，可以看一下钱岭（五哥）翻译《软件度量》那本书，算是介绍的很完善了。

投入人数：这个容易计算，但是也会有问题，比如中途加人，中途撤人，是否在项目中的人做的都是这个项目的事情，这都需要很细的计量方法。

目前我在公司里面推动的是我构建的项目助理协助管理方法。

程序员只需要做代码和代码相关的文档，项目助理在每天早会的时候记录工作量和工作计划，然后对比验证区别，这里先不详细说了，展开也是很多的内容。

代码行：关于代码行，计算起来容易，但只能作为一个侧面的工作量评估数值，因为最核心的代码可能只有几十行，其付出却会是其他上前行代码都无法比的创造性工作。

解决Bug：这个用好bug管理工具就可以，上面都能获取到这些数据信息。我从前一家公司开始就已经开始采用我过去构建完成的一套bug统计分析的表格模板，帮助分析代码质量问题，实现项目质量的数据化管理模式。

回归Bug周期：同上。

一次性修复率：同上。

改动引发：这个是需求管理工具引发的，用好，也不难获得结果数，但是到底有多少价值就需要思考了，绝不是简单的家见问题。

合入引发的问题数：这个说的是merge吧？如果是，那这个是配置管理工具的实现，但是同时也涉及到你的架构设计的结果，一个好的架构设计可以完全避免merge所带来的问题，也可以通过版本的分支控制和代码内的方法实现细节架构形态来解决这个可能引发的问题，这是我在2002年完整实现的一套代码结构方式。

先说这么多吧，有问题我再补充。