Roy W. Miller(rmiller@rolemodelsoft.com)
软件开发人员,RoleModel Software, Inc.
2002 年 10 月
使用 Java 语言所进行的面向对象编程变得空前普及。它使软件开发发生了某种程度的变革。但最近的研究表明,有半数软件开发项目滞后,而三分之一的项目超出了预算。问题不在于技术;而是开发软件所使用的方法。所谓的“灵活”方法,与诸如 Java 之类的面向对象语言的能力和灵活性结合在一起,或许刚好就是答案。最流行的灵活方法称作极端编程(Extreme Programming),或简称 XP,但许多人并不真正了解它。对软件开发项目使用 XP 可以大大提高成功的机会。由 Roy Miller 撰写的这个新专栏从重访他受欢迎的文章“XP 精华”开始,将消除谣言和误解,帮助您理解 XP,并解释为什么它这么重要。Roy 很快还会在相关论坛中讨论 XP。
自从我和 Chris Collins 共同编写“XP distilled”以来已有一年了,那以后发生了很大的变化。极端编程(XP)有些成熟了,而且与以前相比,更多人在他们的组织中实现它。尽管 XP 得到了发展并由此产生了各种议论,但对于 XP 是什么和不是什么还是有许多混淆和争论。不必惊讶,甚至微软也把其最新的操作系统贴上“Windows XP”的标签,这更增加了人们的疑惑。
在此后的几个月中,我将在本专栏中澄清围绕 XP 的误解、误传和真正的疑惑。我希望向您提供解答有关 XP 问题的实用资源以及如何在组织中实现它的思想。本专栏前几篇文章将是“XP 精华”的扩展版本,它们将涉及与 XP 相关的当前实践和思想。我的目标是向您提供支持进一步探索 XP 的扎实基础以及解释它如何给您的公司和职业生涯带来变化。
我从事软件行业中的某些工作已有大约十年了。在此期间,我从未看到或使用过象 XP 那样令我兴奋的软件开发方法。我相信这是一种自然的编程方法 — 当人们开始使用时,可能并不是每个人都能感觉到自然。但如果有机会使用它,您就会惊讶于您以前怎么会使用任何其它方法进行工作的。
当然,XP 并不是开发优秀软件的唯一方法,但我深信两点:
XP 运用到实践中的原则是正确的原则。
我从未使用过象 XP 那样将软件开发的所有部分结合起来的软件开发方法。
所以,如果您还不了解它,那么我将怀着极大的热情介绍 XP。最后,我希望您也会被它所吸引 — 但并不是因为高明的市场营销。我认为让其他人信服 XP 的最佳方法是据实演示 XP,然后让他们自己决定 XP 方法是否比他们正使用的方法更好。
业务问题
在发表“XP 精华”的那一年,企业管理面临的最大问题(IT 业内和业外)一直未改变过:企业领导人如何利用他们的 IT 资产和能力获得竞争优势?在许多情况下,我们讨论的这些“资产和能力”与软件和开发软件有关。那是问题的症结所在。
一个解决方案:灵活方法
在某种程度上,“极端编程”这个名称就不太适宜。大多数人听到 XP 时,可能会想到极限运动,或 Microsoft 的操作系统。这个名称背后的思想是软件开发的最佳实践,例如编写单元测试和代码复查。为什么不能一直执行这些实践呢?当您这样做时,它们就变成类似测试驱动的开发(Test-Driven Development)和结对编程(Pair Programming)之类的概念,大多数人认为相当极端。那就是这个名字的由来。它与苏打、蹦极或比尔·盖茨无关。
可能是为了防止对该名称不合适和目光短浅的批评,那些认为象 XP 之类的方法很好的人,已开始将这样的方法称作灵活(agile)方法。您会听到将 Crystal Method、适应性软件开发(Adaptive Software Development)和(目前最流行的)XP 称为灵活方法。所有这些过程都有这样一个事实,即需要人们共同合作来开发软件。成功的软件过程必须充分发挥人们的长处,而尽量避免他们的缺点。依我看来,XP 做得最好的地方在于它解决了如何互补影响涉及到的人员的所有力量,而且当团队中的程序员编写代码时,帮助他们完成正确的事情。它还让他们在大部分时间内编写代码,而这正是他们喜欢做的。
与大多数人所说的相反,我认为不是每个程序员都会在 XP 团队中受益。XP 方法需要太多始终如一的真诚和谦虚。程序员在学校中往往不可能学到这些,而且大多数的企业环境也不鼓励这样做。软件是由人类开发的。我们都有弱点,并且我们都有许多相同的弱点。我们需要使人类还原本色的方法,一种使人们难以出差错的方法。我认为 XP 是我见到过的任何方法中这一点做得最好的方法。
XP 的价值
正如我在“XP 精华”中所说的,XP 规定了一组核心价值和实践,可以让软件开发人员发挥他们的专长:编写代码。XP 消除了大多数重量级过程中不必要的东西,它们减慢开发速度、耗费开发人员的精力(例如甘特图、状态报告,以及大量的需求文档等),从而偏离目标。Kent Beck 在他的书 Extreme Programming Explained: Embrace Change(请参阅参考资料)中概述了 XP 的核心价值。这些价值在去年没有发生实际的更改。我仍用这种方法概述了这些价值:
勇气:勇气存在于其它三个价值的环境中。它们相互支持。相信开发过程中的具体反馈比预先知道每件事更有价值,需要一定的勇气。当需要与团队中的其他人交流,而此时可能会暴露您的无知时,需要有勇气。使系统保持简单,把明天的决定留到明天做,也需要勇气。而如果没有简单的系统、没有不断的交流来扩展知识以及没有掌握方向所依赖的反馈,勇敢也就失去了依靠。
在我与其他人为在意大利撒丁岛召开的 XP2001 会议而合著的论文中,我建议在上面的列表中加上“自省”。但当在那儿演讲此论文时,我意识到自省实际上不仅仅是实践。坚持学习作为另一个价值被包含进来,这个强大的候选选项是以 Joshua Kerievsky 的一篇论文(请参阅参考资料)为基础的。在该论文中,他谈到对于一个健康的 XP 团队来说,持续学习(Continuous Learning)是如何成为必要条件的。我同意。我不知道添加另一种价值需要 XP 从业者提供什么样的支持,但我认为它很有意义。
修订版的需要
当我第一次读到 Extreme Programming Explained 时,我很兴奋,几乎爱不释手。我所见过的大多数企业环境中的软件开发方法和 Kent 描述的使人耳目一新的方法之间竟存在如此巨大差异,我为此震惊。但我在内心还是有点怀疑,书中留下了对项目业务方面有些过多的想像,这在接受时会产生问题。我被一种无法抗拒的思想给震住了,即 XP 不仅仅是关于编程的。
幸运的是,在有关 XP“12 个实践”的 XP 社区、因特网新闻组以及其它论坛中都有重点讨论。人们正意识到 XP 的第一个发行版似乎过分强调了软件开发的编程方面,而影响了其它方面,并且业务方面不是象它应有的那样十分完善。基本原则是好的,但是完成软件开发还要包含一些更多的实践。在已修改的实践列表(包含 19 个实践,而不是 12 个)中隐含了这样的认识:即 XP 实际上不仅是关于编程的。它是关于为了生产优秀软件所需创建的某种组织性变革。这个方法当然需要严明的编码纪律和高超的编码技能,但它还需要团队中每个人在思考创建软件的方法上有重大转变。这是指团队中的每个人,包括用户、业务分析员以及决策者。新的实践在这一点上绝对清楚,并主要集中在建立可一直生产优秀软件的团队上。事实上,它强调了团队是 XP 世界发生变革背后的主要驱动力。Kent Beck 在以 One Team 为主题的论文草稿中说道:
就象“客户以同一种声音告知团队”中的那样,使用“团队”一词时,就会提到程序员,这使得在 XP Explained(以及随后的论文和交谈)中,这个问题变得复杂了。这个用法总是困扰我,但我不知道对此该做什么。
新的实践和集中于一个团队的方针设法解决那个问题。以对软件开发带来组织性变革为目标的任何方法都必须弥合 IT 团队和业务团队之间的裂缝。存在裂缝的最主要原因之一首先是因为创建软件涉及的人员不属于一个团队。那么这样一个团队看上去会象什么呢?在同一篇论文中,Kent 使用了一个三条腿的凳子作为比喻。开发团队是程序员,而业务(或客户)团队是分析员、用户、测试员等等。第三条腿是管理团队,它由回答如下问题的人员组成:
非常好。我们有了一个团队。每个人做什么呢?就象一年前那样,所有 XP 实践将四个价值转换成了作为一个软件开发团队成员每天应该做的工作,不管是不是技术方面的工作。对成员而言,不管是否从事技术工作都没有什么十分新的东西。XP 编程实践被业界公认为最佳实践已经有好几年了,而且更关注于业务的实践被认为很有效(请参阅参考资料的 Standish Group CHAOS Report 以获取证据)。极端编程中的“极端”一词来自两方面,这一点仍然正确:
XP 采取经过证明的业界最佳实践并将其发挥到极致。
XP 将这些实践以某种方式进行组合,使它们产生的结果大于各部分的总和。
如果每个人都在同一个团队中,那么第二点会令人惊奇。但只要您砍掉凳子的一条腿,那就准备掉在地上吧。XP 从未保证 — 以后也不会保证 — 人们始终会做得正确,但它给予他们尝试的机会。这适用于团队中所有成员,不管是不是技术人员。团队中使用所有实践的成员一起工作会在速度和效率上得到明显的提高。这些实践可以营造使组织产生出优秀软件的环境。是否还有任何其它种类的实践呢?
修订的实践
XP 的 19 个实践(请参阅表 1)定义了团队各种成员应有的习惯。这个月,我们将较深入地研究联合(joint)实践,因为它将一个团队中的所有成员都聚集在一起。下个月,我们将讨论开发(development)实践,它形成了最初的 12 个 XP 实践的主体。再下个月,我们将讨论客户(customer)和管理(management)实践。这将使您更好地理解用 XP 开发软件意味着什么。
XP 的价值使 XP 灵活。XP 的实践没有定义 XP . . . XP 是由它的规则定义的。
他们使用 Alistair Cockburn 的游戏作类比,接着描述了“交战规则”,该规则说明了进行有效的软件开发所需的环境。然后他们讨论了“游戏规则”,它定义“交战规则”框架内每一分钟的活动和规则。他们建议:
“游戏规则”确保 XP 的唯一性。
遵守“游戏规则”就是极端编程。
遵守“游戏规则”和“交战规则”就是极端软件开发。
XP 实践很重要,因为它们强制了一些行为,这些行为增加了团队生产出与团队成员期望值相符的优秀软件的可能性。但 XP 不只是如此。它不仅是编程,还扩展至包括整个软件开发过程。修订的 XP 实践考虑到了这一点,它们要求所涉及的每个人都有不同的行为。
XP 实践的四个类别正逐渐变得清晰。一个团队中的每个子团队有一个集合,而且还有将三个子团队聚集起来的集合。最初 12 个实践中的大多数都在开发团队集合中,但有些可能会去掉。有些名称已改变,主要因为最初的名称要么不太合适,要么没有反映它们应有的意义。有些实践没有列在最初 12 个实践的列表中。在下一节(以及以后的文章)中,在每个名称后,我将附加说明该实践是新的、未更改的还是到最初名称的映射。请注意这些名称还会有更改,但原则或许不变。
迭代(新)
使用 XP 的人经常谈论项目的“节奏”。这个节奏有不同的级别,但迭代的节奏级别简直就象心脏跳动那样快。每隔一到三个星期,团队就交付具有客户要求的新功能的工作系统。那是基本思想。但人们不习惯以这种方式创建软件。大多数方法注重在编写代码之前先进行大量的工作。XP 要求您编写代码、让人们使用它,并让他们的反馈把握项目的方向(我们将在以后的文章中更详细地讨论这个概念)。
不反思您正做的工作就继续做下去会使您陷入重复失败的境地。团队中每人都最好反思他自己的工作以及他吸取的经验和教训,然后与团队中其他成员分享反思的结果。正如我和 Chris Collins 在我们的 XP2001 论文 Adaptation: XP Style(请参阅参考资料)中所概述的那样,我正讨论的个人行为是自省。回顾时,您公开您的自省。
消除业务/IT 团队的隔阂
将企业需求转变成它实际使用的软件是 IT 世界中最难的问题之一。让技术人员和业务人员进行持续且坦诚的交流是一个令人畏缩的挑战。尽管大多数公司在口头上夸夸其谈,但他们的行为表明他们实际不重视交流。他们到处设置障碍。信息就无法流通。拉帮结派的斗争使他们偏离了需要完成的工作。人们对于其他组所做的工作一无所知。项目的启动遥遥无期,而为了似乎永远也不可能达到的目标,这些项目艰难地前进着,而且它们会多次中途夭折。
这种内耗使大多数软件项目产生令人不满意的结果就不足为奇了。事实上,我很惊奇的是,在以这种方法进行工作的环境中,有些项目实际上还是成功了。那么我们要如何修正呢?除了组织性变革以外不需要进行任何更改。逐步变革不会起作用,虽然我愿意帮助组织设法以这种方式进行变革。这种变革的主要催化剂是一种根本不同的软件开发方法,它要求并使软件开发团队的业务成员和技术成员合作。我想那就是 XP 的真正意义所在。
XP 不仅仅是关于编程的。它是关于根本的、改变生活的组织性变革。我相信这是治愈滋生在全体 IT 团队中疾病的唯一良药。
下个月
本月的专栏文章概述了 XP 的联合实践,它可以帮助您建立一个团队,而不是一些争论不休的小组。下个月我们将涉及程序员的实践。那些实践告诉程序员要创建一个团队想要的系统,每天要完成的工作。结对编程是不是听起来很奇怪,或甚至很可笑?持续集成是不是听起来不可能?下个月您会了解到它们的含义,以及了解它们并不是您想象的那样疯狂的想法。
参考资料
单击本文顶部或底部的讨论,参与有关本文的论坛。
请阅读最初的“XP distilled”(developerWorks,2001 年 3 月)。
Jim Highsmith 在撒丁岛的 XP2002 会议上所作的演讲 Agile Methodologies: Problems, Principles, and Practices(PDF)描述了软件中优化和探索之间的区别。
Joshua Kerievsky 的 XP2001 论文 Continuous Learning (PDF)非常优秀。坚持学习可以成为第五个 XP 价值。
请参阅 Ken Auer、Erik Meade 和 Gareth Reeves 合著的 The Rules of XP。它还未发表,请留意。
Chris Collins 和 Roy Miller 合著了 Adaptation: XP Style(PDF)。
Standish Group 的这篇报道详细描述了有关软件项目成功率的残酷事实。(另外,请阅读 Keeping CHAOS quiet (PDF) 中有关 CHAOS 的秘密。)
JUnit.org 是由 Erich Gamma 和 Kent Beck 开发的流行测试框架的丰富资源。
请访问 Xprogramming.com 以优先获取有关极端编程的信息。
如果您想要了解有关 XP 的详细信息,请务必挑选一本本文所参考的书籍:
William C. Wake 编著的 Extreme Programming Explored
Ken Auer 和 Roy Miller 编著的 Extreme Programming Applied: Playing to Win
Kent Beck 和 Martin Fowler 编著的 Planning Extreme Programming
Kent Beck 编著的 Extreme Programming Explained: Embrace Change
在 developerWorks Java 技术专区可以找到几百篇 Java 技术的相关参考资料。
关于作者
Roy W. Miller 作为软件开发人员和技术顾问已有差不多十年了,一开始他在 Andersen Consulting(现在是 Accenture)工作,目前在位于北卡罗来那州的 RoleModel Software, Inc. 工作。他曾经使用过重量级方法和灵活方法(包括 XP)。他是 Addison-Wesley 出版的 XP 系列书籍 Extreme Programming Applied: Playing to Win 的合著者,而且目前正在编写有关复杂性、新兴技术和软件开发的书籍。可以通过 rmiller@rolemodelsoft.com 或 roy@roywmiller.com 与 Roy 联系。可以访问他的个人网站 www.roywmiller.com。
作者: cinc 时间: 2002-10-21 17:08 标题: [转帖]揭开极端编程的神秘面纱:重访“XP 精华”,第 1 部分 IBM 中文网站才翻译了 第一部分