摘要：沟通这件事除了倚赖团队中每个成员自己的能力及自觉之外，其实为团队设计良好的机制及流程，也可以诱发团队成员间的沟通，做为一个导引和辅助的力量。

　　有些程式开发者，即使他对程式语言和技术不那麽全面深入了解、撰写程式也不那麽的快，但是因为他能够适当的让别人知道他遭遇到的问题、请求别人的协助，也懂得确认自己所接收的资讯是否正确、避免因为资讯传达错误而衍生出种种的问题。所以这样子的开发者，反而能够在团队中扮演称职的角色，让开发的工作进展顺利。
　　
　　相反的，有些技术高强的开发者，如果被赋予一个需要大量沟通的工作，但他本身却不擅长沟通时，就有可能没有办法圆满的把工作完成。由此可见沟通对软体开发的重要性。
　　
　　需要流通的资讯类型
　　
　　事实上，沟通这件事除了倚赖团队中每个成员自己的能力及自觉之外，其实为团队设计良好的机制及流程，也可以诱发团队成员间的沟通，做为一个导引和辅助的力量。
　　
　　即使不同类型的开发专案，在资讯的权限控管上会有不同的考量。不过我觉得对于资讯控管上没有特殊需求的团队而言，「尽可能的让资讯在团队中流通」是很重要的一件事。
　　
　　这包括了和开发有关的种种资讯，和专案工作排程有关的，像是现在总共有那些工作、每个人分别负责什麽工作、下一个开发的里程碑时限订在何时、这个里程碑抵达时需要完成那些工作等等。
　　
　　而和程式有关的则像是系统的架构为何、总共有那些主要的类别、每个类别的作用、它们是如何和其他类别进行互动……等等。
　　
　　也有一些和团队成员有关的，像是某成员可能在几天後要请假，或是某人最近身体或心理状态不好，可能没有办法全力投入在开发之类的。
　　
　　各种和专案本身、和需求规格、和设计、和程式码、和每个成员有关的资讯，都应该尽可能的在团队中流通，因为让团队中的成员知道愈多的资讯，他们便更有机会做出更好的决策、得到更好的工作结果。
　　
　　从极限编程看资讯流通的意义
　　
　　在极限编程（XP）里主张「集体程式码共有（CollectiveCodeOwnership）」的概念。在这个概念下，专案中的每个人都有权力及能力，基于增加功能、修正错误，以及重构的原因，更动系统中的每一行程式码。
　　
　　而当我们谈到了「能力」，不禁会问到，要怎麽才能够让每个人都有能力来更动系统中的每一行程式码？除了本身技能之外，也得让和每一行程式码对应相关的资讯（像是领域知识或是演算法，甚至是设计细节或特殊考量），都让每个成员知晓，才能够让他真正具备更动程式码的能力。
　　
　　极限编程里怎麽达到这件事呢？
　　
　　它是透过搭档编程及系统隐喻等准则，来达到程式码的共有。透过持续更换搭档编程的对象，让不同的成员间得以都有合作的机会，每个人都有机会碰触到每一段程式码。
　　
　　而在搭档编程的过程中，透过这种特有的合作模式，领域知识、演算方法、设计思维，都可以在成员间流动、传递。我们可以说，极限编程透过开发方法及流程本身的设计，促进了这些资讯在团队中流动。只要这些资讯能够在团队中流动，这些资讯就容易被更多的人所持有。
　　
　　使沟通顺利进行，让团队成员之间更乐于相互了解
　　
　　这正是本文的主旨，我们是可以透过机制的建立，来促进各种形式的沟通在开发过程中发生，而不必只是倚赖团队成员自己的能力及自觉。甚至，我们有机会利用这些机制，强化成员沟通的能力与意愿。
　　
　　以沟通所得到的效益，很容易可以构成一个正向循环。当团队成员发现这麽做可以得到好处，他们就更愿意沟通。一开始是机制的导入，随着大家在这过程中所感受到的好处，就会渐渐形成文化。
　　
　　就像我知道的一些团队，他们用IRC网路聊天室来做为团队中资讯交换的中心。他们建立IRC的专用频道，每个成员习惯这个频道上，将自己正在做些什麽、打算做些什麽、有什麽想法，对于别人想法的评论或建议、等等的资讯都丢上去。
　　
　　虽然不见得每个人随时都看着频道的内容，甚至不是每个人都一直待在座位上，但是，因为他们都会挂在该频道上，所以只需要检视频道内的资讯，就可以知道其他人所丢出来的各种资讯──即使这些资讯是在自己的非工作时间被丢出来的。
　　
　　我相信，这一开始或许只是一两个成员所建立的机制，但是每个人融入这个机制後，享受到好处，也进而形成一个文化。这样的文化很好，也有一个机制来辅助，可以随时、随地都在沟通。因为有更多的资讯在团队中流动，所以其他成员就能接收到愈多的资讯，而这些资讯便可以辅助他们做决策，使得决策的品质更好。
　　
　　在过去，我们可能很习惯利用定期或不定期会议的方式来做沟通，像是定期的进度会议来审阅每个人的进度、是否遭遇到什麽困难、以及讨论各种问题的解决方案。但是这样子的资讯流通及沟通方式，受限于会议的参加者必须要在同一个时间出现，甚至不利用远距通讯机制的话，还得在同一个地点一起出现，都让资讯流动的速率不够即时，也让沟通的频率显得有点过低。
　　
　　其实，这些在开发中的活动，都可以设计一些其他的机制来辅助的。像是，你可以利用规范成员撰写版本控制系统上的commitlog的方式，来让成员间彼此了解彼此的工作进展。
　　
　　怎麽说呢？一般而言，commitlog的的主要目的，是要记录你所commit到版本控制系统上的原始码，究竟是为了达到什麽样的目的，大致上做了那些事情。这样子的记录，有助于当我们要追溯版本控制系统中原始码的每一次变动，找出究竟发生了什麽事情。
　　
　　例如，我们在现行的原始码版本中，发现了一个重要的程式臭虫，为了找出这个臭虫究竟影响到那些版本，我们就得找出这个臭虫究竟是何时被埋到系统中的。
　　
　　每一次变动的commitlog,当然可以提供不错的提示及帮助。这有助于我们判断版本间的变化究竟是基于什麽原因、发生了什麽事情、以及可能会产生什麽效应。
　　
　　不过，除了上述的目的之外，其实，commitlog还有一个很好的好处，就是每个人都可以透过查看其他成员的commitlog,来了解其他成员做了些什麽事情；遇到感兴趣的部份，还可以把和该commitlog有关的原始码部份，都撷取出来阅读。
　　
　　这是一种有趣的方式，我知道有人会利用有空的时间去查看团队中其他成员的commitlog,看到有兴趣的部份，就会拿出来好好的研究一番。无论对方是不是高手，都可以查看、研究其他成员的程式撰写方式，看他解决特定问题的手法，看他的思维方式是否值得效法，或者是存在破绽。
　　
　　以上述的描述做为一个例子，commitlog除了原先就具备在版本控制系统上的好处之外，一方面，可以让团队成员间知道彼此的工作进展，二方面也提供一个彼此效法或相互审阅潜在问题的途径。如果，能够在团队中建立这样的机制，让大家开始也这麽做，渐渐形成一个文化，那麽，必然可以强化团队中资讯流通的速度及品质。
　　
　　我相信，还有很多可以强化资讯在团队中流通的方式，也衷心的建议大家不妨花点时间思考，还可以透过什麽样机制的建立，来达到这个目标。最後也还是再度强调，资讯在团队中的流动，是再怎麽样也不嫌多的。
　　
　　责任编辑：三水