BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷专家的衰落——实施敏捷必须面面俱到?

| 作者 李剑 关注 1 他的粉丝 发布于 2009年2月12日. 估计阅读时间: 10 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

最近国外敏捷社区颇不宁静,你方唱罢我登场。

Joel和Jeff的podcast系列,是惹着了Kent Beck,然后又惹着了Robert Martin

关于Scrum的是是非非,讨论组里仍是争论不休,InfoQ这篇新闻:采用敏捷需要面面俱到,归纳了一些讨论组里的动向,在英文站上还有30多个跟帖

而更热闹的是,Jurgen Appelo在博客里对Ron Jeffries,Robert Martin,James Shore,Alistair Cockburn以及Martin Fowler点名,以辛辣反讽的语气,批驳了他们的观点。

Jurgen在文中说:

现在,那些敏捷专家告诉我,为了实施Scrum,或是XP,或是其他任何形式的敏捷开发,你都必须要做重构。你没得选。必须这么干。他们说每个人都需要单元测试, 还说因为Scrum忽略了一些重要(但是困难)的敏捷工程实践,让事情变得更遭,还说如果你不是每天至少有一次构建集成的话你就不是敏捷……这些日子以来,他们甚至声称agile就是按照X、Y、Z这样的实践做事。搞极限编程的人开玩笑说,把XP里面那些起作用的技术实践去掉就成了Scrum。

……

我们已经完全实施了Scrum,但是XP实践还去之甚远。我们就低人一等么?敏捷专家们说,离开了XP实践的Scrum,会带来很多技术债,使生产力降低,造成项目失败。每次我看到这种话,我都觉得哪里有问题。我觉得我该说点什么,但不知道怎么说。

直到今天……

今天,我们所有的项目经理都认为,引入Scrum对我们的项目成功起到了很大帮助。我听做开发的说,(因为有Scrum),他们终于至少有机会远离技术债了。客户也说我们现在的项目质量很高……

这些里面都见不到XP。怎么弄的?

为什么每个敏捷专家,还有他们的大叔(译注,这里指的是Robert Martin,他被人称作Uncle Bob),都在警告大家不要单纯的实施Scrum而不用XP实践,但是我们的组织却正好按照那种做法做的很成功?为了理解所发生的一切,我们得干一些敏捷 专家们这些年都没干过的事情……那就是思考,还有回溯敏捷的根源。

接下来,Jurgen先是用复杂性理论(complexity theory)中的“混沌边界(The edge of chaos)”来支持他的观点。

他提到,在从左到右,从“有序”到“混沌”的这样一条谱系中,当系统位于居中的“复杂”区域内,它的适应性、创造能力等等都是最强的。对于那些一直在用有 序、结构化的方式生产软件的公司,敏捷会把他们从左边(即有序)向右推,推向混沌的方向,但不会进入混沌。而如果你没有用一些恰到好处的实践——包括技术 实践——敏捷方法就会把你推的太远,直至混沌。这可能就是为什么大多数敏捷专家都在说“Scrum in not enough”。但是,大多数组织并不是处在有序的位置。对于这种情况,敏捷方法会把他们从右往左推,推向有序的方向。这时,倘若强加一些实践于其上,就 会跟官僚政治一样,危害整个系统。所以一切都要依具体环境而定。

紧接着,他又谈到了博弈理论中的“进化稳定策略(Evolutionary stable strategy)”。他说:

除了适应性以外,在ESS中没有任何单个属性是必须存在的。的确,生物体的眼和脚给他们带来了好处,但是植物和细菌照样过得很好。很多公司通过市场和广告 获益,但也有些公司根本不考虑这个。很多软件开发项目用了自动化测试、现场客户、结对编程。但也有很多项目没用这些东西,也做的很好,我谢谢你们,谢谢你 们八辈祖宗。

……

博弈理论告诉我们,从来不会有一个最佳策略可以适用于一个环境中的所有因素……认为某些敏捷实践必须得用,这种幼稚(或是自大)就跟认为人类基因是世界上最佳的DNA链一样。

此文一出,我们自然可以料想得到社区中的反应,Ron Jeffies在博客回帖中说:

重构这里的关键点是逻辑,Jurgen,不是命令。我不会发号施令。我也不在乎你用不用重构。但是,如果你真的要用Scrum,那么:
  • 你必须从第一个Sprint起开始交付软件;
  • 你必须在随后的每一个Sprint中交付软件;
  • 如果你在第一个Sprint里交付软件,那么当时所作出的设计就会比较脆弱,因为你没时间把一切都弄好。
  • 因为这样一个设计没法从头到尾承载起项目,你就不得不改进设计;

改善既有代码的设计,即为重构之名。

你必须做重构——改善设计,不是因为我这样说你才做,而是因为除了改进代码以外你别无他法,要么就等着项目嗝屁。不过像你这么强悍,项目还嗝屁不了。

然后Jurgen Appelo又回应说:

重构跟单元测试或其他XP实践一样,都是一种投资。人们这样做,是为了*在将来*获取收益。当然,随着时间推移,脆弱的设计会变的不稳定。但最本质的问题在于,投资*何时*能够得到回报?

举个例子:如果我做的东西只会用一个月,而构建就要花三周的时间,那我为啥要做重构?……

另一个例子:如果我知道竞争对手在用Scrum的同时做重构,我可能就会打算不用重构。这样就可以更快把产品做完。没错,代码设计会比较糟糕,但*我*会得到合同!!他们就得不到!!*有了*新合同以后,等交付完第一期产品,我就有钱再花时间做重构了。

这只是两个例子,我还能给出更多,随便什么都行,不管是重构、单元测试,还是结对编程。

你说的是“你必须这样,你必须那样”,可你忘了这是个复杂的世界。

