知道存在问题，也愿意设法解决它，但误解了要解决的问题

    有时人们知道他们有问题，而且愿意设法解决它，即使那意味要尝试新事物。但他们尝试解决错误的问题。例如，他们设法解决生产问题，假设（或许是无意的）开发软件就象在装配线上生产产品。让装配线上的工人不按照装配的有效次序和方法进行操作，这样做毫无意义。软件之所以不同是因为它是新生事物。Jim Highsmith 在 XP2002 的演讲 Agile Methodologies: Problems, Principles, and Practices（请参阅参考资料）中，描述了软件中优化和探索之间的区别。软件中，我们通常探索新领域，并做一些以前未做过的事情。这使软件开发成为需要不同解决方案的完全不同的一类问题。

    如果您设法使软件开发过程过度“机械化”或过多控制此过程，那么您将对此失去控制。我希望本专栏即将发表的文章会有助于清晰地阐明您正试图解决的软件开发问题。

    知道存在问题，也愿意设法解决它，但受现状约束

    最后，人们可能知道存在问题，愿意去解决它，也理解了正设法解决的问题，但在组织中却无法执行。这个问题很令人沮丧，而且解决起来也很困难，但未必不可能。遗憾的是，解决它需要的勇气却不是大多数人所能拥有的。有时为了进行变革，您不得不去冒犯某些人。我知道说比做容易，但如果您是一个组织中的成员，该组织的领导层拒绝解决危害组织健康发展的问题，那么您可以做如下选择：要么全力以赴设法进行变革，要么在该组织不堪自身重负而关门大吉之前离开。本专栏中的这篇文章及以后的文章会向您提供一些好的意见，以帮助您克服通常阻碍组织内新事物（特别是 XP）发展的阻力。

    一个解决方案：灵活方法

    在某种程度上，“极端编程”这个名称就不太适宜。大多数人听到 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 的核心价值。这些价值在去年没有发生实际的更改。我仍用这种方法概述了这些价值：

    . 交流：项目的问题往往可以追溯到某人在某一时刻没有和其他人一起商量某些重要问题上。使用 XP，不交流几乎不可能。

    . 简单性：XP 建议：在对于过程和编写代码起作用的方面，总是做最简单的事情。按照 Kent 的说法，“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 为主题的论文草稿中说道：

    Extreme Programming Explained 中最严重的错误是隐含的假设，即您的技术团队只为一个客户提供服务。

    在同一篇论文的后面，他说道：

    就象“客户以同一种声音告知团队”中的那样，使用“团队”一词时，就会提到程序员，这使得在 XP Explained（以及随后的论文和交谈）中，这个问题变得复杂了。这个用法总是困扰我，但我不知道对此该做什么。

    新的实践和集中于一个团队的方针设法解决那个问题。以对软件开发带来组织性变革为目标的任何方法都必须弥合 IT 团队和业务团队之间的裂缝。存在裂缝的最主要原因之一首先是因为创建软件涉及的人员不属于一个团队。那么这样一个团队看上去会象什么呢？在同一篇论文中，Kent 使用了一个三条腿的凳子作为比喻。开发团队是程序员，而业务（或客户）团队是分析员、用户、测试员等等。第三条腿是管理团队，它由回答如下问题的人员组成：

    . 项目如何开始？
    . 如何增加、减少或终止投资？
    . 如何解决业务和开发团队不能解决的争论？
    . 在这个团队和需要完成的所有其它项目之间如何设置相对优先级？
   
    所以现在我们将一个团队定义为三个子团队：程序员、客户和管理。