远离极限编程(Don’t do XP)

        英文原文：Don’t do XP

        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。 我们要实现一个通常意义上的指导框架，解决多年来的困扰，构建以人为本的核心基础。让我们重新为艺术而工作。或者从此离开这个行业。