没有什么是必须的。

xp yahoogroup中,George Dinwiddie说:

我只是想知道他们是怎么办到不用重构而远离技术债的。

Jonathon Golden说:

有件事情让我感到很惊讶,他一直在说他们做的有多棒有多棒,但最后他还是说“嘿,我们要用一些XP实践了”。他肯定有些事情瞒着我们没说。他们组织里遇到 了一些问题,如果早点引入XP实践的话那些问题可能就不会出现了。现在他就不得不说,“怎么引入这些血淋淋的XP实践”。我把他这种做法叫做扯淡。

论战在Jurgen Appelo的博客上继续,Jason Gorman说:

你引用了复杂性理论,但是把代码中无可逃避的熵却视而不见。
代码会变老。跟人一样。我们会新陈代谢。我们从外界摄取有用的东西,维持我们的身体所需,但与之同时我们也会摄取进一些无用的东西。

写代码跟这个很类似。软件成长的过程中,有益或是有害的东西都会加进来。代码腐烂的速度是很惊人的——尤其是在第一个小发布之前。

Ron的意思是,如果你想保持生产效率——尤其是想在开发几周以后继续保持——那就必须与不断增长的熵作斗争。

Jurgen回应说:

Jason,我当然了解熵。因为有熵,所以我们需要常常打扫房间。但是Ron的意思是,你*必须*打扫房间,他甚至还制定了一个频率:每个Sprint!

我打赌,不是这样的。

这要看房子。还有家庭。还有环境。

Ilja Preuß也反对Jurgen的说法,他说道:

Jurgen,有个有责任心的厨子会时时保证厨房整洁的。这不需要看环境,这只是干好工作的必要条件。

我刚开始学精密制造的时候,学到的最重要的一点就是每天下午清理工作环境。这一点没得商量,不需要看环境。不然你就没法干好工作。

Jurgen继续回应:

我觉得你的类比有问题。

这也许适用于西欧国家的专业厨师,但在其他国家,其他地方就不一定适用了。你也许从没看过中国饭馆的厨房……

Ron Jeffries稍后针对Jurgen的话又写了一篇博客,叫做为什么必须做重构?在博客中他说道:

对于成功的迭代项目而言,重构是一条自然法则。下面用Scrum的名词来解释一下原因:
  1. Scrum 需要在每个Sprint结束的时候交付“完成”的软件。团队来决定完成的含义,但基本上都表示着系统可以运行,经过了测试、集成,可以交付给客户。
  2. 在传统的Scrum中,Sprint的长度为一个月,现在一般时间更短。所以团队就得在项目刚开始的两周或者一个月内交付完成的软件。
  3. 软件来自于产品负责人的backlog。它必须由特征组成。要正确的做到Scrum,我们不能叫做基础架构之类的东西,我们要交付特征。
  4. 所以,在开始几个Sprint中,团队就没时间把最终产品所需要的整个稳定的基础架构做好。我们只能做好一小部分而已。
  5. 但是,整个产品肯定需要一个大型的,性能强劲的,更加稳定的架构。
  6. 所以项目中的架构必须要改,不是因为我这样说你才这样做,而是因为刚一开始我们没有,而到最后我们得需要。
  7. 要修改基础架构的方法不多。我们可以每个Sprint重写一次,或者是对它做改进。每次都重写的话效率太低。所以我们必须做改进。软件的改进就是重构。这就是重构。
在我们学到怎么改进设计之前,Scrum有可能给我们带来好处,但是我们肯定发挥不了最大的能力,时间慢慢过去,我们还会面临速度减缓的危险。

这场论战牵涉范围甚众,这个话题就先报道到这里,回见。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

Jurgen Appelo的观点很值得商榷 by 张 晓庆

1.*有了*新合同以后,等交付完第一期产品,我就有钱再花时间做重构了。──这时的“重构”应该是重写了,这时重构与重写最大的区别
2.嘿,我们要用一些XP实践了──莫非这里的实践就是指的重构,但是Jurgen不好意思说?
3.Jonathon Golden“他肯定有些事情瞒着我们没说”───超认同这句话

Re: Jurgen Appelo的观点很值得商榷 by Jacky Li

我也是觉得Jurgen似乎有点偏激了,难怪xp yahoogroup里面有人说,他这是典型的吸引眼球~·~

支持scrum+xp by * nolearning

以前没用scrum和xp不也有不少公司赚钱,哪为啥这么多人都改用scrum、xp了?简单说就是能赚到更多的钱。
只用scrum确实可以赚钱,但是scrum+xp可以取得更好的效益,为何不用?

Scrum 和 Xp 有冲突吗? by 果 林

他们之间有冲突吗?

Scrum中间每个特征的完成和是否使用了XP没有关系吧? Scrum关注的是完成与否,而不是怎么完成。XP关注的恰恰是如何去完成。

重构有时间限制吗? 特性的完成应该就是重构的完成。
难道重构不能进入Sprint backlog? 如果真的赶着去完成特性而忽略了重构,那总有某些时候可以做这个事情,那么这个事情也可以作为一个特性进入backlog。
每日构建也不是程序员的事情吧?开发项目组就应该有特定的人员去负责构建的事,其他人不用在乎是每日构建、还是增量编译。

结论:
他们作用的域都不一样,面向和解决的问题也不一样,几乎没有特定的交集, 在项目实践中只有互补,而不是互斥。

Fooled By Randomness by Li Guanglei

当然没有什么东西是必须的. 因为1000个项目中, 只要有一个没用某种实践而取得了成功, 那么那种实践就不是必须的.

而1000个只用Scrum而不用XP的项目中, 总会有一两个凭运气获得成功, 但Jurgen这个猪头看不到死去的999的项目

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT