了解驱动软件项目意味着什么
级别：初级
Roy W. Miller（rmiller@rolemodelsoft.com）
软件开发人员，RoleModel Software, Inc.
2003 年 4 月
在上次的专栏文章中，您了解了让 XP 发挥作用所需要的心态。团队的每个人都必须改变他们的思维方式。本文探讨了为什么客户（业务决策制定者）似乎要在这一转变中经历最困难的时期。除非他们改变思维方式并参与到软件项目中，否则最终结果永远不会令人满意。
Roy 欢迎您提出要讨论的主题或 XP 领域内的其它任何事情。请在关于本文的论坛中与作者和其他读者分享您的想法（您也可以单击本文顶部或底部的“讨论”来访问论坛）。
XP 需要业务人员的思维方式有一个深刻的转变。在过去 30 年的时间里，软件开发方法学已经使企业中非技术人员习惯于按某些方式思考和行动。遗憾的是，传统方法学是错的，因为它们并不总是产生这些人想要的结果：在项目结束时满足其需要的软件、有较长有用期的软件和及时交付的软件。
讨论的是一个很苛刻的要求。令人遗憾的事实是传统软件开发始终不能及时交付。其中的一个主要原因人们可能根本不会想到：客户没有做他们的工作。在我进行说明之前，您需要理解 XP 项目的“客户”有哪些特征。
不可能实现的梦想？
XP 描述了一个美好的情形。客户（或达成一致的一组人）告诉程序员编写什么样的软件。客户标识某种特性并给出为什么这很有必要的理由。理想情况下，客户会量化该特性 — 它的最低要求是什么？尽管量化一种特性并非总是可能的，但却始终是值得一试的目标。如果它是不可能的，不要让这一点阻止您生产优秀的软件，但不要假定它始终都是不可能的。试试看。
软件应该由业务需求来驱动，但通常的情况却是技术人员领导项目。他们构建他们想构建的东西，这通常是因为客户在项目一开始时就擅离职守，或者是程序员在某些时刻放弃与业务人员交谈。为什么会这样？软件开发的历史已经使所有参与的人都习惯以某些方式思考和行动。太多的情况下，结果是失望、窘迫和挫折。
深陷于泰勒制
Frederick W. Taylor（请参阅 10 月份专栏文章的侧栏）在 19 世纪 80 年代是一家机械工厂的工长，在此后超过三十年的时间里他一直在研究工厂生产。他注意到一个最重要的特征：低效。他开始通过寻找做任何工作的“唯一最佳方法”，以及告诉管理人员如何为他们操作的每一环节找到最佳方法的系统，来消除低效。到 20 世纪 50 年代为止，泰勒制（Taylorism）是主要的管理哲学。企业的软件开发在那个十年里首次登场，经营企业的人作出了一个看似不错的假定。他们假定适用于其它生产类型的相同管理原则 — 考虑工作的相同方式 — 也适用于软件。
考虑一下汽车装配线。零件和原料从这一头进去，装配好的汽车从另一头出来。您最不想看到的事是：装配线上的每个人聚在一起决定改为造自行车。装配线上没有机会进行创造。您真正想要的是可预见性 — 您希望装配线每次运行都完全相同。在这一领域，问题与解决方案始终是相同的，而您可以有效地优化该过程。当然，一旦您把事情优化并使其平稳运行，那么“变化”就变成了敌人。即使环境在底层是动态的，人们也会费尽心力地使它看上去可预见。
“效率”的这种模型根本不适合软件。对于软件，问题始终是不同的。它可能类似于您以前看到过的，但决不是相同的。这就意味着解决方案不可能相同。不可能只遵守手册就能获得正确的答案。如果问题不同而且解决方案不同，那么您不必考虑优化。它根本就不存在。变化是不断的。
在某种程度上，您可以说软件开发团队（对于内部或外部用户）受困于装配线式的思维方式。泰勒制给企业文化打下了深深的烙印。担当软件项目客户的人通常是管理用户群的人，或者本身就是用户。如果他们管理用户，那他们就是经理。如果他们本身就是用户，那他们就处于由经理们控制的环境中。无论哪种情况，装配线式思维方式都是标准。
参与软件开发的业务人员已经开始相信他们的角色主要是前端的：他们在开发周期的早期为程序员指定一组详尽且不变的需求，然后停下来等待结果。当然，他们应该有对过程的控制权。毕竟，他们正为它付出努力，他们正为它提供需求，而且完成的产品必须使他们满意。但业务极少驱动软件。技术人员很快会告诉业务人员软件是“软”的，但同样是这些技术人员却抵制变化，因为变化是痛苦的和代价很高的。程序员不希望没等到软件变得完美就发布它，而业务人员则不希望新软件给用户造成过多破坏，因此双方共同使得发行不及时 — 有时是在项目开始的数年之后才发行。
在这一周期结束时最终得到的并不是企业需要的软件 — 它是企业在项目开始时认为它所需要的。大多数客户都没有兴趣购买这样的“陈年”软件，但这却是他们所得到的。技术人员不希望交付这样的软件，但他们认为自己别无选择。每个人都感到挫折、疲倦、愤怒和上当受骗。
参与创作软件的每个人在这一过程的某些环节都妥协过。或许是为了保住饭碗或使冲突减到最小。或许是因为宿命论悄然涌上心头并在您毫无察觉的情况下影响了您。或许是因为懒惰。无论是什么，每个人都做了一个糟糕的决定。每个人都觉得使事情保持现状好过尝试使事情有所不同。遗憾的是，只有改变才能使事情做得更好。我们需要回到那条路上。出发的最佳地点之一就是客户行为。
学会驱动
软件开发在过去三十年里已经是非常一致。当然，在其发展过程中有过一些改进，但基本主题是相同的：
用户并不真正知道他们想要什么，所以开发人员必须告诉他们以便生产软件。
变化有害，所以应不惜一切代价来禁止它。
禁止变化的方法是在一开始把所有的事情写在纸上，找些人在上面签字核准，然后照这个计划执行。
在一开始就定义所有需求的唯一方法是让业务人员提出一组需求，在末期试用完成的产品以确认每样事情都和这些需求一致，而在中期则置身事外。
结果是大多数软件项目生产（如果它们确实生产了某些东西）的是某个人在开始时认为他想要的软件，而不是软件用户在末期最终想要的。我们最终得到的是我们根本不想要的东西，但似乎没有办法能走出这个怪圈。管理人员不能只是规定变化。这在过去从未奏效，将来也不会。为什么我们会深陷于此，我们该做些什么？
首先，身为 XP 客户的人需要起到客户的作用。什么人能成为客户？通常是具有足够领域和最终用户知识、能对特性的优先级作出困难决定的人。他可能是了解用户真正需要的超级用户。他可能是了解市场需求和竞争对手情况的市场销售人员。他一般不会是顺理成章就获得这一职位的经理，尽管这也许总比没有客户要好。必须有人接受该职位并承诺做好这项工作。
第二，任何接受客户职位的人都必须把自己当作团队的一份子。他必须愿意花必要的时间和团队其他成员一起生产正确的软件。客户不能预先说明需求后就离开，若软件失败则依靠难以自圆其说的推诿伎俩来为自己掩护。客户不能在团队其他人叫他离开叫他不要制造麻烦时勉强同意。他不是在制造麻烦；他是在为团队指明方向。
第三，客户必须暂时把怀疑放到一旁，尽力表现得好象让团队探索生产最终产品的方法会比预先规定每一项事情取得更好的结果。这对于程序员和客户都很难。程序员希望不被方法的每一步所困扰就能生产出优秀的软件。他们认为预先说明每项事情并且不背离规范就能确保这一点。客户也担心。他们希望写进每一个可能的需求（包括他们并不真正需要的需求），以便在不得不放弃时给自己留有更多商议的余地。这些观点没有一条有助于团队生产优秀软件。客户需要说明软件真正需要什么，什么是最重要的。然后，他们必须相信程序员（是的，很难做到的一件事）会朝着那个目标坚持不懈地工作。当然，程序员必须通过言出必行来赢得更多信任。这对每个人都有风险，但却是做事的典型方法。采用 XP，风险是显而易见的，而不是被成堆的纸张和承诺所隐藏。
第四，客户必须改变他们考虑软件的方式。如何才能知道真正需要什么软件？我只知道两种方法：猜测并指望猜对，或者一点一点地交付软件并在更好地理解了客户的真正需要时对软件进行调整。花大量时间让人们讨论他们需要的软件而不实际使用软件只是第一种方法的翻版。人就是人。让他们使用计算机并不能改变这一点。真正理解需求的唯一方法是有一个运行的示例，两方的团队成员都可以用它找到共同点：“这里，看到这个了吗？那根本就不是我想要的。那个东西的位置真是糟透了，非常碍事！那里可以更好些。不过这个，这个真是太好了。”反馈是非常重要的，所以团队应及早且经常地发表反馈。坐等软件变得“完美”只会推迟您猜错的坏消息。
如果这就是客户所要做的全部，那有什么问题？事情不止那么简单。事实上，它太难了，以至于大多数人都不愿做它。即使他们愿意做，也不能做。大多数组织在建立时都不允许这样的过程发生。使用 XP 制作软件会遇到强大的抵制，因为一些有权利的人对于这是否明智有正统的考虑 — 并且因为一些有权利的人很顽固。
组织可能成为问题
如果 XP 客户所在的组织不同意使用 XP，那么他不能做他的工作。这意味着两件事情：
必须存在 XP 团队以便将客户包括在内。
客户的上司必须让客户成为该团队的一部分。
团队必须在 XP 客户能够做他的工作之前就在使用 XP。如果团队在假装使用 XP，或限制客户充当那一角色的能力，则 XP 不会起作用。遗憾的是，大多数组织的建立机制与 XP 是对立的，这种对立或是有意识的或是自然形成的。除非组织中至少有一小部分愿意尝试 XP，否则它不会起作用。但您可以从小做起。一位客户，几个开发人员和一个小小的应用程序就是您需要的全部。如果那个团队生产出优秀的产品，则有可能其他团队将采取一些那样的行为。
如果 XP 团队需要某位客户，而该预期客户的上司却不允许他在该团队上花任何时间，那会怎么样？那样的话，这个项目从一开始就注定要失败。如果团队需要客户参与计划会议或试用最新的应用程序，但该客户却始终忙于填写 A-324-XYZ 报告以应付即将到来的每两周一次的形势通告会，那么该团队将不能交付他们所承诺的东西。没有某位相似领域的专家，您就无法有效地研究，而那位专家就是客户。组织中控制客户时间的人必须放弃部分要求。
大多数组织的建立机制使这几乎不可能。那么我们就永远深陷下去吗？也许，但我不认为我们必须如此。改变这种情形只需要勇气。
进行改变的勇气
坦率地讲，我认为有三个原因共同促使公司的 IT 人员陷入这个怪圈：
习惯
懦弱
缺乏远见
打破习惯是很难的。您甚至没有考虑过这么做。习惯是您生活中很自然的一部分，即使某些清醒的情况下您知道不应那样行事。这就是为什么人们会抽烟、暴食或对着他们的孩子大喊大叫。一旦您有了某种习惯，打破它就需要有意识的努力。大多数公司生产软件的方法直接来源于该公司各成员的习惯。
有些公司的很多人都没有胆量。当事情真正有麻烦，并且他们真正意识到组织走向了错误方向时，他们要么屈服要么走人。此刻，如果留在某个组织中的日子确实很糟糕，而且您尽了最大努力也无法改善它，那就可能是离开的时候了，对于这种情况，我将第一个赞成。但一看到阻力就逃跑并不是解决问题的办法。您是在逃避必然性。您跑到别的某个地方，在那里相似的问题突然再次出现，而您又会离开那个新地方。组织不会改变有什么奇怪呢？每个人都跑开而使它们支离破碎。
我们需要的是新一代的公司领导（既有技术型也有非技术型），他们将站起来说真话 — 即使要面对传统和习惯。缓和与退却的战略根本不起作用。非技术型领导必须担当 XP 团队的客户，并且如有必要应该用全部时间参与。技术型领导必须愿意放弃控制规范的权利，并探索制作优秀软件的方法。
我们需要更多勇敢的人，但光有勇气没有远见也不能成事。对理想的状况有远见并有勇气尝试达到那一状况，我们需要的是这样的人。在真正的 XP 方式中，这种远见在我们朝向它前进时会改变，但我们必须前进。
软件开发让人痛苦而产品成为垃圾，这是因为您我允许它这样。这是我们的过失。责备“那些人”或“那个组织”起不了任何作用，只会无限期延长这一循环。我们需要痛定思痛，要求变革，并首先自己做好表率。做到那一点非常困难。最后，一言以蔽之：您是希望混日子领工资，还是希望改变世界？
