|
沟通问题是一个项目成功最重要的因素之一。一个项目可能并没有什么正式的软件过程，但是只要团队成员能够进行有效的沟通，项目成功的可能性就很大，但是如果项目中缺乏有效的沟通渠道，再优秀，再严谨的软件过程也没有用。优秀的软件方法学，总是会在沟通渠道的建立，推动有效沟通上花费大量的精力。我们分析RUP、XP等方法学，都会看到很多这样的实践。沟通对一个项目而言是重要的，对一个软件组织而言就更重要了。从长期来看，内部能够进行有效沟通的组织能够得到很好的发展，但是反过来，内部沟通不畅的组织将会出现很多的问题。 在软件开发过程存在的一个很大的问题就是沟通不畅的问题。事实上，这个问题并不仅仅在一个开发过程中存在，在整个软件组织内都将长期的存在，并成为阻碍软件组织发展的一大障碍。这样的说法可能过于理论化，但是我们只要想想，如果现在的项目中，一个主力程序员离开的话，是否会给项目，甚至组织带来重大的影响，就能够理解这段话的含义了。造成这种现象的主要问题是程序是分散在各个程序员手中的。各个代码块就像是程序员们的私有财产一样，神圣不可侵犯。 更为糟糕的是，任何一个程序员都不愿意阅读他人的代码，比起理解别人的代码，程序员们宁可自己重新编写代码，这导致另一个严重的问题――软件组织中大部分的工作都是重复的，以至于程序员天天忙于开发代码，却难以把精力放在更有价值的地方（关于什么是更有价值的地方，我们在下文会详细的描述）。 在一些项目中，我们经常看到这样一种开发环境：每个程序员都拥有个人的隔离空间，彼此之间不进行交流，甚至有时候他们整天不说一句话。在和项目中的一位主力程序员进行沟通之后，我们发现了他们的真实想法： 项目非常紧张，团队成员之间的关系非常的微妙，主力程序员必须要保持自己的主力地位，对他们来说，必须努力写出优秀的代码，同时，你还需要承担项目进度的压力，并提防着其它的程序员。将程序掌握在手中是自己安全感的来源。压力如此之大，他们不得不每天工作12个小时以上。程序开发就如同噩梦一样。 虽然未必所有的团队都如此不良的开发人文环境，但是或多或少都存在一些不好的环境因素。可以肯定的说，没有多少人愿意在这样一个开发环境中工作。这些环境因素都影响了沟通问题的形成。 XP的四大价值观中的一项就是沟通。XP中的沟通范围很广，有开发人员和客户之间的沟通（我们在需求和故事一章中也提到了沟通问题），有程序员和设计师之间的沟通，有程序员和测试人员之间的沟通。但是本文的重点集中在开发团队内部，即，如何改进开发团队内部的沟通质量。 XP方法论非常强调营造一种轻松的开发氛围，重视人的价值胜于重视过程。沟通是XP的一大价值观。XP中大量的实践是围绕沟通这个价值观设计的。例如，用户故事，现场客户，代码集体所有权等等，但是我们这里要强调的，是结对编程这一实践。本文中不对结对编程做介绍，这方面的资料有很多，没有必要在这里浪费笔墨。本文要讨论的，是我们如何在项目的角度上考虑结对编程。 结对编程是一种非常有效的改善沟通的方法。一对编程人员是协作过程中最基本的沟通单元。在经典的XP方法中，结对编程指的是两个程序员在同一时间、同一机器前，主动的共同的解决统一问题。也许经理们听到这句话的第一个反应就是："这不可能，我花了两倍的钱，却只做一个人的事情！"事实上，结对编程运用得当的话，是能够提高工作效率的，不但体现在进度上，还体现在代码质量、以及项目风险上。 个人编程往往会遇到各种各样的问题。在软件开发中，编写代码往往只占构建过程中很小一部分的时间，很多的时间花在调试代码、改进代码结构，以及针对需求或是设计的变更修改代码。想必很多人都有这样的经历，在一些关键的技术问题上卡壳，而单人进行研究不但费时费力，而且很容易导致士气的低落。 在另一些时候，程序员往往需要在不同的设计选择之间进行权衡，而一个人做出技术决策往往造成内心的不安，这时候就希望能够有另一个同伴支持你做出决定。 说代码是最严谨的工件是一点错也没有，任何一个微小的错误，例如缺少分号，都会造成程序运行的错误。虽然编译器能够检查大部分的错误，可是仍然会有一些深藏其中的，时不时出来捣乱的小错误。一个人的眼睛往往容易错过一些错误，但是两个人同时进行编码，这种出错的概率将会大幅度的下降。 为了修正代码缺陷而进行的调试工作往往会占用大量的人月，如果代码缺陷到了测试团队的手中才被发现，修改缺陷的代价会很高，而如果代码缺陷一直持续到客户手中才被发现，这个代价更是惊人。而通过对开发人员配对，可以减少缺陷的数量。根据一些数据显示，结对编程可以让缺陷的数量减少15％。相对于在软件过程后期改正缺陷所付出的高昂代价，采用结对编程还是值得的。 以上讨论的是个人编程中遇到的一些问题，这些是很小的问题，但是都会对开发人员的情绪、进度产生影响。而在一个团队环境中，这些问题还会扩大，升级为团队问题。 虽然软件组织规定了软件编码规范，但是编码规范不可能约定的过细，过细的编码规范不具备可操作性。因此不同人写出的代码仍然相差很大，优秀的代码和拙劣的代码同时存在，每个人都熟悉各自的代码，但却不愿意碰别人的代码。各种各样风格的代码逐渐产生的代码的混乱。这会产生很多问题。首先，软件组织内部复用的目标难以实现，如果人人都不愿意看别人的代码，你又如何建立一个内部复用的框架呢？现存的代码无法进行控制，旧项目的维护成本不断上升，团队积累也成为一句空话， 其次，代码复审的难度加大。代码复审是非常重要的工作，但是代码的混乱将会加大代码复审的难度，因为复审小组的成员不得不花费时间来了解代码的风格，并做出指导。更糟糕的是，代码复审小组的成员往往都是软件组织中的重要成员，他们的时间都代表了高昂的成本。也许没有人仔细计算过这样的成本，但是这些成本累积起来，也会是一个令人吃惊的数字。 再次，项目风险和组织风险都随之增大。这种在以项目开发为结算单位的软件开发组织中尤为明显，因项目开发人员离开而导致项目源代码难以维护的情况非常的普遍。对于已经完工的项目而言，这使得项目维护成本上升，对于尚未完工的项目而言，这会打乱现有的项目进度，导致项目进度的延后。 最后，也是致命的一个问题，内部沟通难以有效的进行。软件开发不是一个单独的活动。优秀的程序员组成的团队未必就是一个优秀的团队。究其原因，大部分都是因为沟通不善造成的原因。组织内部的知识很难形成流动，开发人员之间难以共享知识，而新成员也无法从经验丰富的老员工那里学习。 沟通不畅最终会积累形成组织软件设计平均水平无法提高的问题。软件设计属于脑力劳动，但是个人的知识覆盖程度和思考能力都有限，个人的设计往往都是有缺陷的，而雇佣大师级的开发人员的成本是相当高昂的，并不是所有的软件组织都能够像IBM或是微软那样雇佣大量的优秀人才。因此面对有限的人力资源（数量和质量两方面），关键的问题就在于如何让有限的资源发挥最大的作用。 在参与一家软件组织的代码复审之后，我加入了这一小节的内容。既然是工艺，当然是一些很细微的环节，例如浏览集合的写法、类和方法的命令、注释的规则等等。这些都属于程序员自身修养的部分，但是很多组织恰恰是在这个环节上存在问题。编码的随意性导致了代码可理解性的下降，为团队共享代码设置了障碍，没有人会主动的去看别人的代码。在前面我们说代码的混乱会导致复审的困难，而代码混乱同时产生的另一个影响，就是软件组织的平均软件工艺水平无法提高。虽然每个程序员都希望能够编写优美的代码，但编写优美代码需要一定的毅力和时间，尤其是在项目时间压力大的时候，代码的优美性常常是被忽略的。但是，强制要求代码优美性并不容易实现，需要监督的成本，效果也难以令人满意。 结对编程可以从组织结构上缓解这个问题。程序员大多是骄傲的，如果有一个同伴在身边，那程序员可拉不下脸来编写难看的代码。这是很有意思的现象，但是挺有效的。程序员通过这种方式，可以相互促进，提高编程工艺水平。虽然软件工艺解决的都是一些微小的问题，但是正是这些问题，最终影响到了软件的质量。从代码管理的角度上来说，管理的基本任务都是这些"小问题"。 结对编程可以在有效的解决这些问题的同时保证成本最小，这是结对编程之所以成为结对编程而不是三人编程的原因。在硬件设备的运行过程中，单点故障的最好解决方法是双机备份。这一思想运用到团队和过程上就形成了结对编程的基础。我们见过一个软件组织实施结对编程的初衷是为了保证产品的安全性，在产品的各个重要部件上都至少配备了两位负责人。一开始他们没有意识到他们朝着结对编程迈出了第一步，后来他们发现这种方法非常的有效，并针对这种方法进行扩展，形成了完整的结对编程体系。 在传统的软件开发中，一般都会在软件过程中建立几个检查点（Check Point），在这个点上，软件的各个部分都需要进行检查，设计是否符合规范，是否满足需求，程序中是否存在缺陷。但是在每个Check Point上花费的时间往往是非常可怕的。每个CP上花费的工作包括： a. 熟悉他人的设计思路和代码风格 b. 将不同的系统整合起来 c. 对缺陷进行改进 而结对编程的实践实际上就是将这部分的成本分摊到每一个人天中去。通过两两互配，让组织中所有的人都能能够熟悉软件的各个部分。这个成本在刚开始时确实会比较高，但是随着对结对编程理解的深入，这个成本会慢慢的降低。根据资料显示，结对编程并不是像大多数人想象的那样，会增加100％成本，这个数字取决于具体的实现形式，但绝对不会到100%。 林星，辰讯软件工作室项目管理组资深项目经理，有多年项目实施经验。辰讯软件工作室致力于先进软件思想、软件技术的应用，主要的研究方向在于软件过程思想、Linux集群技术、OO技术和软件工厂模式。您可以通过电子邮件 iamlinx@21cn.com和他联系。 |
|
|
来自： just_person > 《极限编程XP》
