论极限编程中的沟通

高 云

[摘要]极限编程的核心价值中的沟通对于软件项目管理有着极其重要的意义。论述极限编程中的沟通方式，并探讨作用。

[关键词]极限编程软件工程沟通

中图分类号：TP3文献标识码：A文章编号：187t－7597(2009)1020064－01

一、极限编程

随着软件行业的飞速发展，原有的软件开发方法已不能完全适应种类繁多的软件项目。这些软件开发方法需要繁杂的开发文档，过于严格的项目流程，而这对于规模较小的项目来说却成为沉重的负担。规模较小的项目本身开发工作量并不多，这使项目开发人员不愿意多花精力来建立文档和对项目进行管理。项目进行过程中，难以预计的需求变化对规模较小的项目更是常事，开发人员不得不多次调整项目需求以及已完成的项目内容，这使项目的。开发人员常常有做事目标不明确，事倍功半之感觉。这对于项目的开发进程起了负面影响作用。

为了解决以上的项目管理问题，一批业界专家在2001年创立了敏捷联盟，并提出了一些可以让项目团队具有快速工作、响应变化能力的价值观和原则。敏捷开发过程的方法有很多种，其中最重要的是极限编程(Extreme Programming，简称XP)[1]。

(一)极限编程的概念

极限编程(Extreme Programming，xp)适用于轻量级开发。它以客户的需求作为项目的最终目标，并保证项目团队中的所有活动均以此为基础。

极限编程强调把需求细化，划分为若干需求故事，这些需求故事的内容简单明了，工作量较少，开发周期短，开发人员可以明确给出完成所需的时间。在完成这些需求故事的同时，测试代码也相应完成，并用来对相应的需求故事进行测试，从而尽快发现问题。

极限编程的时间进程为一个个迭代周期。每个迭代周期中，客户会提出一批需求故事，开发人员接受这些需求故事并估算花费时间，编写其测试和代码，将代码通过测试，重构系统，记录结果并完成版本控制。完成这些任务模块并进行测试和集成，这样尽快生成相应的项目版本以便客户使用，帮助客户更好地完成项目。

极限编程强调项目团队中所有人员之间的合作，关注彼此之间的沟通交流和反馈。项目的进展在持续的沟通中向着最终目标稳步前进。

(二)极限编程的十二种方法

1、规划策略；2、结对编程；3、测试：4、重构；5、简单设计；6、代码集体所有权；7、持续集成；8、现场客户；9、小型发布；10、每周40小时工作制；11、编码规范；12、系统隐喻。

(三)极限编程的核心价值

极限编程中有四个核心价值，即沟通、简单、反馈和勇气[2]。

极限编程在项目中体现了以人为本的精神，极力地帮助项目各方互相理解，通过种种方法激发人的潜力，帮助所有人减轻思想负担，高度关注项目本身的实现。

二、极限编程中的沟通

极限编程项目首先拥有一个小规模但拥有各种不同职能的成员的项目团队，以项目完成为项目团队的共同目标。作为极限编程的核心价值，第一个就是沟通，这说明沟通成功与否直接决定项目的顺利完成。

(一)开发场所

为了保证项目团队充分掌握需求，保证所有人员对项目需求有充分的理解，开发场所必须是一个开放的场所，项目的所有参与者一起在这里工作，他们属于同一个团趴。开发场所的墙壁上应张贴着与项目有关的图表以及相关的文字内容，帮助团队成员了解项目进度。每个成员可以根据项目进度制定工作计划，并一起探讨所遭遇问题的解决方案。所有与项目有关的意见和变化都在这个场所以第一时间传达给所有参与者，所有人的交流都是面对面的。开发场所中应该必备用于交流的工具，如纸张、卡片和白板等等。

(二)现场客户

项目的顺利完成离不开客户的合作，只有开发出满足客户需求的软件，项目才是成功的。项目的需求其实只有客户自己真正了解，因此项目团队中应包含一名可以经常在开发场所与项目团队一起工作的客户。现场客户提出需求故事，并将故事划分出优先级，然后根据开发人员给出故事的费用从而做出决策。

现场客户必须精通项目的业务流程，具有丰富的业务经验。同时，他还必须具有项目的决策权限，能够对项目的需求决定取舍。往往与项目有关的客户人数不止一人，他们对项目的需求应汇总到现场客户这里，经整理后再提交给开发团队，使项目的需求不至于出现矛盾之处。

