【外刊IT评论】Do do XP

花非花 — Sat, 28 Nov 2009 15:21:36 +0000

agile software development

在文章 Don’t do XP 里, Tobias Mayer 建议人们不要去搞极限编程(XP)。我和Tobias相知已久，我想他这个问题上错了。我不知道他在跟谁争论，但他们的有些争论就是“嚼舌根”。我想如果他曾经试过一次XP，那他的言论会更有说服力。 XP并不是一个万能的解决方案，但它确实是一种方案，而且我们知道如何使用它。

作为一个临时的XP支持者，我并不抱怨 “在软件工业中Scrum没有提供很好的开发原则”，我只抱怨这个产业。如果我们能在这个产业里有效率的工作，那我们也就不会有这场关于方法论的战争了，因为我们的目地就是出产品。如今当人们把Scrum概念应用到这个产业时，Scrum也不幸被人们使用的混乱不堪。另一方面，责备XP阻碍了实施方法的进步显然有些牵强。

XP是一种很小的运动，只吸引了一部分人的目光。 XP（第一版）所实现的成果是让大家知道解决一直困扰很多开发团队的无法负担开发工期压力的问题是有办法解决的，而且是在不须求助高人协助的情况下。它提供了我一套好的实践方法让我们在开发中使用。 当然了， XP 并不能解决世界上的所有问题，它并不是对每个人都适用，至少一个原因是你必须对它有相当的认识和研究，这是一般的团队所不具备的。 Kent beck所论述的第一版XP极具有针对性：它的设计目标是让我们控制混乱，拓宽我们软件开发的思路，重新制定研讨框架。

我想Tobias似乎已经忘了这十年来发生的事情。其实我们所处的完全是一个理论性的运动，因为XP把推迟代码实现作为论述的中心—— 只需看看与此相关的人，他们是相同的一群人。他似乎也忘了众多的XP实施建议直接和我们的直观感觉有冲突，特别是和当前的产业发展方向有冲突。

Tobias说这些优秀的开发实施意见传播的如此缓慢，而我要说的是，没有XP，我们估计仍在原地等待。测试驱动开发一直没有被广泛的接受，甚至连最初的C3小组也没有完全的接受它——直到有一天Kent写出了这本书。持续反省理论有一小群学院派的人追随，但是这种理论的实践如果没有TDD很好的支持会存在一定的风险情。我怀疑大多数的团队仍旧不愿轻易重整代码，除非要添加新的功能。结队编程方式也在滞销，同样，这种方式在TDD的环境中发挥的会更好。我知道有相当多的Scrum团队都没有找到一套系统的方法理论。如果说他们需要改进Scrum的实施方法，这是把问题归咎于他们如何使用Scrum和他们的自我组织问题。

最的的一点挑剔。 XP的论著有二版，第二版发布不是很久远，而且里面提到的方法论更加“柔和”。与这些实践理论相关的一件事情：C3 项目组是在 (Smalltalk/Gemstone) 这样的环境中工作的，落后于大多数我们今天使用的环境。 XP社团里的很多工作都是在增加XP的灵活性，让它能在新的开发环境中使用。真正让人恐怖的事是这个产业缓慢的发展速度。

英文原文：Do do XP

【外刊IT评论】Don’t do XP

花非花 — Tue, 24 Nov 2009 14:56:12 +0000

Steve Freeman 写了一篇 blog Do do XP 来反驳我的这篇文章。

我开始厌倦了和那些坚持认为Scrum离开了极限编程就不再有价值的人的无休止的论战。 Scrum 很好用 — 但前提是实施者必须从基础上理解它的价值所在和实施原则。你应用Scrum所处的环境条件决定了你在实施过程中应该采取哪些措施。比如，在教堂里实施Scrum和在软件开发中实施Scrum有着不同的一套实施策略。而这两种情况下的实施措施又和传统的Scrum有不同之处。

