Roy W. Miller（rmiller@rolemodelsoft.com）
软件开发人员，RoleModel Software，Inc.
2003 年 3 月
我没有计算机科学学位，因此我无法从直接亲身体验的角度来讨论大多数程序员所获得的“传统的”培训。更确切地说，我曾经同许多程序员和业务人员在多个软件开发项目中一起合作过。因此，我想我可以明智地说出当他们设法开发软件时是如何想的，以及是如何做的。让我首先谈论一下程序员，因为我就是其中的一员。
了解编程
我的父亲是位医生。他曾多次告诉我（我都记不清次数了），“去读医科学校，毕业后去实习，在实习中学着做医生。”我想，大多数计算机科学专业的毕业生也都类似。他们带着很多理论知识（其中一些是好的且有帮助的）离开了学校，但是对于如何编写好的代码却所知不多。由于我没有计算机科学学位，因此也就没有大多数理论知识。有时候这会让我很伤心，但大多数时候不会。
当我开始编程的时候，我 22 岁，刚刚走出学校。Andersen Consulting 对我进行了培训，老师们将我领进了门，而我好不容易才“蒙混”过关。大多数人都经历过这个过程：他们在工作的过程中学习编程，并且大多数人通常都身处于公司环境。遗憾的是，他们的师傅和老师也是这样过来的。习惯、术语和偏好（大多数都不是很好的）就这样代代相传下来。最后，大多程序员学会了如何尽可能快的完成工作。
程序员中似乎存在着四种行为模式：
程序员不知道如何同业务决策者很好地交流。 程序员期望出现教科书式的问题。 程序员喜欢独自工作。 程序员认为测试是编码后的活动。 业务培训
业务人员有自己的培训，但是它同程序员接受的培训有着巨大的差别。但结果是类似的：业务人员习惯于用危及其软件项目的方式工作。
进行业务的费用
负责预算的业务人员整天都在计算业务费用，但他们似乎不知道如何考虑为什么他们需要软件。通常，他们对于特性的业务优先级，或者那些特性对其业务的货币价值（直接的或间接的）并没有实际的概念。对于较低级别的项目管理人员和公司领导而言，这是可以理解的。
在许多公司环境（尤其是大公司）中，很容易看到底层下属如何看待高层管理人员通过规章制度进行的管理。高层传达一些命令，只要求底层下属执行它。负责管理项目的人只知去做，而不知为何去做。通常公司并不鼓励他们进行思考。因此，当下达了一项命令时，他们只需服从，而为什么他们应该或不应该做什么的详情只能是那些企业高层人事考虑的事情。
但是，恐怕并不是高层的英明人士做出的决策总是正确的。许多业务决策都是根据什么“热门”或者什么最能引起新闻界的关注而决定的。“如果所有其它公司都在做，我们也应该做”。这称为“随大流效应”。问题在于企业领导对软件的认识是错误的。他们认为它是费用开销，而不是花费一些费用的资产。他们认为它是“无可避免之灾祸”，或者是生产的手段，而不是策略优势。
我不希望参与
据说业务人员有进一步“参与”软件项目的趋势。通常他们根本不太参与这些项目。软件开发人员可能会偶尔询问他们一些问题，但是该过程真的没什么意义。项目通常是从分析设计开始，即使在开发团队不使用瀑布模型变体的情况下也是这样。这是最需要业务人员参与发言的阶段。但是技术团队通常都希望业务人员能回答所有问题。“现在就告诉我，这个软件一年以内需要做什么。我们会告诉您，您可以在将来改变您的想法，但是这只是开玩笑。您现在做的任何决定都是一锤定音的。”
难怪业务人员会很紧张。他们不得不就他们不知道的东西进行明确的陈述。这使他们几乎不可避免地与 IT 团队进行某种达尔文式的争论，在这一过程中，业务人员把材料往墙上一扔，希望开发人员把问题解决。协调的创新活动没有秘方，是吗？
企业“拔河”
谁都有强烈的抵制约束的心理。作为项目管理人员，您的老板把上述一大堆难题都推给您处理，而他却不管了。您必须取悦于每个人，包括您的系统必须同其打交道的其它部门的职员，不管他们是高级职员还是普通职员。您肯定会在什么地方得罪某些人，并且使某些人不满意。
打破模式
随着时间的推移，大多数公司都“陷入”了这种行为。得到的结果是软件项目使人疲惫不堪，可是当项目完成时，通常都不会使任何人满意。
那它不是无可救药了吗？您不是永远都陷于困境了吗？是的，如果您还不开始采取其它行动的话。我不是思维过程的专家；我只能提供一些经验之谈。有时候，我认为您应当先尝试着换一种思路，然后影响您的行为。但是，大多数时候这对我不起作用。我必须先采取不同的行动。我的思路才能随之而来。对我而言，最佳的途径是在采取不同的行动时有意识地改变我思考问题的方法。这就是 XP 可以帮助您的所在。
XP 需要有别于标准培训的行为。要了解由其产生的最佳可能结果，以及判断其是否适合于您和您的组织，唯一的方法就是在一段时间内使用尽可能多的（最好是全部）实践。让您和您的团队全身心地投入其中以探究它们的有效性，并且使公司里从事开发软件的人能养成更良好的习惯。
XP 实践可以帮助人们改变思维，但是只有当他们开始使用这些实践时才会有帮助。这需要转变信念，或者至少需要暂缓下结论。XP 并不“普通”，因此刚开始时您会觉得很难使用。也许它永远都不会适合于您。也许它永远都不会适合于您的公司，但是，如果不尝试一下，您就不会确切地知道这一点。进行实验是比较妥当的。试着花几个星期使用 XP，在此过程中要牢记两点：
不要放弃，即使您感到孤单或不友好。 自觉地用不同的思路看待您正在做的工作。 第一项承诺是显而易见的。第二项承诺需要进行一些说明。针对程序员的 XP 实践（如结对编程，pair programming）和针对业务人员的 XP 实践（如告知详情）需要不同的思路，以便更好地工作。不可能刚开始就会用不同的思路思考问题，但是您可以假装这样做。
优秀的伪装者
当您遇到一项不熟悉的实践时，您需要以两种方式假装：
假装您喜欢这个任务 — 假装您真的喜欢它。 假装您是用该实践希望的不同思路进行思考。 当然，如果您确实已喜欢该实践，则您无须假装。但是如果您不喜欢它，那么必须坐下来研究一下，就好象您确实喜欢一样。时时刻刻都要使用该实践。假装没有它您简直不能编码了。如果您实在憎恨这个实践（大多数程序员不是喜爱就是憎恨“有争议的”实践，如结对编程），如果必需的话，发泄一下，但是要克服它。暂且不去怀疑，无论如何都要去做。这是考验意志的行为。如果只因为您的偏见或者是您的意向或经验就让您生气或采取抵制行为，那么最好不要那样做。
那么，现在为什么要假装用不同的思路进行思考？所言极是。Ron Jeffries 在一篇文章中讲述这一问题，而他对它甚至不了解。他谈论了 YAGNI（“You Aren't Gonna Need It，您不会需要它”）实践，来提醒我们需要换一种思路进行思考：
作为技术专家，我们中的大多数人都对处理复杂性的能力洋洋自得，并且都喜爱了解最新的东西。我们需要提醒的是，我们的工作是生成简单、可维护的程序，很快就能得到，而不是构建巨大的企业软件以支持少数 Web 页面。 他还说，YAGNI 提醒我们，作为程序员，在没有搞清楚是否需要某些特性前不要向软件添加这些特性。为什么呢？因为这一行为实际上应当是由业务推动的，并且因为我们经常会对以后我们将“需要”什么作出错误的判断，如果我们正在使用其它相当好的实践，那么当将来我们需要某些功能时，就可以对其进行添加，而不需要额外的费用。YAGNI 让我们一直专注于简易性。这是 XP 所需的新思路的一部分。下面是适合于程序员的一些其它示例：
结对编程需要您知道“三个臭皮匠，顶得上一个诸葛亮”。私下里认为其他人是傻瓜是不公平的。他有知识差距吗？如果有就弥补差距，别在私下里贬低他。您永远都不会知道“傻瓜”也可能会看到一些您未察觉的东西，甚至还会有高见。
测试优先的开发需要您有远见。在只有一个类时，您当然可以叫嚷着不需要测试。其代码相当简单。但是，当您有 100 个类，并且突然出现一个错误时，会发生什么呢？进行测试可以以极快的速度将错误分离出来。不进行测试则会让您经受数小时的调试煎熬。首先编写测试还需要您接受一个令您不快的事实：您并非全才或者是无所不知的。
告知详情实践需要您坚信，您的顾客将驱动这个软件，我是指真正地驱动它。您不能粉饰某些东西，无论假想的特性可能有多酷。 下面是几个针对业务人员的示例：
告知详情需要您坚信，您可以并且也应该驱动软件。您必须这样想，“这是我的软件。我最好告诉人家它应该做什么。”
频繁的发行版需要您认为“只有更好没有最好”，来自实际用户的反馈是“驾御”项目使之朝着您最终希望的软件方向进行开发的最佳途径。您必须这样想，在软件完成前将其发布给真正需要的人是很不错的，尽管有些部分可能看上去仍然很不完善。
用户测试需要您坚信，让您花费明显是额外的工作来编写这些测试是值得的。是的，它将花费一些时间。您希望项目成功吗？那么，当您的开发人员“完成”某个特性时，让他们进行测试，以证明您对此很满意。不要似是而非地推诿不知情。 下面是一个示例，展示了所有这些假装可能看起来象什么。如果您是程序员，让用户驱动，即使您对其很反感。除非有用户对您“告知详情”，告诉您做什么，并且有了告诉您何时完成的验收测试，否则不要编写一丁点的代码。如果您不同意用户的明智要求，只需提一个问题，让用户去考虑他正在做什么。不要信口开河地评论他的需求是多么的愚蠢。要求团队中的每位开发人员都做到这一点。如果您是客户，不要匆忙地给出模糊的定义，并且希望程序员把他们解释清楚。尽您所能编写最好的需求，要知道，您可以要求获得稍后改变想法的权利。因此故意就某件事改变想法 — 这没什么大不了。如果您是程序员，当您的客户改变了想法时，不要讨价还价，而是对其做出良好的反应 — 假装它正是您所希望的。
这种假装将开始培养您的习惯。这些习惯将改变您的思维。因而您会开始觉得它们很自然。
专注于价值
最后要做的事情看起来简直疯狂至极。您团队的业务人员要求您尽力量化（用美元计）您要求的每个特性（或更可能是每组特性）的商业价值。这是针对软件的商业案例，可能值得在本专栏中再写另一篇文章来介绍（我将让读者来决定写还是不写，因此请提供您的意见）。目前，我简要地谈论我说的是什么意思。对于您的团队正在开发的软件的每个特性，您应当试着回答以下两个问题：
这个特性将提供哪些需要的价值（即，用户的哪些成本将因此而降低，或者它会提高哪些收入）？
实现该特性需要多少花费？ 并不是始终都能回答这些问题，我第一个同意这种观点。不能回答这些问题时，别紧张，但是在您尝试之前，千万别假想不能回答这些问题。作为一名特性的请求者，对您而言，理解为什么需要它们是很重要的。有人会购买这个软件。他们应该知道花钱后他们会获得什么。
脑筋转弯
利用 XP 开发软件通常需要您改变思路，但是有几点新的思维方式特别怪异。请密切注意以下几点：
客户需要时时刻刻驱动软件开发，而不只是开发人员让他这样做的时候才做。开发人员需要将客户看作其团队的一部分。客户需要将他们自己看作是团队的一部分。
客户应当由业务需求来驱动，而不是来自上司的武断压力。
客户必须将业务需求转换成非常具体的特性需求。否则，程序员将不知道如何编码。
客户（可能在其他人的帮助下）必须指定验收测试，这些验收测试告知开发人员何时完成每个需求。
如果客户没有详细地告诉开发人员要添加特性，开发人员就不能这样做。
开发人员必须时时刻刻都要编写程序员测试。 这几点完全不同。它们都需要纪律约束。大多数情况下，纪律所产生的回报将是不断提高项目的成功率。坚持您的立场。在我将来的文章中，我将讲述有关如何改变思维模式的具体建议。
改变必须影响高层
上一节的第二点可能会让您有点难于理解。“客户应当由业务需求来驱动，而不是来自上司的武断压力。”我已经听到您在发牢骚了，“算了吧，Roy。请别那么天真了。上司始终会给您压力的。压力是一级加给一级的。”不错，但是必须改变对此的反应。
还记得程序员实践吗？如果客户要求的内容是将进行的一次迭代开发内容的两倍，而且他是昨天提出的，那么程序员能说什么呢？说不，或者是说好，然后进行修改。他们肯定不同意一个星期工作 100 小时。业务人员也需要开始进行同样的工作。这肯定会一路波及到组织的高层。每个人都需要这样采取行动。其它任何事情都是不切实际的。
我很乐意说要从高层开始改变，但是通常都不是这样。有时候改变必须自下进行。之所以出现这种方式，是因为下属不希望再向上司说谎，以便减轻短期压力。否则，在您无法交付产品时，您就得把怒气藏在自己肚子里。说实话：“不，我们不能那样做。我认为，我们可以这样做，那才是我们将做的。”这样可能会让您惹上更大麻烦。我不希望那发生。但是正如 Martin Fowler 所说的，“如果您不能改变您的组织，那么就改变它。”找出其它切合实际的方法。事物没有发生改变的唯一原因是我们拒绝对其进行改变。
下个月
客户角色是 XP 最有效的方面，并且客户角色与大多数的 IT 组织无关。它的方法过于“非正规”且过于“强制性”，以致于大多数人都觉得不舒服。但是，它对于 XP 项目的成功是至关重要的。没有客户的 XP 项目注定会远远偏离用户在项目结束时希望看到的最终结果。下个月，我们将讨论，对于 XP 团队而言，需要在心理和组织上进行怎样不同的改变以便赢得客户。
参考资料
参与有关本文的论坛。（也可以单击文章顶部或底部的讨论以访问论坛。）
在 Demystifying Extreme Programming 系列中阅读所有文章。
请阅读最早的“XP distilled”（developerWorks，2001 年 3 月）。
“Extreme Programming with IBM VisualAge for Java”（developerWorks，2001 年 4 月）描述了一些利用领先的 Java IDE 使用 XP 的最佳实践。
请参阅由 Ron Jeffries 所著的“Misconceptions about XP”以获得他对有关 XP 思想的一些想法。
这是另一篇同样由 Ron 所著的有关假装益处的好文章：“Pretend You're Not Afraid。”
在 developerWorks Java 技术专区可找到数百篇其它 Java 相关技术的参考资料。 如果您学习更多有关 XP 的知识，请务必查阅以下书籍：
Extreme Programming Explored，William Wake 著（Addison-Wesley，2001 年）
Extreme Programming Applied: Playing to Win，Ken Auer 和 Roy Miller 著（Addison-Wesley，2001 年）
Planning Extreme Programming，Kent Beck 和 Martin Fowler 著（Addison-Wesley，2000 年）
Extreme Programming Explained: Embrace Change，Kent Beck 著（Addison-Wesley，1999 年）
关于作者Roy W. Miller 作为一名软件开发人员和技术顾问差不多 10 年了，最初为 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。
