SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 2301|回复: 3

[赏析] 流水先生新作《软件集成策略》赏析九

[复制链接]
发表于 2013-9-13 20:28:42 | 显示全部楼层 |阅读模式
第 4章   第一组旋钮:检测的力度和方法

2 f/ M; L/ _  Z1 o. n+ S( [' B
" i6 [6 Z$ p$ V$ Z" X* g- |8 \
制定集成策略,优化集成工作,就好像是在控制面板上调节旋钮、扳动开关,观察或推演项目的六个要素产生或将会产生的变化,看看是不是项目想要的。从本章开始,我们来看看,有哪些可以扳动的开关,有哪些可以调节的旋钮,看看调整它们会有什么样的效果。
( g4 F! r* b! b5 \
我们把这些开关和旋钮按照类别分为四组。本章将讨论其中的第一组:既然集成分为三个阶段①,那么我们来看看,集成工作在各个阶段中应该分别投入多少精力,做到什么程度。也就是说,我们应当把按钮拧到什么位置。此外,我们也将讨论具体选择哪些集成工作方法,这就好像是确定应该扳动哪些开关到开的位置。$ |# E7 y! N- @" b4 _
$ s: A1 c5 c. A' v$ m  ~3 n3 u' ~
①关于集成的三个阶段,见第2.4节。
尽管我们以笛卡尔式的分析方法①入手,但要始终注意,这些旋钮并非独立存在,它们相互关联,相互影响,一起构成了软件集成的整体解决方案。而我们做集成优化改进的目标,也是为了让项目整体受益,而非局部优化,或提高某个指标* N% @9 I8 I/ X! |" o
 楼主| 发表于 2013-9-13 20:30:37 | 显示全部楼层
4.1 提交前检测力度
8 \) K6 g. t& y; T$ l4 H- O6 g& \
% t# u3 T/ Z' ]. U/ i+ w  v
假定在你所在的项目中,你收到一个提议,要在集成的第一阶段,也就是程序员提交前,通过某种方法,进一步加强质量保证工作。这种提议让人不好拒绝,因为拒绝它就可能被戴上漠视质量之类的帽子。然而,客观上讲,对于某个具体的旨在提高质量的提议,它到底是不是一个好的提议?是不是对项目对企业有利的?这可真不一定,需要具体分析。为了弄清楚它到底是不是一个好提议,首先要研究、实施这个提议的话,会有什么效果。

6 ^# ^3 k9 h8 m( }4 c有利的一面是,提交的质量会更高。于是,需要在第二阶段和第三阶段继续发现和修复的问题的数量和相应的代价会下降。此外,更多地消除了程序中的问题,减少了程序中问题的数量,也将使后续的开发和集成工作更顺畅。而不利的一面是,在第一阶段加强质量保证工作,需要在此阶段增加更多资源、更多成本,并影响项目时长。有利有弊。利多还是弊多?
3 x& E" }7 g# N4 C9 u
% N/ h. p6 W& u* R
我们先暂不考虑程序质量越高,后续开发和集成工作就更顺畅这一点。我们先只考虑为了将来发布时能达到一定质量,在第一阶段发现与修复更多问题,跟在第二和第三阶段发现与修复这些问题相比,效率是不是更高,代价是不是更低。之后,在第4.3节中,我们再考虑程序质量越高,后续开发和集成工作就更顺畅这一点,补充和修正我们的结论。
: b# q! E+ N: s
从解决问题的成本考虑,越早修复,成本越低,见第 3.6节讨论。所以,一般来说,提交前应该做检测并修复检测发现的问题,这样比晚修复要便宜。3 A) e& l) a0 P2 v: p, y
5 T7 N% M& @+ b* k: m3 z
然而从发现问题的角度考虑,边际效用递减。也就是说,在提交前,当前质量越高,发现下一个缺陷就越难。再多发现一个缺陷,要耗去程序员更多时间。对于这个缺陷,程序员值得为了在解决它的时候省一点时间,而耗费大量时间来发现它吗?
4 f6 b8 @7 s2 h9 ~0 v+ v
举例来说,一名程序员在提交前做检测,已经测出来并且修复了不少问题。根据发现缺陷所需时间的变化趋势,他预计发现下一个缺陷要再耗去自己0.5小时的时间,然而提交前修复缺陷与等测试人员发现后再修复缺陷相比,仅仅从 0.3小时降到0.1小时,下降 0.2小时。所以,他就当机立断,不再做进一步的检测工作了,干脆扔给测试团队去测试①。
5 j/ \% h2 U4 ]# R
3 S+ ?6 J! g/ l( x  `, g
程序员按照这个思路去做事,是不是比较自私呢?不再多测一测,而是扔给测试团队,会不会增加了测试团队的工作量呢?其实关系不大,因为不论程序员提交质量比较好还是特别好,测试团队都是要做全面深入的测试的。
$ r! c+ U% l6 l4 M8 \
当然,多漏给测试团队一个缺陷的话,测试团队的工作还是会增加一些,比如在缺陷跟踪工具里填上这个缺陷,将来还要复核这个缺陷是不是确实修复了。这些增加的工作量,都可以算作发现了这个缺陷后,为了解决它而进行的工作。程序员为了解决它,需要修改代码,而测试人员也跟着忙。! ~* K5 ^6 u- a5 s  s" J3 D

4 D4 b; L2 h$ K5 q( y" d$ `# \
因此,我们把前面程序员判断是否要继续检测的方法,稍微改一改,让它更合理一点:如果他根据发现缺陷所需时间的变化趋势,来预计再发现一个缺陷要继续检测的人时,要比在提交前就发现它所节约的解决问题的人时要高,那就不必继续检测了。而这里解决问题的人时,既包括程序员自己的人时,也包括测试人员的人时,如果拖到了第三阶段由测试人员发现这个问题的话。
) h% M# S4 A) I8 c4 N. L$ X7 g
换句话说,当程序员刚做完代码改动的时候,一定要做各种检测工作,努力发现问题。这个时候,一般也挺容易就能发现问题。但随着时间的流逝,他会感觉到,再发现一个问题越来越难。在适当的时候,他就要放弃了,而不是去一味追求高质量,完美的质量。这样才是对项目昀好的方法。# @( g5 k) Z9 \$ I; m