现场客户对软件开发的了解水平有高有低，有的现场客户对技术不够了解，或是不善于描述需求故事，从而屡屡修改需求故事而没有考虑带来的影响。对于这样的现场客户，可与其交流项目的架构和开发技术，告知其需求修改可能产生的损失，并通过需求故事的调整和工作流程的再造来解决问题。有的客户希望掌控项目的技术细节，这可能会对开发人员的技术决策带来一定的影响。对于这样的客户，开发团队应满足其，解的愿望，在制定需求故事时应全面考虑其意见。让客户在每日例会中充分了解项目的进展和问题。强烈的参与意识将树立客户对项目的信心，在项目出现问题时也会积极需求解决方案，这对项目的顺利进展起到不可忽视的推动作用。

现场客户不仅要和开发人员一起制定需求故事，还需要保证每个需求故事都有验收测试用例进行验证。极限编程中的测试包括单元测试和验收测试。现场客户所负责的是验收测试。现场客户可以自己编写测试用例，也可以由现场客户所在单位的人员来编写测试用例。当然，现场客户也可以直接让项目团队的开发人员来编写验收测试用例。验收测试的结果直接为现场客户提供项目决策依据。

(三)需求故事卡片

旧有的软件项目中用大量的文档来记录项目需求及进展，保证项目顺利进行。有必要编写好和维护好项目文档，但时间的要求和需求的变化使其变得难以保证。开发人员需要在完成编码任务的同时完成文档的编写和维护，而规模不大的项目中的编码工作量不大，开发人员不愿意去花费过多的时间在文档上面。

所谓需求故事是指项目的基本需要所分解成的小的、重耍的用户故事。它由客户提出，并被开发人员所接受，作为开发和测试的依据。客户将一个个需求故事写在一张张卡片上，内容包括需求故事的名称和需求故事的业务逻辑，然后将其按优先级排列，交给开发人员去处理。当需求发生变化时，客户只需要重新制作需求故事卡片，并被开发人员认可就可以了。现有的需求故事卡片内容就是当前的项目需求，相比项目文档的维护而言。这样的工作量减少很多。

(四)每日例会

项目进行离不开会议交流，开发人员在会议中汇报自己的工作并提出需要解决的问题，但会议往往会间隔一段时间后召开，间隔时间或长或短，开发人员不能及时沟通，如果采取个别交流的方式则无法让全体开发人员了解。

开发人员应该在完成自己任务的同时，了解其他开发人员所做的工作，并学习其他开发人员所使用的技术方法，以及帮助其他开发人员解决

工作中的难题，从而提高开发效率。每日例会满足了这样的需求。

每日例会的时间较短，所有开发人员报告昨天的工作成就、获得的成果和今天的工作计划，提出自己面对的困难。不能在例会上解决的问题将放到会后进行个别讨论。每日例会避免了开发人员各自为营、相互脱节的局面。在会上，所有的开发人员必须畅所欲言，诚实地汇报自己的工作现状，同时不避讳自身的缺陷，将工作中的难题公开并向项目团队寻求尽快解决的方法，达到真正的有效沟通。实际上，遇到难题时，开发人员最好应该立即寻求帮助，既然整个项目团队在一个开放的工作环境中工作，那么所有人都会立即了解他的问题并援助，大大节约了开发的时间。

(五)结对编程

以往的项目通常会把分解的各模块任务下发给单个开发人员完成，这样会出现以下问题：每个开发人员的技术水平不同，对项目的理解也会存在不同，这会导致开发模块与需求的差异，尽管经过修改可以达到目标，但走了弯路，花费了时间和精力。如果遇到难题而没有他人的帮助，单个开发人员往往会花费更多的时间来解决。个人开发有可能会受自身的种种因素影响，如精力不够集中、时间安排不合理等等，使得开发计划受到影响。

结对编程使得参与编程的开发人员必须共同熟悉所开发的内容，对所涉及的需求达成共识，共同完成设计决策。结对编程的工作方式使得开发人员更全面地了解项目需求，更快地达到目的，同时提高了个人的工作效率，加快了项目开发速度。同时，经过结对编程人员之间的审查后的代码相比单独编程的代码而言，具有较高的规范性和准确程度。

因为项目团队中的编程人员的结对极有可能发生变化，原有结对编程人员将共同完成的需求的理解以及技术方法传播给项目团队中的其他人员，促使更多的开发人员了解项目需求，有利于开发人员之间的沟通。

(六)编码标准

基于极限开发的共同拥有代码和结对编程的方法，项目的代码为项目团队中所有成员所拥有并可以进行修改。因此，项目按照规范的编码标准来开发，提高了代码的质量，可以方便所有开发人员理解和修改项目代码，这对于开发人员之间的沟通也是极为有利的。

三、结束语

有效沟通是影响软件项目质量乃至成败的关键因素之一。极限编程方法中的所强调的沟通对项目管理具有积极的意义。无论是否采用极限编程方法-我们在软件项目中都应高度关注项目相关人员之间的有效沟通，在满足客户的需求之上提高软件质量，减少时间和消耗。