【IT168 技术文章】
了解驱动软件项目意味着什么
XP 需要业务人员的思维方式有一个深刻的转变。在过去 30 年的时间里，软件开发方法学已经使企业中非技术人员习惯于按某些方式思考和行动。遗憾的是，传统方法学是错的，因为它们并不总是产生这些人想要的结果：在项目结束时满足其需要的软件、有较长有用期的软件和及时交付的软件。
讨论的是一个很苛刻的要求。令人遗憾的事实是传统软件开发始终不能及时交付。其中的一个主要原因人们可能根本不会想到：客户没有做他们的工作。在我进行说明之前，您需要理解 XP 项目的“客户”有哪些特征。
不可能实现的梦想？
XP 描述了一个美好的情形。客户（或达成一致的一组人）告诉程序员编写什么样的软件。客户标识某种特性并给出为什么这很有必要的理由。理想情况下，客户会量化该特性 — 它的最低要求是什么？尽管量化一种特性并非总是可能的，但却始终是值得一试的目标。如果它是不可能的，不要让这一点阻止您生产优秀的软件，但不要假定它始终都是不可能的。试试看。
软件应该由业务需求来驱动，但通常的情况却是技术人员领导项目。他们构建他们想构建的东西，这通常是因为客户在项目一开始时就擅离职守，或者是程序员在某些时刻放弃与业务人员交谈。为什么会这样？软件开发的历史已经使所有参与的人都习惯以某些方式思考和行动。太多的情况下，结果是失望、窘迫和挫折。
深陷于泰勒制
Frederick W. Taylor在 19 世纪 80 年代是一家机械工厂的工长，在此后超过三十年的时间里他一直在研究工厂生产。他注意到一个最重要的特征：低效。他开始通过寻找做任何工作的“唯一非常好的方法”，以及告诉管理人员如何为他们操作的每一环节找到非常好的方法的系统，来消除低效。到 20 世纪 50 年代为止，泰勒制（Taylorism）是主要的管理哲学。企业的软件开发在那个十年里首次登场，经营企业的人作出了一个看似不错的假定。他们假定适用于其它生产类型的相同管理原则 — 考虑工作的相同方式 — 也适用于软件。
考虑一下汽车装配线。零件和原料从这一头进去，装配好的汽车从另一头出来。您最不想看到的事是：装配线上的每个人聚在一起决定改为造自行车。装配线上没有机会进行创造。您真正想要的是可预见性 — 您希望装配线每次运行都完全相同。在这一领域，问题与解决方案始终是相同的，而您可以有效地优化该过程。当然，一旦您把事情优化并使其平稳运行，那么“变化”就变成了敌人。即使环境在底层是动态的，人们也会费尽心力地使它看上去可预见。
“效率”的这种模型根本不适合软件。对于软件，问题始终是不同的。它可能类似于您以前看到过的，但决不是相同的。这就意味着解决方案不可能相同。不可能只遵守手册就能获得正确的答案。如果问题不同而且解决方案不同，那么您不必考虑优化。它根本就不存在。变化是不断的。
在某种程度上，您可以说软件开发团队（对于内部或外部用户）受困于装配线式的思维方式。泰勒制给企业文化打下了深深的烙印。担当软件项目客户的人通常是管理用户群的人，或者本身就是用户。如果他们管理用户，那他们就是经理。如果他们本身就是用户，那他们就处于由经理们控制的环境中。无论哪种情况，装配线式思维方式都是标准。
参与软件开发的业务人员已经开始相信他们的角色主要是前端的：他们在开发周期的早期为程序员指定一组详尽且不变的需求，然后停下来等待结果。当然，他们应该有对过程的控制权。毕竟，他们正为它付出努力，他们正为它提供需求，而且完成的产品必须使他们满意。但业务极少驱动软件。技术人员很快会告诉业务人员软件是“软”的，但同样是这些技术人员却抵制变化，因为变化是痛苦的和代价很高的。程序员不希望没等到软件变得完美就发布它，而业务人员则不希望新软件给用户造成过多破坏，因此双方共同使得发行不及时 — 有时是在项目开始的数年之后才发行。
在这一周期结束时最终得到的并不是企业需要的软件 — 它是企业在项目开始时认为它所需要的。大多数客户都没有兴趣购买这样的“陈年”软件，但这却是他们所得到的。技术人员不希望交付这样的软件，但他们认为自己别无选择。每个人都感到挫折、疲倦、愤怒和上当受骗。
参与创作软件的每个人在这一过程的某些环节都妥协过。或许是为了保住饭碗或使冲突减到最小。或许是因为宿命论悄然涌上心头并在您毫无察觉的情况下影响了您。或许是因为懒惰。无论是什么，每个人都做了一个糟糕的决定。每个人都觉得使事情保持现状好过尝试使事情有所不同。遗憾的是，只有改变才能使事情做得更好。我们需要回到那条路上。出发的非常好的地点之一就是客户行为。
学会驱动
软件开发在过去三十年里已经是非常一致。当然，在其发展过程中有过一些改进，但基本主题是相同的：
用户并不真正知道他们想要什么，所以开发人员必须告诉他们以便生产软件。
变化有害，所以应不惜一切代价来禁止它。
禁止变化的方法是在一开始把所有的事情写在纸上，找些人在上面签字核准，然后照这个计划执行。