8 W! j- N. K6 W8 C- |
那么,具体如何得到那些计算、判断所需要的数据呢?估计呗。根据历史上的经验,特别是根据发现前面几个缺陷的所用的时间,可以粗糙地推测发现下一个缺陷将用的时间。对于具体的某个改动某个提交,这个推测可能会很不准,但是在统计意义上这是有价值的。而解决问题所需要的时间,可以根据经验积累。程序员要想知道测试人员为每个缺陷所多付出的时间,那就去跟测试人员聊一聊。通过沟通,说不定会发现,自己过去的猜测其实跟实际情况差得很远。
* G8 P; d5 |! e$ s# E
以上这些数据,都只能是一些粗略的估计。但这样也总比不做估计和计算,让管理层拍脑袋做结论要好。更比一根筋地只顾提高提交质量或者只顾提高开发速度要好得多。8 d$ D$ |( i% o: m+ _

# l& z9 Y' Q) H7 ]) s& h# g
以上是从成本的角度分析。发现和解决问题还会影响项目时长,下面我们将从这点分析,看看如何尽量减少因发现和解决问题而造成的项目时长增加。在你所在的实际项目中,如果你首先想尽力压缩集成成本,请重点考虑上面的分析。如果你首先想尽快发布上市,那么请重点考虑下面的分析。

( c" O2 y2 y  k1 K; J) x如果一个项目时长要求很紧,而资源供给充沛,有足够的程序员可供使用的项目,那么应该尽量缩短关键路径,压缩项目时长。在此条件下,对于关键路径上和比较容易跑到关键路径上的改动,可适当降低对提交质量的要求,缩短提交前的耗时,以此缩短以关键路径为代表的,开发新功能的路径的长度。而把发现和解决问题这部分工作尽量转由集成的第三阶段完成,并且充分利用测试和修复缺陷的充沛资源,让集成的第三阶段尽可能并行于程序功能的开发。这样,等程序功能在尽可能短的时间内开发完了,质量保证工作也差不多完成了,项目时长最短。
5 l# \0 |# Q6 u; _* S9 U. J  n8 |. Y% j1 F: V" p
也就是说,在这样的项目里,本质上是要使用一个通用的思路:既然要(在保证质量的前提下)尽快完成一件事情,那就投入宽裕的资源,把各项工作尽可能地并行起来,分头完成,哪怕因此而降低了资源的使用效率。在这个例子里,对于一个开发任务,把消除其中问题的时机推迟到集成的第三阶段,而且可能并非由做出改动的这名程序员(他可能又去忙关键路径上的其他开发任务了)来负责修正,这样会降低效率,耗费更多成本。但是这样有利于项目时长的缩短。

7 ~8 x. n* u0 q; i0 Z与上一种情况不同,有些项目程序员人手紧张,程序员成为项目的关键资源。在这样的情境里,要想项目时长昀短,要充分利用程序员资源,确保他们高效工作。此时,关注重点是提高程序员工作效率,包括发现和解决问题的效率。因此对项目时长的分析方法类似于前面从程序员的视角对其人力成本的分析:关键是减少每发现和修复一个问题所消耗的程序员的人时总数。* y5 U$ \1 Y2 ^, O7 t/ B9 M. w

1 e, t# \! k' G4 P+ J- G- F相对应的,当项目的测试人员而非程序员人手紧张的时候,就要让程序员适当多发现问题。当测试人员人手紧张时,常常不得不降低测试的频率,因而推迟每个漏入集成第三阶段的问题被发现的时间。在下一节我们将看到,越到项目后期,这将对产品发布时间有越大的影响。让程序员适当多发现问题,能够减少漏入集成第三阶段的问题的数量,昀终减少项目时长。6 t, l2 W( q8 x7 k
5 t$ ?( X" R% P$ `6 `9 }2 a
①“把我所考察的每一个难题,都尽可能地分成细小的部分,直到可以而且适于加以圆满解决的程度为止。”——勒内·笛卡尔
4 \( ?& H& {! p8 j' }' [6 P①当然,这样做的前提是,不论是测试团队在集成的第三阶段,还是程序员在集成的第一阶段,都有能力发现这个缺陷。注意,有些缺陷容易通过集成的第一阶段可采用的一些检测方法发现,却难以被第三阶段的系统测试发现。详见本章后续讨论。
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 20:36:02 | 显示全部楼层
4.2 当项目临近发布时

6 a, W$ n0 ?- U1 e$ r8 P; f; e; [( V1 e! L2 I
上一节讨论并给出的,是一般性的结论。它比较适合于项目的早期和中期。在项目末期接近发布时,有一些特殊性。本节,我们分析项目临近发布时的情况。
1 {/ j/ D2 ?1 q: G- f
项目的末期,或长或短,常常是有一段以消除缺陷为主要工作内容的稳定化阶段。此时,程序员主要是完成并提交以修复缺陷为目的的改动,而测试团队则一轮又一轮不断测试。注意,程序员提交的改动,不一定完全修复了已有的缺陷,甚至可能增加了新的缺陷。
% Y: f% g5 P: `! |9 X9 I) l8 p  J3 g) \
假定测试人员非常的多,随时可以多人并行进行任何测试以发现问题,那么每当程序员提交后,在短时间内,就能收到反馈,了解本次提交的内容是否有问题,是否仍有缺陷要修复。此时,还需要多少时间才能发布,在很大程度上取决于程序员消灭缺陷的速度。假如此时共有300个发布前需要修复的缺陷,程序员共 10人,每人每天提交的代码,号称修复 2个缺陷,其实新引入或未修复0.5个缺陷,那么每天程序员消除的缺陷总数就是(2-0.5)X10=15,也就是说,大约 20天后,程序就可以发布了。
& ~( A- Z/ e2 m
在这种条件下,要想早日发布,关键是提高程序员消灭缺陷的效率,而不是单纯地衡量他提交的质量。每天消灭2个缺陷但引入 0.5个缺陷的程序员,要比每天消灭 1个缺陷而不引入新缺陷的程序员更有贡献。在(自以为)修复了一个缺陷后,程序员要进行检测验证工作。到何时为止呢?如果他连修复带检测,已经花了4小时,估计有 80%的可能性修复了这个问题且未引入新的问题,而预计再花 1小时,能再提高 10%的可能性,有 90%的把握,那就不要再花这1小时了。因为前面的 4小时,工作效率是每小时修复 80% / 4=0.2个问题,而接下去的1小时,工作效率是每小时修复 10% / 1=0.1个问题。赶快提交,然后去修复别的问题吧。
5 d- I, [' Q' r( n- C( F/ t, r8 o$ o, n, {' q: u( ~7 J
这种情形是一种理想的情形。实际情况是,测试人员并非无限多,测试有一定的周期。在临近发布时,铺上所有的测试资源,做一轮全面深入细致的测试,如果发现的问题足够少了,指标达到具体项目的需求,就发布。如果发现的问题还不少,就继续工作。由于这是发布前的昀后一道质量把关,通常不敢靠增量测试①来把关,得是全面深入细致的测试,否则风险太大。
3 y' D1 ?  w0 ~' |8 |  g
假定进行一轮全面深入的测试需要一周的时间,测试完毕后,若不合格,就马不停蹄开始下一轮全面深入的测试。在程序员方面,简便起见,假定在我们的这个例子中,程序员的数量很多,工作效率非常高,以至于每当发现一个缺陷,在很短的时间内它就被(号称)修复了。那么,在下一轮测试之前,所有的缺陷都(号称)修复好啦。当然,是号称,其实有25%的问题没有真正修复或者新涌现出来,假定这些问题都将在下一轮测试中暴露出来。那么在这样的场景中,对付 300个需要在发布前修复的缺陷,需要多久呢?
" Q4 J8 ?" a/ k& u+ q" Y. @8 N7 r+ ]/ v0 C  L* _
第一周过去了,程序员们号称修复了全部 300个缺陷,但随后的系统测试说明,仍有 300 X 25%=75个。第二周过去了,程序员们号称修复了这 75个缺陷,但随后的系统测试说明,仍有 75 X 25%≈19个。第三周过去了,5个。第四周过去了,1个。第五周过去了,测试表明,终于可以发布了。
4 g7 c5 M7 l; g$ z7 r  Z; J2 S- \
当然,这是个极端的例子。不一定是每个到达一定严重级别的缺陷都必须修复才能发布,或许只测试出5个的时候,就可以发布了。于是,需要三周的时间。
: m3 i' e* w, G5 B1 _8 {2 i2 _: }. S- p0 M
不论是五周还是三周,都是由全面深入的系统测试的频度和程序员提交的质量①,共同决定了产品何时发布。在这种情况下,显然程序员要多花些时间,验证自己的修复工作是否真的完成了,并努力避免新的缺陷出现。
当然,这并不意味着程序员可以花无限多的时间来检测。花很多时间检测,就赶不上测试团队的下一轮全面测试了,就得等再下一轮甚至更后面的全面测试来复核。
5 Q0 C! W' z! [/ T
在本质上,此时是活动间依赖关系决定项目剩余时长。当程序员数量足够多,以至于测试团队发现的所有缺陷都可以立刻找到一个程序员来应对时,就构成了这样一种模式:在每个循环中,一个程序员修复一个已有问题,适当质量保证工作,再在提交和归入基线后,由测试团队进行全面深入的系统测试。每个循环均使缺陷数呈几何级数下降,趋向于收敛。
4 g1 w2 B5 s3 l8 J4 K7 T" |( a( f! J3 y; g7 t
这有点儿像原子核衰变。要衰变多久,取决于半衰期①和打算衰变到什么程度。在这里,如果打算“衰变”到的程度是给定的,那么关键就是“半衰期”,也就是“衰变”的速率。“衰变”的速率取决于每个循环剩余缺陷比例,比如 1/4,和每个循环时长,比如 1周。而每个循环的时长由程序员花费的时间,平均等待及进行狭义集成花费的时间,平均等待及进行全面系统测试花费的时间共同决定。若程序员花过多的时间在提交前的检测上,比如昀终令每个循环的时长变为过去的三倍,为3周;但仍有缺陷的可能性只降为以前的 1/2,即 1/8,那么“衰变”的速率就会变慢,就不值得。
; M. n1 J+ F5 H
程序员资源丰富,测试人员资源丰富,这是两种理想情况。在现实世界的具体项目中,在稳定化阶段的早期,缺陷削减的速度常常主要受程序员数量的限制,大量的缺陷等着程序员来修复。若是这样,此时应该更重视程序员的综合工作效率。而在稳定化阶段的后期临近. C; G( D8 v& |
0 K' g  G6 d! q5 R# v0 M" K: c
发布时,会变得主要是半衰期这个因素在起作用。此时应该更重视程序员的提交质量,以减少循环次数,早日收敛到可发布的质量。
/ r- l+ q. z$ Y( {, \( ?
在项目末期,常常对需要修复哪些缺陷有越来越严格的控制:为缺陷跟踪系统里的每个缺陷记录标注缺陷严重等级、重要性、紧急程度等属性,要求程序员把主要精力放在等级高的缺陷上,也可能干脆直接标明哪些缺陷必须在本次发布前修复。在项目的昀末期,甚至可能控制程序员的提交本身,只有修复特定缺陷的少量改动,才允许提交,进入集成分支。这些方法都是为了让程序员把有限的精力集中到本次发布所需要的缺陷修复上。同时,减少因修复不必要修复的缺陷而引入新的必须修复的缺陷。这一点在“衰变”即将结束,项目临近发布时特别重要。
% u- B/ r- p/ F7 a  j8 v, }7 k0 |5 A* g/ o$ Z
①这里所说的增量测试,是指测试昀近所做的改动相关的功能,测试昀有可能引起问题的部分。详见第4.9节,第 7.10节。
" r' z7 a: g4 w6 D6 J( v
1 L) K6 x  J1 o$ V% ], J①这里所说的“程序员提交的质量”,严格地讲,应该是程序员提交并(可能)经过测试团队增量测试后的质量。在第三阶段,除了全面深入的测试外,还有增量测试。详见第 4.9节和第 7.10节。

/ V5 z. R4 L/ G" p4 [: _/ t: _+ n9 m2 O( `: \
①半衰期( half-life)是指某种特定物质的浓度经过某种反应降低到剩下初始时一半所消耗的时间。人们一般在谈论放射性元素的衰变、药物在体内的吸收和代谢等话题时,使用这个名词。
/ L/ U, b( f0 I. W' Z1 u
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 20:55:42 | 显示全部楼层
4.3 为了让后续工作更顺畅

6 E& V' e  e9 |) L5 Y9 S( }2 D% q+ @, P2 @/ s) u
在前两节,我们是以将来软件对外发布时,它需要具有的一定的软件质量为目标,从发现和解决问题的效率这一点,考察提交前应有的质量。下面我们进一步考虑另一个因素:程序当前质量越高,则后续开发和集成工作就更顺畅。我们将据此补充和修正前面的结论。
; r* |+ j0 R7 Q" e- g
我们知道,那些挡住了很多后续功能的展现的问题,其对程序员开发新功能和测试人员测试的负面影响很大,有很高的修复价值。而这些问题,通常也是严重的问题,对程序的昀终使用者有很高的修复价值的问题。同时,它们常常还是容易发现的问题。容易发现,而修复价值又大,那么消除它们就是特别有效率、特别值得做的工作。我们就要尽力确保这样的问题不会流传到广大程序员或测试人员手上,因为越多的人遇到,项目的损失就越大。也就是说,要么在集成的第一阶段,要么在集成的第二阶段,总之在基线产生之前,要尽力消灭它们。& d) N, _, j* v6 p0 B# M
. O  u$ S# C0 k
早发现,早解决,容易解决。这个道理也适用于对付严重问题。如果比较容易就能在集成的第一阶段查出这样的严重问题,那就不要拖到集成的第二阶段,不然解决问题的成本会高。
. U; c3 I, k# P* r& Z' B! Y3 W
另一方面,在提交前到集成的第二阶段,是要汇聚各个程序员的改动。在此阶段对付问题,要让所有依赖于已提交但尚未进入基线的各个代码改动的工作处于等待状态。在对项目完成时间的影响上,这个代价比第一阶段时对付问题要明显高些。
; H- n9 x0 C( \1 o
" v2 S  U% N3 f# r$ s* G
更何况,在第二阶段对付问题,容易形成瓶颈,阻碍更多的后续开发活动。因此我们在集成的第一阶段就要尽量发现和消灭这样的严重问题。再考虑到有时程序员是从集成分支末端而非昀后一个基线取得源代码,因此我们更有理由在集成的第一阶段就要尽量发现和消灭这样的严重问题。
4 \9 N( R& y5 f
发现和消灭相对不严重的问题是有必要的,早发现,好解决。这是前两节讲的内容。而与此相比,我们要更重视发现和消灭相对严重,容易耽误后续开发和质量保证工作的问题,尽可能的不让它们跑到基线里,甚至不要跑到集成分支上。
/ O) H* f( T. I, S+ X( W, p
/ v; L9 ^8 W3 K* p; e
在什么情况下应该调节当前集成策略,在提交前加强对严重问题的检测呢?如果程序员经常因为已有程序质量不高而耽误工作,他们自己为此很头疼,那就和他们一起讨论,要不要在提交前加强对严重问题的检测,避免提交有严重问题的改动。
; c+ n- M# ?3 g% F2 J$ s
如果测试人员测试时经常因为基线中的严重问题而无法深入测试,造成测试资源不小的浪费,造成项目时长的拖延,那么就要考虑让程序员在提交前做更多的测试,至少要保证基本的质量。/ v) _5 p3 T  ?" S3 n  K5 u6 M' s, i
, W' F' C2 m6 ^# p4 f7 ?9 w
如果由于程序员的提交中经常带有严重问题,而导致集成工程师当前的工作负荷很大,形成瓶颈,经常耽误整个项目的进展,或者他为了减轻压力,不得不遗漏很多比较严重的问题到后续工作中,那么就要在提交前加强严重问题的检测和修复。

  z5 n8 _: @; k& \反之,如果没有这些现象,从统计上看,提交的严重问题不多,到集成的第二阶段时基本能对付,那就不必在提交前再增加很多测试用例或者其他检测方法。毕竟,更大的检测力度,意味着更多的资源、成本和更多的项目时长,是有代价的。7 s5 O9 D. Y) r7 d0 P: ~
6 h/ m4 c9 ~" Z0 W2 d
一般来说,对于很多人一起开发的大型项目,要花费更多的精力来避免提交严重问题。因为在这样的项目中,每个人开一条小缝,这么多人的遗漏,就会汇聚成问题的洪流,让集成工程师招架不住。在第2.5节我们聊过这个事儿。
3 j# [, |  e- d1 |! [) V
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /5 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2020-2-29 08:42 , Processed in 0.095420 second(s), 8 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表