从天气预报来看软件开发的估算

作者：张克强

在敏捷软件开发估算相关材料、培训和交流中，常常见到听到“昨日天气”这个说法。我一直不是特别理解 敏捷里提出“昨日天气”是出于什么目的。

可能的目的有：

1，昨日天气情况很容易观测，拿来推断今日天气，很是方便。

2，根据昨日天气来推测今日天气，对于普通人来说，错误率极高，所以这个方法效果不好，所以记录昨日天气的效果不好。

这两个目的是矛盾的。

长期的困扰在敏捷中国大会被听众提问时，我貌似有所悟。当时的问题的大意是“有领导担心 如果从CMMI转向敏捷，估算会不准确，怎么办”？

首先这个问题的表面是有歧义的。他所说的“从CMMI转向敏捷”是指原来在CMMI推进下建立的相应方法转变到敏捷软件开发下推荐的相应方法。

当时我回答的大意是基于CMMI4开展的估算的精确度是高于一般的敏捷开发的估算，而达到CMMI3所开展估算的精确度恐怕还比不上采用燃尽图。

第2天，我继续思考了这个问题，将昨日天气的疑惑代入，得到了如下的文字。

天气预报的7重境界
1，像我一样的普通人，能够在夏天看到乌云盖天时预报雷阵雨。
2，经验丰富的老农，多年经验让他能够通过观察云朵、风向、太阳、月亮、星星来判断第2天的天气。
3，气象爱好者团体，比如多位在一起交流的气象爱好者或者经验丰富的老农 
4，县级气象台  开展本地气象记录，预报本县天气，气象台技术人员数量不超过10个。
5，省级气象台
6，国家级气象台，拥有卫星、超级计算机
7，全球顶尖气象台，拥有覆盖全球的天气观测和15天预报能力

关于软件工程中规模和工作量的估算
规模是指软件工作的大小，一般有两类表示法：1类是诸如代码行数、功能点数等等，另1类是直接采用工作量。
工作量一般也分两类：1类是全部工作量，另1类是理想工作量， 理想工作量与全部工作量存在数学关系， capacity = 理想工作量/全部工作量 。

常见的估算方法有如下，说明：以下方法并不是孤立使用的，不少地方是组合使用的，为了方便叙述，就罗列在下面了。
1，个人凭经验估计，俗称拍脑袋，据说此方法的误差范围是1/4~4。
2，群体凭经验，比如delphi方法，比如扑克游戏，当然扑克游戏一般也基于story point。
3，按照一定的方法，比如IFPUG，UCP(use case point)，User Story Point, Cocomo, CocomoII, NESMA，MKII等等 
4，CMMI2  上个项目的数据可以拿来作参考, 采用一些方便获得的数据。
5，CMMI3  项目数据被组织采集，组织经分析后提供一些估算的参数，估算的结果一般带有中值和上下限。规模表达的方法要求得到定义。
6，CMMI4  收集大量数据，通过统计学分析得到过程绩效模型和能力基线，里面几乎必然用到了数学建模方法，典型的给出带有概率判断的预测。
7，Scrum中利用理想人天或理想工时估计
8，Scrum中利用Story Point的估计  
9，CMMI5 在CMMI4的基础上，能够对主动变化进行可控制、可预期的估算，类比到气象的话，就是通过计算分析进行人工降雨或驱雨，选择合适的气象条件，在适当的位置释放适量的、适当的材料，让雨能如预期的来或者不来。


根据大量数据、进行数学建模得到的估算的偏差比例一般来说是小于简单方法的。但如果估算的对象本身是很大的话，那么小偏差比例会被放大，所谓“差之毫厘，谬以千里”。
敏捷对估算是拥有天然优势的，就是在于短迭代和小团队，在小团队短迭代的情况下，估算对象本身不大，误差会及时发现，在下个迭代中有机会去调整。
换句话说，在敏捷小团队短迭代下，偏差比例就算大一些，绝对的偏差并不大。也就意味着，在敏捷环境下，不必使用高精度偏差比例很小的估算方法。

对照到天气预报的7重境界，我把真正满足CMMI4类比到国家级气象台，CMMI2也就在县级，CMMI3在县级到省级之间，一般的敏捷估算放在气象爱好者团体级别到县级到省级之间。

通过分析天气预报的七重境界，发现“昨日天气”很不简单，复杂度不必软件估算低。敏捷估算中拿“昨日天气”来做隐喻，如果是整体全面考虑，真的是很恰当。

但如果是把昨日天气对比为“把上几个迭代完成的故事点数的平均值作为当前迭代的估算”，那么也许就是用错了，这带给我长达3年的困惑。

 

------

本文欢迎全文转载，转载请注明作者和链接