极限编程的拥护者动不动就抱怨在软件工业中Scrum没有提供很好的开发原则。但就目前极限编程被业界采纳的缓慢进度来看，真正应该受责备应是XP的缺少实践措施的问题，XP应该为这种状况负责。

从八十年代到九十年代，随着开发语言的进步和更适合于软件设计，人们开发和测试的方式发生了改变。在广大的面向对象群体中，有些概念正在缓慢的、但广泛的被人们所接受。例如持续反省、限制责任、测试代码优先（TDD）、持续集成、推迟设计、编码规范、以及结对编程等。所谓的极限编程 (Kent Beck和他的一些同事所做的) 也就是将所有的这些好的实践方法集中到一起打成一个包，再加上Jeff Sutherland 1993年在Easel公司实践出的Scrum模式。某种意义上说，这也就有抽象Scrum概念的第一次具体的实现。

这些都很成功。然而他们的这些实践经验的推广和采纳并没有像他们想象的那样进行。也许就是因为取了个极限编程的错误名称；也许是因为主要的、嗓门最大的拥护者非要说这是唯一真理的原因；也许是因为管理者恐惧这个新出现的异类，暗中作梗反对它；也许是因为，说到底，XP也不过是另一种开发方法。我不知道。我只知道，只有很少的开发团队宣称和承认采用了XP。

然而与此同时，Scrum正在获得强大的发展动力。并不需要多少华丽的理由，实际情况却是Scrum正在被为数不少的团队接受，正在用它来改进我们软件的开发过程。反而是XP现在想来分一杯羹。他们确实很饥饿。

首先，让我把问题说明白。我十分赞同软件开发团队采用一些已知的实践指导来提高代码质量、生产更高水平的软件作品。但为什么这么多人不愿意这么做？我不太喜欢把十几个任务打个包直接丢给团队，也不喜欢事先指定一种开发方法让他们必须遵守。那样做很显然违反了“people over process”和自我管理原则。在好的Scrum实施里，团队成员应根据自身情况找到适合自身的实施策略，这样的Scrum应用过程才是与实际相结合、才有意义。这才是我追求的进步。有些Scrum团队一直没有找到很满意的开发方法，这说明Scrum实施方式需要改进，而不是去告诉团队成员强制实施。

我有一个问题思考：如果XP从来没诞生过，有多少团队愿意完全接受所有XP所推荐的方法？我相信会有很多。我相信这些宝贵的开发经验会自然而然的被程序员和团队们采用，对我来说，关心的是经验本身，而不是他们出现的形式。我从来没有“done XP“，但我显然可以写出高质量的软件。 XP的错误就在于坚持要求全盘接受。这并不是XP的创始人的初衷，可现在却搞成这样。很可能就是XP导致了这些好的实践经验不被人接受。很讽刺，不是吗？

另一个大问题是，XP论述写于12年之前，于此至今已有40多种新的语言诞生。 XP倡导者在向人们推荐12年前的、现在可能过时的经验 — 12年相当于整个软件工业年龄的四分之一。惊人吧。让人们去发现适合自己的开发方法，他们将会总结出最有效的开发经验，这远不是几个脑瓜好用的人在上个世纪末能创造的。

我强烈要求Scrum倡导者停止与XP的争吵，我们讨论的应该是软件艺术。这才是我们在这个领域里急切需要的最终目标。幸运的是，现在有一个有着自己的manifesto的软件艺术运动正在逐步为人们所关注。最终，我们可以通过好的软件艺术实践运动重新改革我们这个领域，而不是使用那些修修补补的策略。

开发者们：Don’t do XP。我们要实现一个通常意义上的指导框架，解决多年来的困扰，构建以人为本的核心基础。让我们重新为艺术而工作。或者从此离开这个行业。

英文原文：Don’t do XP

外刊IT评论 » scrum

【外刊IT评论】Do do XP

【外刊IT评论】Don’t do XP