XP方法论非常强调营造一种轻松的开发氛围，重视人的价值胜于重视过程。沟通是XP的一大价值观。XP中大量的实践是围绕沟通这个价值观设计的。例如，用户故事，现场客户，代码集体所有权等等，但是我们这里要强调的，是结对编程这一实践。本文中不对结对编程做介绍，这方面的资料有很多，没有必要在这里浪费笔墨。本文要讨论的，是我们如何在项目的角度上考虑结对编程。
结对编程是一种非常有效的改善沟通的方法。一对编程人员是协作过程中最基本的沟通单元。在经典的XP方法中，结对编程指的是两个程序员在同一时间、同一机器前，主动的共同的解决统一问题。也许经理们听到这句话的第一个反应就是："这不可能，我花了两倍的钱，却只做一个人的事情！"事实上，结对编程运用得当的话，是能够提高工作效率的，不但体现在进度上，还体现在代码质量、以及项目风险上。
个人编程
个人编程往往会遇到各种各样的问题。在软件开发中，编写代码往往只占构建过程中很小一部分的时间，很多的时间花在调试代码、改进代码结构，以及针对需求或是设计的变更修改代码。想必很多人都有这样的经历，在一些关键的技术问题上卡壳，而单人进行研究不但费时费力，而且很容易导致士气的低落。
在另一些时候，程序员往往需要在不同的设计选择之间进行权衡，而一个人做出技术决策往往造成内心的不安，这时候就希望能够有另一个同伴支持你做出决定。
说代码是最严谨的工件是一点错也没有，任何一个微小的错误，例如缺少分号，都会造成程序运行的错误。虽然编译器能够检查大部分的错误，可是仍然会有一些深藏其中的，时不时出来捣乱的小错误。一个人的眼睛往往容易错过一些错误，但是两个人同时进行编码，这种出错的概率将会大幅度的下降。
为了修正代码缺陷而进行的调试工作往往会占用大量的人月，如果代码缺陷到了测试团队的手中才被发现，修改缺陷的代价会很高，而如果代码缺陷一直持续到客户手中才被发现，这个代价更是惊人。而通过对开发人员配对，可以减少缺陷的数量。根据一些数据显示，结对编程可以让缺陷的数量减少15％。相对于在软件过程后期改正缺陷所付出的高昂代价，采用结对编程还是值得的。
以上讨论的是个人编程中遇到的一些问题，这些是很小的问题，但是都会对开发人员的情绪、进度产生影响。而在一个团队环境中，这些问题还会扩大，升级为团队问题。
团队编程
虽然软件组织规定了软件编码规范，但是编码规范不可能约定的过细，过细的编码规范不具备可操作性。因此不同人写出的代码仍然相差很大，优秀的代码和拙劣的代码同时存在，每个人都熟悉各自的代码，但却不愿意碰别人的代码。各种各样风格的代码逐渐产生的代码的混乱。这会产生很多问题。首先，软件组织内部复用的目标难以实现，如果人人都不愿意看别人的代码，你又如何建立一个内部复用的框架呢？现存的代码无法进行控制，旧项目的维护成本不断上升，团队积累也成为一句空话，
文章来源于领测软件测试网 https://www.ltesting.net/
