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

  • 李剑

2009 年 2 月 11 日

话题:敏捷Scrum最佳实践语言 & 开发架构文化 & 方法

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

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 有可能给我们带来好处,但是我们肯定发挥不了最大的能力,时间慢慢过去,我们还会面临速度减缓的危险。

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

敏捷Scrum最佳实践语言 & 开发架构文化 & 方法