敏捷过程在中国软件企业的实践——XP价值观

 

接上一篇。。。。。。

 

段誉：“好的，俗话说：‘巧妇难为无米之炊’，每一种开发过程都有它的理论来源，首先我先谈一谈XP理论基础的来源。众所周知，在软件工程中，有三个比较主要的因素，那就是：进度、成本、范围。具体到某一次项目开发中，这三个因素有一个恒定的比例，也就是说，对该项目来讲，假定我们想加快项目完成的进度，我们可以通过增加更多的人手、通过加班增加项目组的开发时间、通过降低设计和编码的质量来达到这个目的，这增加了项目的成本；我们也可以通过减少系统的功能来达到这个目的，这缩减了项目的开发范围。通常，中国大多数软件公司的项目开发方式都是在项目开始之前制定一个项目完成时间表，也就是说在三要素中进度要素基本上是比较难以去改变的。当项目范围即需求频繁变更造成进度延误的情况下，这时候问题就出来了，由于项目完成时间的不可改变性，客户通常又很难同意系统功能的缩减，这时候要赶上项目进度，唯有在三要素的成本要素去着手。成本主要包括人力成本、时间成本和质量成本，企业出于财务方面的考虑通常又不愿意增加人手，并且项目紧急时人员的临时加入也很难起到1 + 1 >= 2的效果，这在软件工程经典之作《人月神话》中有着详细的描述。在这种情况下企业管理者唯一的办法就是从时间成本上着手，通过加班来增加项目组的开发时间，而开发人员也会自觉或不自觉的通过降低设计和编码的质量来尽快完成任务，所有的这些都会引起开发人员工作效率下降、人员流失、代码质量下降、系统难以维护等弊端，反过来又导致项目进度的延误，这种情况在我们公司各项目组也是随处可见。”

 

虚竹：“你说得没错，那么XP是怎样去解决这个难题的呢？”

 

段誉：“XP是强调拥抱需求变化的，即使在项目的后期它也随时欢迎变化，因此XP要求我们改变传统的项目组织方式，当需求发生变化的时候，也就说在三要素中范围发生了变化，在成本不变的情况下，XP团队会明确告诉客户，该需求变更需要多长时间才能开发完成，对项目的完成时间会有什么样的影响，因此XP团队跟客户签订的合同通常和中国现状不太一样，它们通常不会承诺具体完成项目的时间，它们承诺的是系统完成的功能和工作量，承诺整个团队会始终保持一种高效的工作效率去完成客户需要的各种功能，随需而变，使客户最终能够得到一套满意的、具有较大商业价值的系统。”

 

乔峰：“XP这种理论基础的出发点确实是让人耳目一新，可惜在中国很难说服客户去签订一个这样的合同，中国的客户通常都是要求能有一个明确的完成时间表，并且还要我们去随时满足他们提出的各种需求变更并且项目完成时间还不能有任何延误，这是在我们国家从事软件行业最难的地方之一啊！”

 

虚竹：“因此我们不能像XP一样去拥抱需求，去随时欢迎需求的变化，尽管我们都很清楚能够更多的满足客户各种需求的变更会让客户从系统得到更多的益处，但考虑到中国市场的现实情况，我们还是必须控制需求的变更。”

 

段誉：“因此对XP在我们公司的应用我们必须抱着一种谨慎的态度，根据我们公司的实际情况进行适当的剪裁，以符合我们公司的具体情况。接下来我说一说XP的价值观吧，XP的价值观是所有XP具体实践的指导，由它们延伸出了很多的XP开发实践，因此第一步我们应该着重去理解它的价值观，才能更好的理解后面将会讲到的具体实践。它共包括五个部分，分别是沟通、反馈、简单、勇气和尊重。在XP的创始人Kent Beck写的书《解析极限编程——拥抱变化》第一版中，他概括的价值观主要是前面四个，在第二版他加上了‘尊重’这个价值观。”

 

虚竹：“在一个项目团队中，毫无疑问，沟通应该是非常重要的，如果团队成员之间缺少了沟通，那不叫一个团队，那叫各自为战，其结果必然导致1+1<2的结果出现，关于沟通的重要性我想在每一种开发过程方法学里面都会强调，XP所提到的沟通有什么不同吗？”

 

