调测中的反思

# 作者：水煮鱼
时间：2008-2-14 夜
版权申明：本文为水煮鱼为 水煮鱼@博客园 撰写，不得用于商业用途，如需摘用，请与水煮鱼联系。

最近几个周，一直在进行调试。因此回家一直都比较晚，繁重的调试任务，也让自己暂时放弃了思考。但今天却让自己觉得对于如此宝贵的财富，不记录下来，也许我永远也不会得到成长...

在正常的CMM项目中,测试包括了UT/IT/ST/BBIT/SDV/SIT/SVT/BETA等,目前项目运作仍然处于ST前的单模块调测阶段.
由于本次负责的模块进行全新的重开发,因此该阶段的调试任务显得尤其繁重.
在调测之前,调测任务已经进行有效的分解,基本的原则是由简入繁,由浅入深,稳扎稳打,步步为营. 从年前调测算起,正式的投入的到本模块的功能性调测已经基本有半个月左右,目前进展基本与原来计划相符合.功能性调测基本完成了65%左右.

在调测中的时间耗费分布如下:
------------------------------
总耗时间:                       100%
版本编译:                       50 %
问题定位:                       20 %
问题修改验证：                10 %
版本演进引入问题分析:       10 %
其他:                            10 %
------------------------------
有效调测时间:                  30 %

从上面的数据分析中，在调测活动中，实际上有效的时间仅仅占了总时间的3成，也就是说剩下的约7成的时间在从事着非实际有效的调测活动．以目前15工作日计算,　有效调测时间仅仅约4.5天．

也许你并不赞同我上面数据的分析, 版本编译/版本演进中引入问题分析和定位以及其他有些活动并非与调测活动无关联,相反,这些都是在调测中不得不需要完成的活动.我承认如此.因此我把调测活动本身称为实际有效调测活动,而将与调测活动关联的一些其他必要或者非必要的活动统一称为非实际有效调测活动.

下面,我们将分别针对该两类活动来探讨如何更加有效的提高我们的调测效率.

实际有效的调测活动主要包括了问题定位和问题修改验证.从表面看似乎遇到问题,定位和验证是无法避免的.因此该活动时间似乎也没有可以节减的空间.但是深入分析问题的根源, 就可以很容易找到提高调测效率的有效方法. 以目前我所从事的调测活动中,所以遇到的问题主要分布如下:
-------------------------------
所有问题:                       100%
COPY引入问题:                60 %
笔误:                            35 %
功能性问题:                    5   %
-------------------------------
低级错误:                       95 %

在调测前,一般需要进行UT和REVIEW.对于低级错误,一般充分的UT和REVIEW活动可以完全发现.而在所有的调测问题中,低级错误占了95%, 从调测过程来看,也说明了该问题: 越是充分UT和REVIEW的代码,调测过程所遇到的阻力越小.以曾经的一个低级错误为例:如果REVIEW,可能花费的时间代价约30分钟,但是调测中为了解决该问题,则花去了约一天的时间.从发现问题的效率比较来看,可以作如下的排序:
调测 << UT < REVIEW(他人) < REVIEW(本人)
因此在调测前安排充分的UT和REVIEW是必不可少的，也是提高最终调测效率的很好手段。

非实际有效的调测活动主要包括了版本编译/版本演进引入问题的分析和定位/其他一些活动。
版本编译和调测实际上是并行的活动，我想地球人都知道。但是在实际的调测中：你的代码如何做到让版本编译和调测过程足够并行呢？这却决于良好的软件架构设计。如果你在架构设计中，做到了子模块间功能的独立和低依赖性，也就是常说的高内聚，低耦合，同时在设计之初，能考虑更多的容错性设计(比如一些错误情况的替代模块，通过替代模块，可以对一些出错模块进行规避性替代，从而不影响到对其他子模块的功能调测)。好的设计，可以充分保证在改错后的版本编译与实际有效的调测活动可以并行开展。
版本编译还有一个最直接和最有效的手段就是采用功能更加强大的电脑和编译工具。目前公司内部大力推广的分布式编译就是属于后者。
版本演进中引入问题的分析定位时间的节俭主要依赖于严格的版本发布机制。一般一个新的版本的发布经历如下的阶段：
代码问题修改->问题验证->合入->主线验证->其他基本功能验证->发布
严格执行上述的流程将可以将调测中版本演进引入的时间耗费完全杜绝。版本演进过程最好尽量平滑，严格控制每次版本合入问题的解决数是一个很好的手段。
最后一个其他活动主要看个人的时间管理习惯而言。但在调测阶段，尽量采用优先与调测活动强相关活动的时间管理策略。

------------------
总结：在上面的分析中，我们其实都忽略了一个基本的东西：项目管理的理性和合理性。
项目管理的理性是指：充分认识到项目管理中对流程的严格执行的重要性。一些冒进的做法，看似在与进度抢时间，殊不知其实已经对进度拖了后腿。以本次项目中之前的调测过程为例：未经过UT和REVIEW的代码，直接进行调测，最终获得的是惨痛的教训。
项目管理的合理性则是指：在理性的制定项目计划中，提供可行的项目计划方案。
同样本次项目中最初计划存在不合理性也在于(就本模块而言)：15K的代码量(完全新写),
初始计划：15工作日, 整个项目周期中，工作量为170行/日
修正计划：40工作日，整个项目周期中，工作量为100行/日
尽管修正计划的工作量仍然大大高于了公司的基线值(30行/日), 但至少相比于第一个计划，还稍具可行性．

如果按照理想的情况下：根据上述总总的调测效率提升手段后，目前15天的调测时间将缩减为15*6.5% = 1天．

PS:今天情人节，定了99多玫瑰确是送给朋友的老婆...无奈..........