最近国外敏捷社区颇不宁静,你方唱罢我登场。
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的名词来解释一下原因:
在我们学到怎么改进设计之前,Scrum有可能给我们带来好处,但是我们肯定发挥不了最大的能力,时间慢慢过去,我们还会面临速度减缓的危险。
- Scrum 需要在每个Sprint结束的时候交付“完成”的软件。团队来决定完成的含义,但基本上都表示着系统可以运行,经过了测试、集成,可以交付给客户。
- 在传统的Scrum中,Sprint的长度为一个月,现在一般时间更短。所以团队就得在项目刚开始的两周或者一个月内交付完成的软件。
- 软件来自于产品负责人的backlog。它必须由特征组成。要正确的做到Scrum,我们不能叫做基础架构之类的东西,我们要交付特征。
- 所以,在开始几个Sprint中,团队就没时间把最终产品所需要的整个稳定的基础架构做好。我们只能做好一小部分而已。
- 但是,整个产品肯定需要一个大型的,性能强劲的,更加稳定的架构。
- 所以项目中的架构必须要改,不是因为我这样说你才这样做,而是因为刚一开始我们没有,而到最后我们得需要。
- 要修改基础架构的方法不多。我们可以每个Sprint重写一次,或者是对它做改进。每次都重写的话效率太低。所以我们必须做改进。软件的改进就是重构。这就是重构。
这场论战牵涉范围甚众,这个话题就先报道到这里,回见。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14639675/viewspace-594432/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14639675/viewspace-594432/