解读极限编程的十二大原则——现场客户

 

现场客户：讨论，使用程序员和客户都能够的语言描述功能。

98年刚刚参加工作的时候，公司的项目都是严格的区分项目阶段，先是收集用户需求的阶段，由我们的系统设计人员到客户现场通过跟客户的沟通编写出一份很厚的用户需求说明，这个阶段往往需要1、2个月的时间。而沟通的过程呢，也是相当的“粗糙”，因为当时的客户了解软件的人很少，不知道软件可以实现成什么样子，跟他们了解业务，客户自己都很难将自己的业务描述的一清二楚，所以我们通常的做法就是收集一大堆他们平时业务中的纸质报表，然后拿回来自己分析，看看哪些数据是输入的，哪些数据是计算出来的。但是这样的分析却难以触及业务的本质，我们不知道客户为什么要这么做，而仅仅是将他们的手工劳动改变到了用电脑劳动。其实很多年纪大的人都已经习惯了手工劳动，这样做出的软件对于他们来说不但没有提高工作效率，反而因为要学习如何使用电脑，使得工作难度增大了。

然后，进入到系统设计阶段，在公司内部分模块写设计方案，将用户需求转化为给研发人员看的设计文档，这个阶段又花费了1个月的时间。到了真正开始编码的时候，开发人员看到的已经是完全经过设计人员“修饰”过的需求。

在这种模式下就很容易出现用户想要一个“秋千”，结果我们设计出了一个“挂着绳子的轮胎”这样的情况。更多的悲剧是因为周期过长（从最初的客户现场用户需求收集到软件在客户现场实施会有半年左右的时间），当我们的软件安装到客户现场时，当时的需求提出人自己都忘记了最初提出的需求是什么样子的，或者是当时提供需求的客户发生了变化，等等原因，使得我们的开发人员不得不在客户现场进行需求的重新收集和确认。于是，项目计划必然拖延。

对于定制特征比较明显的软件项目，需求的多变是常态，所以敏捷开发正是清醒的认识到了这一点，需求的变化的不可避免的，与其想办法通过各种手段去减少变化，不如改变思路去面对变化，保证当变化来临时开发进度的高效。

现场客户这个原则有两个主要内容：第一，鼓励和客户一起开发，无论是将客户邀请到公司内部还是开发人员到客户现场。第二，就是在和客户沟通需求时采用场景的方式将用户的需求一个个描述出来，而描述的语言是程序员和客户都能理解的，这样就不需要再经过任何人的重新“润泽”，也就减少了需求在“解释”的过程中被曲解的风险。

当然，客户的素质不同，会导致沟通时的成效也有很大区别。这时，我们通常采用工具（比如Visio、VB、DHTML等一些能够快速开发的工具），首先将业务界面速成，展示给用户，在界面的帮助下进行业务需求的梳理。因为用户通常对看得到的东西感兴趣，如果讨论来讨论去没有任何实物去帮助他理解，客户的思维很难和程序员的思维保持一致。