透视迭代开发
上一篇 / 下一篇 2008-12-01 09:24:33 / 个人分类:测试资料
我们都知道,人对于世界的认识是一项主观活动,它受到各种因素的影响,使得我们不能够一下子对所要认知的事物有一个清晰的了解。具体到软件开发中来,我们会发现,你很难在开发之前弄清楚客户所有的需求。一方面,客户对自己想要什么可能并没有一个明确的想法,这就好比在买衣服的时候,我们在专卖店里看到一个衣服,会觉得自己穿起来很帅,但是你仍然需要把它真实的穿在身上才能看到实际效果,而在你看到这件衣服之前,你能够仅仅凭着想象在脑海里刻画出这件衣服的样子么?51Testing软件测试网-_4[,h2\I
~uCa,G
51Testing软件测试网xDWk?N
其次,软件工业中我们讲究的是投入和产出比,软件业的成本主要是人力资源的成本。这也是软件项目对时间特别敏感的原因。时间比计划延长一个月,对于一个数十人的团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软件是完美无缺的呢?于是很多时候我们必须对已经开发的部分进行修正,而修正就需要时间。 传统的开发方式下,很多软件项目都是在匆忙交付后发现用户不满意,于是继续修正,再次引发用户的不满意,再次修正,在这样反复地拖延中,客户和软件开发商都筋疲力尽。51Testing软件测试网M@:C+^ \LJ0|
51Testing软件测试网dp/}d%Bb
我们需要迭代开发,是因为我们深知对事物的认知就是一个探索的过程,软件开发也是一样。在温博格《探索需求---设计前的质量》一书中提到:
7S3l\ xsOb6d8_:m'u0
Mbm;t H }G0 美国第34任总统艾森豪威尔上将曾经说过,"计划本身什么都不是,而编制计划的过程就是一切"。我们认同这样的说法,并把它推广到需求过程:产品什么都不是,而开发的过程就是一切。51Testing软件测试网#a?b/P:]g
8y#S0DY$r%D9y-n0 或用另一种方式表达:发现什么都不是,而发现过程(探索过程)就是一切。51Testing软件测试网{s r,r:qf+X
\8t kb7V V+N0 软件项目本身的意义就在于和用户一起探索他们真正需要的东西并且帮助他们实现。而这种探索,如同在第一段中我们阐述的那样,需要不断的反复,如果我们没有做好迭代和反复的准备,而是希望一次性的把所有工作都做完并且还做得非常好,结果可能恰恰相反。
+v |xf l^W|051Testing软件测试网YzD%RHH YCQ
我们需要迭代开发,是因为我们追求软件质量的最大化。没有人可以制造出完美无缺的东西,但是我们可以通过不断的检查和反馈,使得那些不适合的东西在早期被暴露出来,迭代给予了我们这样一种检查合反馈的机制,让我们不必在事情结束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物。51Testing软件测试网L;TEW/t:g,xC`/~a
8c.?7EC K:nEG0 实践:正确实施迭代开发
d:~o/\BS,?^051Testing软件测试网A"P Org5a}~*`
事实上在业界,迭代开发的观念早已经深入人心,然而有多少团队在正确地实施着迭代方法呢?有多少团队通过迭代得到了他们想要的东西呢?很多人简单的把迭代理解为开发的分阶段进行。我们常常看到有项目经理们这样说:我们打算通过4次迭代完成软件的开发,第一次迭代,完成需求分析和软件设计,第二次迭代,完成多少多少模块的开发,第三次,完成其他多少模块的开发,第四次,配置,部署,上线,测试,修正软件bug。虽然我们言必称“迭代”,但是这样的迭代和过去传统的瀑布型开发有多少区别?我们又能够从这样的伪迭代中得到什么好处呢?51Testing软件测试网"Ha6b T#q7q
51Testing软件测试网k1{k$u/SFp#\w
在本文以下部分将对迭代开发实践中几个关键方面进行阐述,这几个方面我们概括为以下关键词:变化,周期,目标,反馈,合作。51Testing软件测试网I0C Qh7Ap
+s*]'pdx9S^C0 变化51Testing软件测试网r1r#`G `L i{
迭代思想带给我们最重要的一个启示,就是要适应变化,要积极、主动地拥抱变化而不是拒绝变化。51Testing软件测试网p2hF'yy Cl i
51Testing软件测试网3TT^7hX*x$mM
在过去的开发中,我们常常会拒绝变化,以需求分析工作为例,有些项目组在需求分析完成后会要求用户签字,等到交付时,如果客户有什么意见,他们就会拿出那份客户已经签字画押的文件来理直气壮地说:这是你们签字过的东西,我们做的难道不是和这里所说的一样么?51Testing软件测试网W.fhD)M ax
51Testing软件测试网-x+AhFV7Wp4v
是的,开发出来的可能是和需求定义文件的内容一样的,但问题是:这份需求定义文件上描述的内容是不是真正能够帮客户实现自己的价值呢?难道我们进行软件开发的目的就是让客户在一份他们根本不清楚有什么意义的文件上签字,然后用这个来反驳用户的真正需求么?我们在软件立项之前总是会告诉用户,这个即将开发的软件会帮助他们如何如何。我们有什么理由为我们做不到这一点而理直气壮地责备客户呢?客户亲笔签名的需求文档难道不是我们整理出来并且讲解给他们听的么?
Wle!SR3Xf j q0
/t*]zh Od:xv&w0 如果一个软件项目的目标是帮助客户实现某一方面的增值,但是这种增值的目的并没有达到,我们就可以认为这个软件项目是失败的。即使软件厂商通过这个项目达到了盈利的目的,满腹牢骚的客户也会把自己的意见传播出去。而如果软件厂商认为这种事情是天经地义的话,那么它在以后的软件项目中也很难帮助自己的客户实现他们想要的价值。
jz~{5Z;bQ0
G a1ut[l0 我们必须让自己具有适应变化的能力。因为这种变化是客户需要的,因为这种变化能够让软件更能体现出自己的价值。我并不是说应该无条件地接受这种变化,但是我们可以在事前就这些问题和客户进行充分的讨论和沟通,让他们明白,世界总是变化的,需求本身可能会变化,而这种变化需要人力和物力的支持。让客户也能够适应自身的变化,这是非常重要的。
H6VPg:dex0
/m#C&UI:{wZ]0引子:我们为什么需要迭代开发?51Testing软件测试网3U(pWT3f'` u;x
h_hR$S^i5Q0 我们都知道,人对于世界的认识是一项主观活动,它受到各种因素的影响,使得我们不能够一下子对所要认知的事物有一个清晰的了解。具体到软件开发中来,我们会发现,你很难在开发之前弄清楚客户所有的需求。一方面,客户对自己想要什么可能并没有一个明确的想法,这就好比在买衣服的时候,我们在专卖店里看到一个衣服,会觉得自己穿起来很帅,但是你仍然需要把它真实的穿在身上才能看到实际效果,而在你看到这件衣服之前,你能够仅仅凭着想象在脑海里刻画出这件衣服的样子么?51Testing软件测试网,^.Bv)P t w
51Testing软件测试网qW&{ {'|!Oo5ZPI'\
其次,软件工业中我们讲究的是投入和产出比,软件业的成本主要是人力资源的成本。这也是软件项目对时间特别敏感的原因。时间比计划延长一个月,对于一个数十人的团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软件是完美无缺的呢?于是很多时候我们必须对已经开发的部分进行修正,而修正就需要时间。 传统的开发方式下,很多软件项目都是在匆忙交付后发现用户不满意,于是继续修正,再次引发用户的不满意,再次修正,在这样反复地拖延中,客户和软件开发商都筋疲力尽。
}___&i9e051Testing软件测试网^ q)f5z~s_)Nq*N+z
我们需要迭代开发,是因为我们深知对事物的认知就是一个探索的过程,软件开发也是一样。在温博格《探索需求---设计前的质量》一书中提到:
#i`"?O^3_(^1mb0
Bxd%aqT4~#V0 美国第34任总统艾森豪威尔上将曾经说过,"计划本身什么都不是,而编制计划的过程就是一切"。我们认同这样的说法,并把它推广到需求过程:产品什么都不是,而开发的过程就是一切。51Testing软件测试网 O&j\3L Ut:Nb
ouT:GL|K0 或用另一种方式表达:发现什么都不是,而发现过程(探索过程)就是一切。
A1ha!P_%U0
D!k0f[pjJe;M0 软件项目本身的意义就在于和用户一起探索他们真正需要的东西并且帮助他们实现。而这种探索,如同在第一段中我们阐述的那样,需要不断的反复,如果我们没有做好迭代和反复的准备,而是希望一次性的把所有工作都做完并且还做得非常好,结果可能恰恰相反。
q'S6q/N$v_051Testing软件测试网 |Y%E$i/F*Z
我们需要迭代开发,是因为我们追求软件质量的最大化。没有人可以制造出完美无缺的东西,但是我们可以通过不断的检查和反馈,使得那些不适合的东西在早期被暴露出来,迭代给予了我们这样一种检查合反馈的机制,让我们不必在事情结束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物。51Testing软件测试网{FVp9m!YD({
#|/[}{F IPx0 实践:正确实施迭代开发51Testing软件测试网5x:j'RG+i,M7Dn;f
#un7v#?7Ta0 事实上在业界,迭代开发的观念早已经深入人心,然而有多少团队在正确地实施着迭代方法呢?有多少团队通过迭代得到了他们想要的东西呢?很多人简单的把迭代理解为开发的分阶段进行。我们常常看到有项目经理们这样说:我们打算通过4次迭代完成软件的开发,第一次迭代,完成需求分析和软件设计,第二次迭代,完成多少多少模块的开发,第三次,完成其他多少模块的开发,第四次,配置,部署,上线,测试,修正软件bug。虽然我们言必称“迭代”,但是这样的迭代和过去传统的瀑布型开发有多少区别?我们又能够从这样的伪迭代中得到什么好处呢?51Testing软件测试网 kd;s7i9I"SA
51Testing软件测试网1JP Sp]"m
在本文以下部分将对迭代开发实践中几个关键方面进行阐述,这几个方面我们概括为以下关键词:变化,周期,目标,反馈,合作。
.?1j1p2{P0
7Ee F FD`S4S0 变化
?5Sj!M`t;n%bF0 迭代思想带给我们最重要的一个启示,就是要适应变化,要积极、主动地拥抱变化而不是拒绝变化。51Testing软件测试网A-X2mS"pBy/f
|"{(S*M0As0mv'H0 在过去的开发中,我们常常会拒绝变化,以需求分析工作为例,有些项目组在需求分析完成后会要求用户签字,等到交付时,如果客户有什么意见,他们就会拿出那份客户已经签字画押的文件来理直气壮地说:这是你们签字过的东西,我们做的难道不是和这里所说的一样么?51Testing软件测试网P0T"H L` v$j
C~9BLr.X1b$AW0 是的,开发出来的可能是和需求定义文件的内容一样的,但问题是:这份需求定义文件上描述的内容是不是真正能够帮客户实现自己的价值呢?难道我们进行软件开发的目的就是让客户在一份他们根本不清楚有什么意义的文件上签字,然后用这个来反驳用户的真正需求么?我们在软件立项之前总是会告诉用户,这个即将开发的软件会帮助他们如何如何。我们有什么理由为我们做不到这一点而理直气壮地责备客户呢?客户亲笔签名的需求文档难道不是我们整理出来并且讲解给他们听的么?51Testing软件测试网hz&\S f,|"|p}
51Testing软件测试网[_.R,f{U)Q5q
如果一个软件项目的目标是帮助客户实现某一方面的增值,但是这种增值的目的并没有达到,我们就可以认为这个软件项目是失败的。即使软件厂商通过这个项目达到了盈利的目的,满腹牢骚的客户也会把自己的意见传播出去。而如果软件厂商认为这种事情是天经地义的话,那么它在以后的软件项目中也很难帮助自己的客户实现他们想要的价值。51Testing软件测试网Nf,Au{d;~|N
51Testing软件测试网 |N!X"HE.X
我们必须让自己具有适应变化的能力。因为这种变化是客户需要的,因为这种变化能够让软件更能体现出自己的价值。我并不是说应该无条件地接受这种变化,但是我们可以在事前就这些问题和客户进行充分的讨论和沟通,让他们明白,世界总是变化的,需求本身可能会变化,而这种变化需要人力和物力的支持。让客户也能够适应自身的变化,这是非常重要的。
X0K mw4E8w"Jm1n c051Testing软件测试网3tjU]r:Gy
将剩余的工作列入下一次迭代计划中去,51Testing软件测试网[ M;_ [^bi
将本次迭代的结束时间向后延迟,等待任务的完成51Testing软件测试网,LI:jU5g Kh
前一种办法适合于有很大工作量没有完成的情况,这可能也同时说明计划的制定有问题,在制定下次迭代计划时应该考虑对任务完成时间进行调整。后一种办法适合剩余工作量不是很大的情况。
5nq!g8@AO$Zt051Testing软件测试网7ff.pW-f%d v[?T ]
通常来说,一次迭代完成以后应该有一个产品的新版本可用。这也就意味着:将集成和发布分散到每次迭代中去。借助于一些自动化工具(比如ant),我们甚至可以做到每日构建。51Testing软件测试网!Y9m(['{!n!_5d'm
51Testing软件测试网&lp/nX8Lb8K-CF
一个迭代周期应该有多长呢?这并没有一个统一的说法,而是应该视目标和可用的资源而定。但是,迭代周期不宜过长,也不宜过短。迭代周期过长的话,会延缓反馈的时间,可能将许多问题隐藏或是堆积了起来。迭代周期过短,会让人身心疲劳,事情难有大的成效。一般来说,迭代周期应该在2-6周之间。如果安排的迭代周期超过了两个月,你可能就必须审视一下迭代计划的合理性了。
v#N-kh.k!]&p)w051Testing软件测试网,f;c7q;? ZD;l[1e
不要认为下一次迭代应该和上次迭代的时间差不多,刻板地把所有迭代规定一个统一的时间是一个很坏的做法。但是你可以把以前迭代周期中的工作效率作为估算下次迭代时间的一个依据。
)nLW UbdN1s x0
BP4\2oK^'IC)p5E0 目标51Testing软件测试网_]}(mR,Le6B3\
一次迭代必须有明确的目标:我们希望通过这次迭代达到什么目的。在制定目标时,应该同时考虑另外一个问题:如何检查该目标是否已经达成。这就是所谓的“里程碑”。
$K}K#AQ6O051Testing软件测试网_cP^%f+i
迭代计划必须有明确而可行的目标。明确的意思是它应该是可度量的,不能太模糊,因为你很难检查一个模糊的目标是否达成。比如,我们可以说,这次迭代的目标是对xxx方面的需求作进一步细化和评审,完成xxx模块的开发以加入到软件的下一版本中去。这样的目标是明确而且可行的。反过来,如果我们这样说:我们要通过和用户的讨论明确绝大部分愿景,同时要有一个初步的开发。“绝大部分”和“初步”这样的词让人感到困惑:多少是绝大部分呢,在总量尚未明确的前提下,怎么能够知道完成的确是“绝大部分”而不是“一小部分”?“初步的开发”似乎告诉我们这次开发量比较小,但是具体开发哪个部分,或者开发到什么程度,并没有指出一个明确的概念。
/w6J*a4PR}051Testing软件测试网GxKR1|@W|Xe
由此产生了一个困惑,软件项目是一个不断探索的过程,我们怎么能够明确地对未来的事情作安排呢?譬如在项目初始调查用户愿景时,为了实现“明确”的目标,是否这样定义任务:完成20%的用户愿景调查?51Testing软件测试网P;[\e.NK r!y
51Testing软件测试网X Ii@;Cf&Jw
很显然,用户愿景总量到底有多少我们并不知道,所以在这次迭代完成以后如果我们问:是否真的完成了20%而不是15%?很难得到答案。
'WE[i*jf.BT$I%]0
X~T%ztL+W4W0 为了避免出现这种情况,你必须换个角度来看问题,比如我们可以说:对xxx部门和yyy部门的用户做愿景调查。在迭代完成后,可以检查是否这两个部门所有用户的访谈,调查都已经完成,是否这些部门每个人都认为自己表达了全部的意思。51Testing软件测试网2k^^R}+}Pd
51Testing软件测试网0wc$p@2KmAE3Ur
所以,如果你发现很难对制定的目标进行度量,那么换一个角度来看事情吧,你可能就会找到一个合适的表达方式。如果你从所有的角度都看不到事情是可以度量的,那么这可能意味着这件事情可能还没有到应该去实施的地步,这时你应该把它从迭代计划中去掉。对于这种情况,有人可能会说:那我们这次迭代可做的事情就很少了,如果真是这样,那就进行一次小的迭代吧,可能把这次迭代的工作做完了以后就会有更多的工作可以安排了。51Testing软件测试网Tu2f,u'jNH#t
&w"Jr#E3K @ p;~ N0 有些项目经理在日程表上,很详细地写着:第一次迭代,某月某日到某月某日,第二次迭代:某月某日到某月某日,第三次迭代。。。这样的做法是不恰当的。因为它假设了后面几次迭代的任务量,但是实际上,在前面的工作完成之前,你很难对以后的工作得到一个明确地概念。而且在这样的计划上,可能并没有用于测量迭代成果的里程碑,这样的迭代最后很可能会演变成为瀑布式的开发。所以,在一次迭代完成之前,不要对急着去计划下次迭代,特别是不要试图精确定义下次迭代的时间,因为你连下次迭代要做什么都还不清楚。
C:x @({g,T)]/[!\*l"D0
d!c:I$wL0 为什么目标的可度量性这么重要呢?在团队开发中,很多信息因为人与人的交流不畅而无法得到正确地反馈,这让我们没有办法实时地掌握项目的进展情况,退而求其次,我们必须阶段性地了解这些信息。如果目标难以度量,迭代结束后我们很难明确到底有哪些工作没有完成,也就无法看到事情的问题所在。
7Fs3]P:z~.`k051Testing软件测试网dw:x yl5z,^#~
有些团队中会要求每个成员每天对自己的工作进度以百分比的形式做汇报,他们以为通过这样的方式可以确实的掌握事情的进展,但实际上并不行,因为软件开发中存在很多不确定因素,有时候我们认为事情已经完成了一大半,但是可能因为技术或者其他的原因发现这一大半工作方向是错的,这时候就要推倒重来,而且人们在汇报工作量的时候总是会有一些感情的因素在里面,这就使那些看似精确的百分比打了个折扣。
j5VQE$}4L0
51Testing软件测试网xDWk?N
其次,软件工业中我们讲究的是投入和产出比,软件业的成本主要是人力资源的成本。这也是软件项目对时间特别敏感的原因。时间比计划延长一个月,对于一个数十人的团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软件是完美无缺的呢?于是很多时候我们必须对已经开发的部分进行修正,而修正就需要时间。 传统的开发方式下,很多软件项目都是在匆忙交付后发现用户不满意,于是继续修正,再次引发用户的不满意,再次修正,在这样反复地拖延中,客户和软件开发商都筋疲力尽。51Testing软件测试网M@:C+^ \LJ0|
51Testing软件测试网dp/}d%Bb
我们需要迭代开发,是因为我们深知对事物的认知就是一个探索的过程,软件开发也是一样。在温博格《探索需求---设计前的质量》一书中提到:
7S3l\ xsOb6d8_:m'u0
Mbm;t H }G0 美国第34任总统艾森豪威尔上将曾经说过,"计划本身什么都不是,而编制计划的过程就是一切"。我们认同这样的说法,并把它推广到需求过程:产品什么都不是,而开发的过程就是一切。51Testing软件测试网#a?b/P:]g
8y#S0DY$r%D9y-n0 或用另一种方式表达:发现什么都不是,而发现过程(探索过程)就是一切。51Testing软件测试网{s r,r:qf+X
\8t kb7V V+N0 软件项目本身的意义就在于和用户一起探索他们真正需要的东西并且帮助他们实现。而这种探索,如同在第一段中我们阐述的那样,需要不断的反复,如果我们没有做好迭代和反复的准备,而是希望一次性的把所有工作都做完并且还做得非常好,结果可能恰恰相反。
+v |xf l^W|051Testing软件测试网YzD%RHH YCQ
我们需要迭代开发,是因为我们追求软件质量的最大化。没有人可以制造出完美无缺的东西,但是我们可以通过不断的检查和反馈,使得那些不适合的东西在早期被暴露出来,迭代给予了我们这样一种检查合反馈的机制,让我们不必在事情结束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物。51Testing软件测试网L;TEW/t:g,xC`/~a
8c.?7EC K:nEG0 实践:正确实施迭代开发
d:~o/\BS,?^051Testing软件测试网A"P Org5a}~*`
事实上在业界,迭代开发的观念早已经深入人心,然而有多少团队在正确地实施着迭代方法呢?有多少团队通过迭代得到了他们想要的东西呢?很多人简单的把迭代理解为开发的分阶段进行。我们常常看到有项目经理们这样说:我们打算通过4次迭代完成软件的开发,第一次迭代,完成需求分析和软件设计,第二次迭代,完成多少多少模块的开发,第三次,完成其他多少模块的开发,第四次,配置,部署,上线,测试,修正软件bug。虽然我们言必称“迭代”,但是这样的迭代和过去传统的瀑布型开发有多少区别?我们又能够从这样的伪迭代中得到什么好处呢?51Testing软件测试网"Ha6b T#q7q
51Testing软件测试网k1{k$u/SFp#\w
在本文以下部分将对迭代开发实践中几个关键方面进行阐述,这几个方面我们概括为以下关键词:变化,周期,目标,反馈,合作。51Testing软件测试网I0C Qh7Ap
+s*]'pdx9S^C0 变化51Testing软件测试网r1r#`G `L i{
迭代思想带给我们最重要的一个启示,就是要适应变化,要积极、主动地拥抱变化而不是拒绝变化。51Testing软件测试网p2hF'yy Cl i
51Testing软件测试网3TT^7hX*x$mM
在过去的开发中,我们常常会拒绝变化,以需求分析工作为例,有些项目组在需求分析完成后会要求用户签字,等到交付时,如果客户有什么意见,他们就会拿出那份客户已经签字画押的文件来理直气壮地说:这是你们签字过的东西,我们做的难道不是和这里所说的一样么?51Testing软件测试网W.fhD)M ax
51Testing软件测试网-x+AhFV7Wp4v
是的,开发出来的可能是和需求定义文件的内容一样的,但问题是:这份需求定义文件上描述的内容是不是真正能够帮客户实现自己的价值呢?难道我们进行软件开发的目的就是让客户在一份他们根本不清楚有什么意义的文件上签字,然后用这个来反驳用户的真正需求么?我们在软件立项之前总是会告诉用户,这个即将开发的软件会帮助他们如何如何。我们有什么理由为我们做不到这一点而理直气壮地责备客户呢?客户亲笔签名的需求文档难道不是我们整理出来并且讲解给他们听的么?
Wle!SR3Xf j q0
/t*]zh Od:xv&w0 如果一个软件项目的目标是帮助客户实现某一方面的增值,但是这种增值的目的并没有达到,我们就可以认为这个软件项目是失败的。即使软件厂商通过这个项目达到了盈利的目的,满腹牢骚的客户也会把自己的意见传播出去。而如果软件厂商认为这种事情是天经地义的话,那么它在以后的软件项目中也很难帮助自己的客户实现他们想要的价值。
jz~{5Z;bQ0
G a1ut[l0 我们必须让自己具有适应变化的能力。因为这种变化是客户需要的,因为这种变化能够让软件更能体现出自己的价值。我并不是说应该无条件地接受这种变化,但是我们可以在事前就这些问题和客户进行充分的讨论和沟通,让他们明白,世界总是变化的,需求本身可能会变化,而这种变化需要人力和物力的支持。让客户也能够适应自身的变化,这是非常重要的。
H6VPg:dex0
/m#C&UI:{wZ]0引子:我们为什么需要迭代开发?51Testing软件测试网3U(pWT3f'` u;x
h_hR$S^i5Q0 我们都知道,人对于世界的认识是一项主观活动,它受到各种因素的影响,使得我们不能够一下子对所要认知的事物有一个清晰的了解。具体到软件开发中来,我们会发现,你很难在开发之前弄清楚客户所有的需求。一方面,客户对自己想要什么可能并没有一个明确的想法,这就好比在买衣服的时候,我们在专卖店里看到一个衣服,会觉得自己穿起来很帅,但是你仍然需要把它真实的穿在身上才能看到实际效果,而在你看到这件衣服之前,你能够仅仅凭着想象在脑海里刻画出这件衣服的样子么?51Testing软件测试网,^.Bv)P t w
51Testing软件测试网qW&{ {'|!Oo5ZPI'\
其次,软件工业中我们讲究的是投入和产出比,软件业的成本主要是人力资源的成本。这也是软件项目对时间特别敏感的原因。时间比计划延长一个月,对于一个数十人的团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软件是完美无缺的呢?于是很多时候我们必须对已经开发的部分进行修正,而修正就需要时间。 传统的开发方式下,很多软件项目都是在匆忙交付后发现用户不满意,于是继续修正,再次引发用户的不满意,再次修正,在这样反复地拖延中,客户和软件开发商都筋疲力尽。
}___&i9e051Testing软件测试网^ q)f5z~s_)Nq*N+z
我们需要迭代开发,是因为我们深知对事物的认知就是一个探索的过程,软件开发也是一样。在温博格《探索需求---设计前的质量》一书中提到:
#i`"?O^3_(^1mb0
Bxd%aqT4~#V0 美国第34任总统艾森豪威尔上将曾经说过,"计划本身什么都不是,而编制计划的过程就是一切"。我们认同这样的说法,并把它推广到需求过程:产品什么都不是,而开发的过程就是一切。51Testing软件测试网 O&j\3L Ut:Nb
ouT:GL|K0 或用另一种方式表达:发现什么都不是,而发现过程(探索过程)就是一切。
A1ha!P_%U0
D!k0f[pjJe;M0 软件项目本身的意义就在于和用户一起探索他们真正需要的东西并且帮助他们实现。而这种探索,如同在第一段中我们阐述的那样,需要不断的反复,如果我们没有做好迭代和反复的准备,而是希望一次性的把所有工作都做完并且还做得非常好,结果可能恰恰相反。
q'S6q/N$v_051Testing软件测试网 |Y%E$i/F*Z
我们需要迭代开发,是因为我们追求软件质量的最大化。没有人可以制造出完美无缺的东西,但是我们可以通过不断的检查和反馈,使得那些不适合的东西在早期被暴露出来,迭代给予了我们这样一种检查合反馈的机制,让我们不必在事情结束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物。51Testing软件测试网{FVp9m!YD({
#|/[}{F IPx0 实践:正确实施迭代开发51Testing软件测试网5x:j'RG+i,M7Dn;f
#un7v#?7Ta0 事实上在业界,迭代开发的观念早已经深入人心,然而有多少团队在正确地实施着迭代方法呢?有多少团队通过迭代得到了他们想要的东西呢?很多人简单的把迭代理解为开发的分阶段进行。我们常常看到有项目经理们这样说:我们打算通过4次迭代完成软件的开发,第一次迭代,完成需求分析和软件设计,第二次迭代,完成多少多少模块的开发,第三次,完成其他多少模块的开发,第四次,配置,部署,上线,测试,修正软件bug。虽然我们言必称“迭代”,但是这样的迭代和过去传统的瀑布型开发有多少区别?我们又能够从这样的伪迭代中得到什么好处呢?51Testing软件测试网 kd;s7i9I"SA
51Testing软件测试网1JP Sp]"m
在本文以下部分将对迭代开发实践中几个关键方面进行阐述,这几个方面我们概括为以下关键词:变化,周期,目标,反馈,合作。
.?1j1p2{P0
7Ee F FD`S4S0 变化
?5Sj!M`t;n%bF0 迭代思想带给我们最重要的一个启示,就是要适应变化,要积极、主动地拥抱变化而不是拒绝变化。51Testing软件测试网A-X2mS"pBy/f
|"{(S*M0As0mv'H0 在过去的开发中,我们常常会拒绝变化,以需求分析工作为例,有些项目组在需求分析完成后会要求用户签字,等到交付时,如果客户有什么意见,他们就会拿出那份客户已经签字画押的文件来理直气壮地说:这是你们签字过的东西,我们做的难道不是和这里所说的一样么?51Testing软件测试网P0T"H L` v$j
C~9BLr.X1b$AW0 是的,开发出来的可能是和需求定义文件的内容一样的,但问题是:这份需求定义文件上描述的内容是不是真正能够帮客户实现自己的价值呢?难道我们进行软件开发的目的就是让客户在一份他们根本不清楚有什么意义的文件上签字,然后用这个来反驳用户的真正需求么?我们在软件立项之前总是会告诉用户,这个即将开发的软件会帮助他们如何如何。我们有什么理由为我们做不到这一点而理直气壮地责备客户呢?客户亲笔签名的需求文档难道不是我们整理出来并且讲解给他们听的么?51Testing软件测试网hz&\S f,|"|p}
51Testing软件测试网[_.R,f{U)Q5q
如果一个软件项目的目标是帮助客户实现某一方面的增值,但是这种增值的目的并没有达到,我们就可以认为这个软件项目是失败的。即使软件厂商通过这个项目达到了盈利的目的,满腹牢骚的客户也会把自己的意见传播出去。而如果软件厂商认为这种事情是天经地义的话,那么它在以后的软件项目中也很难帮助自己的客户实现他们想要的价值。51Testing软件测试网Nf,Au{d;~|N
51Testing软件测试网 |N!X"HE.X
我们必须让自己具有适应变化的能力。因为这种变化是客户需要的,因为这种变化能够让软件更能体现出自己的价值。我并不是说应该无条件地接受这种变化,但是我们可以在事前就这些问题和客户进行充分的讨论和沟通,让他们明白,世界总是变化的,需求本身可能会变化,而这种变化需要人力和物力的支持。让客户也能够适应自身的变化,这是非常重要的。
X0K mw4E8w"Jm1n c051Testing软件测试网3tjU]r:Gy
将剩余的工作列入下一次迭代计划中去,51Testing软件测试网[ M;_ [^bi
将本次迭代的结束时间向后延迟,等待任务的完成51Testing软件测试网,LI:jU5g Kh
前一种办法适合于有很大工作量没有完成的情况,这可能也同时说明计划的制定有问题,在制定下次迭代计划时应该考虑对任务完成时间进行调整。后一种办法适合剩余工作量不是很大的情况。
5nq!g8@AO$Zt051Testing软件测试网7ff.pW-f%d v[?T ]
通常来说,一次迭代完成以后应该有一个产品的新版本可用。这也就意味着:将集成和发布分散到每次迭代中去。借助于一些自动化工具(比如ant),我们甚至可以做到每日构建。51Testing软件测试网!Y9m(['{!n!_5d'm
51Testing软件测试网&lp/nX8Lb8K-CF
一个迭代周期应该有多长呢?这并没有一个统一的说法,而是应该视目标和可用的资源而定。但是,迭代周期不宜过长,也不宜过短。迭代周期过长的话,会延缓反馈的时间,可能将许多问题隐藏或是堆积了起来。迭代周期过短,会让人身心疲劳,事情难有大的成效。一般来说,迭代周期应该在2-6周之间。如果安排的迭代周期超过了两个月,你可能就必须审视一下迭代计划的合理性了。
v#N-kh.k!]&p)w051Testing软件测试网,f;c7q;? ZD;l[1e
不要认为下一次迭代应该和上次迭代的时间差不多,刻板地把所有迭代规定一个统一的时间是一个很坏的做法。但是你可以把以前迭代周期中的工作效率作为估算下次迭代时间的一个依据。
)nLW UbdN1s x0
BP4\2oK^'IC)p5E0 目标51Testing软件测试网_]}(mR,Le6B3\
一次迭代必须有明确的目标:我们希望通过这次迭代达到什么目的。在制定目标时,应该同时考虑另外一个问题:如何检查该目标是否已经达成。这就是所谓的“里程碑”。
$K}K#AQ6O051Testing软件测试网_cP^%f+i
迭代计划必须有明确而可行的目标。明确的意思是它应该是可度量的,不能太模糊,因为你很难检查一个模糊的目标是否达成。比如,我们可以说,这次迭代的目标是对xxx方面的需求作进一步细化和评审,完成xxx模块的开发以加入到软件的下一版本中去。这样的目标是明确而且可行的。反过来,如果我们这样说:我们要通过和用户的讨论明确绝大部分愿景,同时要有一个初步的开发。“绝大部分”和“初步”这样的词让人感到困惑:多少是绝大部分呢,在总量尚未明确的前提下,怎么能够知道完成的确是“绝大部分”而不是“一小部分”?“初步的开发”似乎告诉我们这次开发量比较小,但是具体开发哪个部分,或者开发到什么程度,并没有指出一个明确的概念。
/w6J*a4PR}051Testing软件测试网GxKR1|@W|Xe
由此产生了一个困惑,软件项目是一个不断探索的过程,我们怎么能够明确地对未来的事情作安排呢?譬如在项目初始调查用户愿景时,为了实现“明确”的目标,是否这样定义任务:完成20%的用户愿景调查?51Testing软件测试网P;[\e.NK r!y
51Testing软件测试网X Ii@;Cf&Jw
很显然,用户愿景总量到底有多少我们并不知道,所以在这次迭代完成以后如果我们问:是否真的完成了20%而不是15%?很难得到答案。
'WE[i*jf.BT$I%]0
X~T%ztL+W4W0 为了避免出现这种情况,你必须换个角度来看问题,比如我们可以说:对xxx部门和yyy部门的用户做愿景调查。在迭代完成后,可以检查是否这两个部门所有用户的访谈,调查都已经完成,是否这些部门每个人都认为自己表达了全部的意思。51Testing软件测试网2k^^R}+}Pd
51Testing软件测试网0wc$p@2KmAE3Ur
所以,如果你发现很难对制定的目标进行度量,那么换一个角度来看事情吧,你可能就会找到一个合适的表达方式。如果你从所有的角度都看不到事情是可以度量的,那么这可能意味着这件事情可能还没有到应该去实施的地步,这时你应该把它从迭代计划中去掉。对于这种情况,有人可能会说:那我们这次迭代可做的事情就很少了,如果真是这样,那就进行一次小的迭代吧,可能把这次迭代的工作做完了以后就会有更多的工作可以安排了。51Testing软件测试网Tu2f,u'jNH#t
&w"Jr#E3K @ p;~ N0 有些项目经理在日程表上,很详细地写着:第一次迭代,某月某日到某月某日,第二次迭代:某月某日到某月某日,第三次迭代。。。这样的做法是不恰当的。因为它假设了后面几次迭代的任务量,但是实际上,在前面的工作完成之前,你很难对以后的工作得到一个明确地概念。而且在这样的计划上,可能并没有用于测量迭代成果的里程碑,这样的迭代最后很可能会演变成为瀑布式的开发。所以,在一次迭代完成之前,不要对急着去计划下次迭代,特别是不要试图精确定义下次迭代的时间,因为你连下次迭代要做什么都还不清楚。
C:x @({g,T)]/[!\*l"D0
d!c:I$wL0 为什么目标的可度量性这么重要呢?在团队开发中,很多信息因为人与人的交流不畅而无法得到正确地反馈,这让我们没有办法实时地掌握项目的进展情况,退而求其次,我们必须阶段性地了解这些信息。如果目标难以度量,迭代结束后我们很难明确到底有哪些工作没有完成,也就无法看到事情的问题所在。
7Fs3]P:z~.`k051Testing软件测试网dw:x yl5z,^#~
有些团队中会要求每个成员每天对自己的工作进度以百分比的形式做汇报,他们以为通过这样的方式可以确实的掌握事情的进展,但实际上并不行,因为软件开发中存在很多不确定因素,有时候我们认为事情已经完成了一大半,但是可能因为技术或者其他的原因发现这一大半工作方向是错的,这时候就要推倒重来,而且人们在汇报工作量的时候总是会有一些感情的因素在里面,这就使那些看似精确的百分比打了个折扣。
j5VQE$}4L0