工作量评估方法

领导给你一个开源项目，让你调研之后用另一种技术来实现其一模一样的功能...

更难的是，这个开源项目没有任何文档，只能自己去网上搜相关资料...

定目标、搭班子、带队伍！

目标，有了；
班子，加上我总共三个人；
带队伍，领导觉得需要一个计划！

这个计划怎么做？没有参考，对这个开源项目也不了解...

慌得一批！

网上一查：

基于WBS的工作量估算方法，是最常见的一种估算方法，也是厂商最常用的。基于WBS的工作量的估算方法，又称为由底向上法（自下而上法），通常的需要寻找类似的历史项目。

没有类似的历史项目，不要！

基于代码行（SLOC）的工作量估算，是从开发者的技术角度出发来度量软件。代码行数是软件开发者最早进行规模测量的主要方法。进行工作量估算时，先采用WBS法、类比法等统计出软件项目的代码行数，然后将代码行数转换为人天数。

这个听着靠谱，代码行数我们很容易就可以得到。

接下来，需要构建一个我们自己的将代码行（SLOC）转换成人天数的模型，因为网上的，不太适合我们，但他们的思想可以借鉴：

找到影响工作量的因子，然后数学近似化。

影响工作量的因子都有哪些？

代码行数是肯定的了。那么，是统计好整个开源项目的代码行数，然后代入公式计算？还是统计好一个文件的代码行数就计算？

显然，逐文件的统计粒度更小，所以会更加准确。

除了代码行数，技术状态和复杂程度都应该考虑在内。

技术状态，是说妨碍开发进展的限制，比如技术储备、机器性能等；
复杂程度，是说同样行数的代码，有的要复杂，有的要简单。

记代码行数为\(L\)，技术状态系数为\(T\)，复杂程度系数为\(C\)，工作量为\(W\)（单位人天），则

\(W=L*T*S\)

需要注意的是，这个W是某一个文件的。工作总量是所有文件的W累加的结果。

显然，给每个文件预估一个技术状态系数\(T\)和复杂程度系数\(C\)，费时费力。何不给某一个大的模块预估一个整体的就好，这个模块下面的所有文件都用该平均的\(T\)和\(C\)。