从估算谈到软件工程的本质

估算的应用

估算是软件开发团队的日常工作，几乎每个人都会涉及各种估算，程序员要对任务进行估算，项目经理或者架构师要对项目或者方案进行估算。这是因为估算是软件开发过程中的一个核心概念，它是所有计划与管理的基础。比如我们需要估算一个项目的投入与回报来确定是否值得启动这个项目；我们会依据估算来确定项目的交付或者上线日期，并把这个大的目标分解为很多阶段性的控制点，并以此作为项目计划和日常管理与监控的依据。

 

追求估算的准确性

基于这些原因，很多人相信并致力于追求估算的准确性，业界也相应的创造应用各种估算的方法和模型，比如：专家判断、类比估算、参数估算、自下而上估算、三点估算等等。最常见的是依靠资深人士比如架构师、项目经理、技术主管的个人经验和能力，甚至结合公司内外可以参考的各种“类似”的数据或者标准来进行估算。

 

估算成为度量、管理和考核的标准

追求估算的准确性本身好像无可厚非，但是一旦得到这个神奇的数字后，往往就成为了各种度量、管理和考核的基准。我至今还记忆犹新，第一次做PM的时候，每两周就要向领导做项目汇报，如果基于挣值分析出现进度或者成本的偏差超过了基于估算的控制线的时候，就犹如过堂，必须有个交代。因为估算是“准确”的，所以如果在执行过程中的实际进度与依据估算所做的计划有偏差，一定是执行的人或者团队出现了问题。

 

遇到这种情况，我们往往会惶惶不安的自我检讨：是不是我们开发人员的能力没有达到要求？是不是我们的开发团队不够努力？为什么我们没有预见到影响我们工作的各种依赖，是不是我们的风险管理没有做好，是不是我们的contingency 留的不够？我们也可能会把问题归咎于自己的估算能力，为什么我们的估算不准确？当然，我们也很擅长找别人的问题，比如，因为需求不清楚，所以我们花了很多的时间去澄清需求；这个问题是一个新需求，而不是一个Bug；因为UX/UI设计交付延迟，所以导致我们的工作滞后。无论什么样的解释，我们最终几乎都无法避免加班加人这个软件开发的魔咒。即使一些做“敏捷”的团队，仍然受困于估算。我自己就遇到过这些情况：有Manager或者PO要求度量每个Sprint的完成情况，甚至比较各个团队之间的Velocity；有的Manager或者PO要求团队提高Velocity以便达到Release Date的目标。

 

估算，就这样成为了管理者和客户的利器，也成为了套在开发团队头上的枷锁。开发团队为求保险，往往会放大估算，而管理者和客户又自然会压缩估算，这就成了双方对估算的博弈。

 

敏捷中的估算

敏捷产生于应对软件开发过程中的各种不确定性，认为估算只能是就目前已知的情况对开发活动进行一个大致的预测，而且估算一定是整个团队的集体活动，而不是某个专家的个体行为。即使使用Planning Poker进行估算，也并不是为了追求估算的准确性，而主要是为了激发团队对Story的集体讨论。既然各种不确定性不可能体现在估算里面，那么估算也就不应该成为度量和考核的标准。比如，在Scope确定的情况下，Release Date一定是一个可以变动的范围；在一个Sprint中，如果有Story没有完成，也是正常的现象，当然团队可以在Retrospective活动中对此进行讨论，看看是否有提高和改进的可能；团队成员对某个具体任务的估计，也是其对完成这个任务的一个大致的估计，而不会是衡量其工作的依据。有些敏捷团队认为估算是一种浪费，主张把Story分解为大体相当的尺寸而节省估算的时间，有的甚至干脆就不做估算。也许要准确的做估算，就只能是把这个Story做一遍。

 

软件开发活动的本质

为什么传统软件开发管理和敏捷对估算是不同的态度呢？这是因为它们对软件开发活动的认识有根本的区别。传统软件开发管理的思想认为，软件开发活动是可以进行预测和计划的，只要专家（项目经理，架构师，资深程序员）做好估算和计划，团队成员严格遵守来源于“最佳实践”的开发和质量管理流程，就可以复制项目的成功，其本质上是受到泰勒的科学管理的影响。敏捷则更强调软件开发的不确定性，应对的办法就是信任并授权团队，从侧重预测转变为侧重调整适应的能力，以小步迭代增量的方式来寻求各种反馈以修正前进的方向。

 

那么软件开发活动的本质到底是哪一种呢？这当然是仁者见仁，智者见智。下面以一个简单的例子来讨论。假设，我们需要在下班的高峰期，从西安软件园零壹广场，开车到市中心吃饭。那么从开车出发开始，每一时刻我们都需要眼观六路，耳听八方，获得各种信息，同时手脚并用，修正我们的车速与方向；而每到一个路口的时候，我们都需要对前方的路况做出判断，重新实时规划路径。其实任何一个有经验的老司机也不能事先准确的预测出我们需要花多少时间才能够到达目的地，我们事先只能大概估计可能需要花40-60分钟左右到达。开车尚且如此，软件开发呢？