段誉：“XP为什么会称为极限编程，是有它的特殊含义在里面的，那就是它会把很多软件开发的价值观、原则、实践给放大，放大到一个极限的程度，因此在这里它所说的沟通和其它方法学里面讲到的沟通既有相同点也有不同点，相同点是它同样强调沟通的重要性，不同点是它认为：口头交流是最具表现力的沟通形式，与书面交流相比，它不易引起错误和误解。因此XP更看重的是口头文档而不是书面文档，它的很多价值观都会反映在具体实践中，在后面讲到XP实践的时候我还会再谈一谈我对它的看法，这里先把XP的主要价值观一一阐述，以使我们对该方法学的体系有一个简要的了解。”

 

虚竹：“XP所说的反馈也是一个很常见的价值观了，它又有什么特殊的地方吗？”

 

段誉：“反馈和需求是紧密相关的，在开发过程中越是需求无法确定的项目就越需要更多的反馈，因为如果没有了不断的反馈，由于需求的不确定性，最终开发出来的系统必定是很难符合客户的需求的。在传统的开发过程瀑布模型中，它是采用从需求分析、设计、开发、测试这种线性的开发过程，为什么它会逐渐为人所诟病，那是它忽略了一点，就是大部分软件系统的需求是无法在项目前期完全掌握的，它会随着时间的变化而变化，其结果是导致在需求分析阶段所得出来的输出已经是错误的，或者是部分错误的，因此导致最后开发完成的系统不是客户所想要的系统。XP是非常强调反馈的，在系统开发中，它对反馈的要求达到了一个极致的地步，甚至是有点偏执了，它的具体实践中处处都体现了反馈的痕迹，我这里捡两个例子来讲，其它的留到后面说到具体实践的时候再讲。第一个例子是XP要求每次迭代的步伐是非常小的，通常是一到两周的时间，每一次迭代过后都会提交版本给客户使用，以获得客户的反馈意见；第二个例子是XP在具体编码的时候强调采用测试驱动开发，它要求开发人员每写一个小小功能之前都要先写一个小的测试，然后再编写功能代码以让测试通过，也就是在编码过程中每前进一步都有一个小的反馈，以验证你代码编写的正确性。”

 

虚竹：“关于这点我是有些不同看法的，后面再说吧，接下来你再说说简单的价值观是怎么一回事。”

 

段誉：“XP认为在系统开发中对一切采用简单原则是关键，总是尝试做可能使工作最简单的事，为达到同样的目标，通常这样做比完成一件复杂的事情需要的时间更少。也就是说，我们在设计、编码的过程中不要考虑太多未来可能发生的情况，考虑太多的扩展性、性能诸如此类的事情，只需要能满足当前的需求就可以了，因为XP认为未来的需求可能永远都不会发生，就算万一发生了也可以将来再处理，过多的考虑只是浪费当前的时间，影响了项目开发的敏捷性。”

 

乔峰：“嗯，尽管我对它的说法持一些保留意见，但它仍然不失为一个好的经验法则。”

 

段誉：“在XP里面勇气的价值观是最让人感到困惑的，它基本的意思是说在系统开发中我们必须有放弃失败的解决方案和寻求新方案的勇气，有大规模重构代码的勇气，有与人沟通、敢于表达自己意见的勇气。”

 

乔峰：“勇气是一个优秀的开发人员必备的素质之一，这点我赞同，不过我觉得不止是开发人员，无论哪一个优秀的人员都应该具备这种素质，XP把它做为五大价值观之一，这点倒令我有点意外。”

 

段誉：“因此我刚才说觉得有点困惑道理也就在此，这个暂时不管它，现在说一说最后一个价值观吧，尊重是后来Kent Beck新加的价值观，这点我倒是深表赞同，在很多软件公司内部都存在着一种现象，那就是一旦某一个项目组出现了开发人员经验欠缺、项目延期、项目失败等各种情况的发生，其它项目组的人员往往都会有幸灾乐祸的心理，甚至有些看轻该项目组的人员，我觉得这种心态是最要不得的，不管是团队内部还是团队之间，互相尊重是一个公司同事之间最起码的要求，也是做人最基本的原则，决不能因为另外的同事一时水平较低或者项目出现差错而否定一切，各项目组都有自己的苦衷和难处，即使是个人水准的原因，也没必要就觉得自己高人一等，每个人都有每个人的长处和弱处，要想取得一定的成绩只能找到适合自己的岗位，扬长避短。”

 

乔峰：“段誉，你说得好，XP的这个价值观确实有着深刻的道理，也正是我们公司所需要的。”

 

未完待续。。。