以下是小编为大家准备了敏捷结对编程实践（共含8篇），欢迎参阅。同时，但愿您也能像本文投稿人“以鹅传鹅”一样，积极向本站投稿分享好文章。
本文主要从提升项目质量、促进知识传递及减少项目风险等角度出发，讲述作者所在团队在结对编程实践中的一些经历，以及如何避免或减少其所带来的负面影响，
你了解结对编程吗？你尝试过结对编程实践吗？也许你还未曾尝试甚至还不曾了解，那么我们一起来学习和了解敏捷结对编程实践，相信对敏捷感兴趣的你会有收获。
什么是结对编程
结对编程（Pair Programming）是一种敏捷软件开发实践，指两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘和鼠标一起工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）， 两个程序员定期互换角色。他们在一起完成需求分析、系统设计、编码、单元测试、整合测试（Integration Test）、写文档等工作。基本上所有的开发环节都一起肩并肩地、平等地、互补地进行工作（如图1所示）。
图1 共用一台电脑进行结对编程
上面是极限编程（eXtreme Programming，XP）对结对编程的描述，它有如下主要的优点：
有利于提升项目质量，减少Bug；
有利于知识传递，降低学习成本；
多人熟悉同一段代码，减少项目风险；
与别人一起工作会增加责任和纪律性等。
尽管结对编程有诸多诱人的优点，但实行结对编程实践的却为数不多，其主要原因可能有：
结对编程需要投入更多的资源；
结对双方需同时注意力集中，否则效率更低；
结对人员能力要求相适，否则起不到观察者的作用，甚至产生依赖；
不成功的配对，经常引发争吵，产生内耗，导致团队不和谐等。
结对编程是颇具争议的敏捷实践之一，除上述一些优缺点外，可能大家还有更多不同的看法，但分析利弊不是本文所要讨论的重点。
实践经验
就我所在的项目团队而言，6人左右的开发团队需要支持多个中小型独立产品的需求开发，在繁重的业务压力下，用户价值的快速交付是首要的，所以想尝试共用一台电脑进行结对开发的实践只能是一种奢望。让团队开发人员尽可能熟悉相互间的产品代码，提升项目开发效率以及保证良好的项目质量，是我们在项目开发过程中需要重点解决的问题。
我们试图通过集体Code Review和设计交流分享等活动，来提升代码质量以及相互间业务代码的熟悉度，但一直收效甚微。问题主要在于这种集中式活动时间较难安排，人多交流效果不佳，性价比不高。后来，得益于公司的导师机制，在一对新人和导师身上，找到了敏捷结对的原型。由于他们的紧密合作，遇到问题及时沟通，新人在项目进度和质量都有不错表现，很好地融入了团队，
在后续的项目过程中，我们不断地尝试和优化这种结对形式，逐渐形成相对固定的工作方法。
与XP结对编程相比，敏捷结对编程最为显著的差异是结对进行需求分析、系统设计和问题讨论，但分别编码实现，通过过程中频繁的Review来实现结对的效果。开发人员两两结对，共同认领开发任务，一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论，然后分工各自编码实现，并通过Code Review以确保实现与设计一致。对结对过程中发现的问题，随时沟通和讨论。由于产品业务逻辑相对不是特别复杂，所以通过这种小范围、高效的沟通，可以解决项目中的绝大部分问题，实现更高的开发效率并确保代码质量。目前，在开发流程中的主要结对活动如图2所示。
图2 敏捷结对的主要活动
结对活动（如图3所示）给我们带来了哪些好处？
提升项目质量。结对开发人员在需求理解、设计思路上进行了充分的沟通和讨论，能尽早地发现和解决问题，避免前期因需求理解偏差、设计缺陷问题造成返工。
知识传递。对于新员工或经验略逊的开发人员，通过经常性的沟通和讨论，能迅速地进入角色和积累经验，发挥了传帮带的作用。
backup，规避项目风险。结对人员之间互为backup，有利于团队成员之间熟悉业务代码，若有人员异动时有利于项目风险控制。
图3 结对人员充分讨论设计细节及问题
无论新老结对还是强弱结对，都要尽力避免一方对另一方产生依赖，要给新人足够的成长和锻炼空间，让其独立思考和解决问题，并允许在可控范围内尝试失败，以获取宝贵经验得到成长。否则，团队只会多一个执行者，结对难以达到预想的效果。同时，一定程度的独立活动，可以让大家保留自己的工作习惯，而且形式更为自由和灵活。当然，大家可能会有疑问，如何保证结对人选中资深工程师工作的正确性，因为新人和弱者很有可能无法提出想要的Review帮助。这个问题在我们的结对中不可避免，有选择地邀请其他资深专家Review，也许会是个不错的解决方案，特别是对于一些重要的复杂业务逻辑。
参加结对的工程师应具备独立思考和解决问题的能力，并且具备较好的团队协作意识。否则，不仅不能有好的结对效果，反而会带来一些新问题。此外，结对也不仅限在研发工程师之间，研发和测试工程师之间或同产品经理之间的结对（如图4所示），同样可以带来不错的效果。
图4 研发、前端工程师测试之间结对解决问题
引入敏捷实践，贵在充分理解、结合实际，能扬长避短，且是一个适应、发展的过程，而按部就班绝对不是个好主意。有选择地结对对我们来说也许是上策，在结对的人选、场合、结对的环节等方面进行选择性的实施。
作者金建法，阿里巴巴B2B公司技术主管，具有多年互联网开发和项目管理经验，对J2EE和敏捷项目管理有着浓厚兴趣。
在传统的开发过程中，往往是一个人从一个模块的需求开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项目，这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比项目经理大。而同时，极限编程中的结对编程方式，对于开发人员人手严重不足的项目中，领导是不认可这种组织方式的，他们认为这会浪费很多的人力，一加一未必大于二。
“结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或者同一组测试。与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候。实施结对编程技术将给软件项目的开发工作带来好处，只是这些好处必须经过缜密的思考和计划才能真正体现出来。”（引自《结对编程技术》，原名为《Pair Programming Illuminated》，作者为Laurie Williams, Robert Kessler）。下面我们分析一下结对编程的特点：
结对编程在很多项目中得到应用，也作为XP（极限编程）一个非常著名的观点和做法被很多人大为推崇。
结对编程是两个人同时做同一件事情的一种方法。表现上会给人一种浪费一个开发人员的感觉，实质上这的确是可以提升效率的。
同样的这个做法，我在上海进行的一个类ERP项目中用过一次，当时在我做完权限系统的全部功能后，和一个兄弟合作了一个模块，我们两个人只用了三四天时间，就完成了这个新的模块的全部功能。相对于我们此前做的功能模块来说，时间不到那些模块开发时间的十分之一。但由于结对编程会让人感觉到资源被浪费了一半，在20的一个项目中，我提出进行结对编程的时候被领导拒绝了。这件事以后，我就开始考虑如何才能降低这种表面的浪费，而又能让大家交流起来，同时能提高团队的稳定性。
产生背景
年我的项目组要做如下这样的一个项目：
这是电信MSS系统的核心业务系统部分，包括了规划、设计、施工、验收、财务、合同等多个重要环节和多个部门的业务。当时团队开发人员数量较少，人员技能较为均衡，没有水平超出其他人过多的技术人员。这个项目在最初评估的开发周期就是第一个版本在五个月内完成，整个项目至少要做上一年以上，而最后的实际情况是，这个项目随着不断的升级和调整一直开发了三年多。最初的开发团队是十一个人，后来扩展到二十三个人，主要开发人员总数为十六个人，其中有四个人技术水平相对较高，另外的七个人技术水平相对较低但是也都有三年多的实际项目开发经验，其中有三个是我带的三个应届毕业生。
由于开发团队中没有技术水平超出其他人很多的人员存在，因此技术方案的论证过程都是在大家的共同讨论中制定下来的，只是在团队整体控制上，当时我有相对较强的发言权。因此在权衡了整个项目的实际情况后，完成需求工作我就告诉弟兄们——第二阶段设计模型的开发大家交换来做。
刚开始很多弟兄不理解，因为相对而言我的开发经验比其他人多了几年，所以当时我说的一些话兄弟们还可以接受，于是我就直接要求大家按照我的计划执行。在设计模型开发完成后，我再次要求大家进行交换。两次交换完成后，保证了每一个模块都有至少两个人对其十分熟悉，一方面不会因为人员的变动造成团队的不稳定（这一点考虑相对较少，因为当时的团队合作时间比较长，大家彼此十分熟悉和了解），另一方面保证每一个模块的开发人员都能找到人进行讨论，从而增加了团队内的沟通，方便了协调工作的进行。
因此在那个团队的开发过程中，我们经常是大呼小叫，无论走到哪里，都是十分热闹的场景。
方法定义
与结对编程类似，交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅可以应用于软件项目，也适合其他研究开发型项目。相对而言，这更是一种更容易被人们接受的方法，在前文大家已经看到了它在实际项目中的事实，这里先分析一下它与结对编程的不同之处：
它仍然采用传统的一人一机的开发方式，结对编程是两人一机。
它在每个迭代间进行多人交换或者两两交换，结对编程没有交换的概念。
它与传统的编程方式之间的差别是在每个迭代间进行多人交换或者两两交换，而传统编程没有交换的概念。
这里说明一下两个概念：
轮轮流交换：三个以上的程序员之间相互交换所开发的工件，不仅限于三个。例如：A1的开发内容交给A2，A2的交给A3，……，An的交给A1。这种方式称为轮流。
两两交换：两个程序员之间相互交换所开发的工件。仅限于两人之间。
建议实施方式
交换编程中的操作与其他过程有较大的差异，根据经验，建议在软件工程实施的各个阶段按照如下的方式进行：
需求工程中，需求调研和需求分析进行轮流交换，轮流交换至少是三个以上的人进行互换，不是两两互换；
概要设计（分析模型）开发中，需求分析到概要设计也进行轮流交换；
详细设计（设计模型）开发中，概要设计到详细设计再进行一次轮流交换；
编码实施启动后，详细设计到编码的交换采用两两交换，注意这个时候不再采用轮流交换了。
在全程建模的开发方法下的交换编程应用方式如下图：
由于目前没有进行实际数据的度量对比，本文也无法从量化的数据上来说明问题，只能通过一些具体的事实来进行说明和验证：当时这个项目的模块从7个扩展到了11个，人员数量从11人扩展到了23人，我们在七个月内满足了南方11家省级电信公司和集团公司的基本业务需求，从4月到月期间，基本完成了这些省公司版本的二次定制开发任务。
在编码以前全部采用轮流交换的目的就是为了让更多的人了解项目进展的全部内容，有利于增加团队内的交流，使更多的人对项目所开发的内容熟悉，并能让他们提出自己的观点，也有利于使更多的人从更多的角度来研究某个系统模块所需要实现的功能和用户需要解决的实际问题，不会因为某个人的定式思维而出现理解偏差，从而造成对需求的理解不到位。
详细设计到编码的交换采用两两交换，这是因为前期需求已经基本上都稳定下来了，这时候不需要对用户需求进行更多方面的理解，只需要进行实施并进行纯粹的编码工作即可。此时做轮流交换就不存在任何意义了，相反只能影响开发进度。
优劣势分析
这里所提到的优势都是和具体的开发方法相关联的，大部分是相对于XP方法中的结对编程，同时也会分析它与传统开发方式间的优劣。
开发时间“浪费”不明显
表现
这个开发时间“浪费”不明显是相对于结对编程与传统开发模式而言的，至少让老板没有感觉到人员分配方式带来了人员的浪费。大家都知道，结对编程需要两个人共用一台计算机、一套键盘、做同一个故事，这样的开发方式往往会给人感觉浪费了一个人，虽然事实上未必如此。但是如果哪个项目经理第一次甚至说前几次这样做，估计大多数老板都会表示反对的，因为他会感觉自己的技术人员只有一个人在做事情。同样，在的敏捷中国开发者大会上，ThoughtWorks的总经理也提到了这个问题，他的解释是这样的：当两个人合作三个月以后，效率会超过两个人单独编程的效率！但请注意：这里有一个时间前提——三个月以后。
三个月这个时间未必是真实确凿的时间分界线，它只是一个模糊的大概的时间范畴，如果两个人配合的好，也许只需要两个多月，如果配合不好，也许需要四五个月的时间，或者更长的时间……。我相信这样的说法连Martin也不会反对的。从这个时间界限上，大家可以看看国内公司的项目状况，然后再继续我们的讨论。
分析
项目情况：国内很少有时间限度较长的项目，大多数项目都是在三个月到半年时间内结束，有些甚至只有一个月。这样的时间特性，将使得这个三个月的期限变成了一句空谈，也就是说，当两个人磨合好的时候，项目已经结束了。这时候，有人会说，下一个项目还可以继续合作呀，好，那我们来看看国内项目团队的人员变动情况，然后再继续。
人员情况：国内大多数的公司都处于一种为了谋生而存在的状态下，有很多技术人员都有三五个月就跳槽的经历。不仅仅是技术人员，往往公司也是这种状态，很多公司就是为了某一个项目而建立的，老板在招聘技术人员的时候，都是往最低限压低技术人员的工资，当一个技术人员对项目了解到一定程度的时候，这个时间往往是在三个月到半年时间之间，
半年，或者一年，是一个人最容易发生跳槽行为的时候，因为这个人了解了公司的实质情况，如果老板当时骗了人，那么这个人必然要离开公司；如果老板当时过分地压低了他的收入，那么这时候这个技术人员就希望能够获得加薪等等，除此之外，还有很多很多其他的因素，都会给人带来未知的行为。也可以说，国内很少有团队成员能够合作达到一年以上的时间。这样的话，第一个项目磨合好了，第二个项目就是在考虑跳槽，第二个项目未结束人就走了，这是我们平时很常见的现象。
这个时候做结对编程，效果就不会那么明显，因为在人员相对成熟的时候，人的心理发生了较大的变化，工作的积极性和配合程度也远远不及刚刚进入公司的时候。那么结对编程在这样的环境下还能进行下去吗？估计不用分析就可以知道了。这时有人会说，如果配合不好，那就换人结对，不一定非要这两个人结对。那这就要从项目组人数说起了。
项目组人数：在我所开发过的项目中，大概有不到一半的项目有十个人以上的开发团队。最大的团队开发人员是不到三十人，这二十多人还要分成几个组，每个组也就五六个人而已。在这种情况下，结对的问题就出现了，在组内的你只能和这么三五个人结对，是不是都很容易配合起来呢？这个事情很难说。配合不好怎么办？换人？换项目？还是换公司？当然，如果配合了三个月还配合不好，站在公司的立场上，是肯定要考虑开除掉某人了，至少也要将他降薪或者调离这个项目组，因为公司承担不起这么大的风险。项目经理更是在担着风险，因为结对编程的事情老板本来就不太乐意看到，本来老板就有意见，而项目组如果发生了这样配合力度很差的情况，项目经理的处境可能就非常危险了。
综合上面这三个方面的情况，我们可以得到如下的结论：
结对编程在中国这些短小项目过多的情况下是不太适合的！结对编程其实更适合一些相对人员较为稳定的开发环境，否则，三个月的低效率配合时间会让老板将项目经理的脑袋当球踢的。但是，结对编程还是有其好处的，比如，提高项目组的稳定性，当一个人离开后，另外一个人可以很快地将新人带到位，项目组不会因为人员变动而发生较大的风险问题。同时，结对编程提高了程序员之间的交流，团结了项目组内成员，同时容易形成人月神话中提到的胶冻团队的效果。另外，在三个月后还是有效率提高的情况发生，的确能够带来很好的效益的。
这时候，交换编程就带来了很好的效果，一是没有老板担心的两个人做一件事情的风险，同时增加了项目组内成员的沟通交流，也提高了团队的稳定性。但如何提高团队的稳定性？
项目组稳定性提高
表现
在我前面的例子中可以看到，一个模块至少有三个人对他它很熟悉，因此在后面的开发过程中，无论哪个人发生变动，都不会影响这个团队的稳定性，所有的任务都能够很好的延续下来。每一个系统的模块都会至少按照阶段数量（不同的项目会有不同的开发周期，同时也就有不同数量的人会对这个模块十分熟悉）分给不同的人来进行开发。如果和结对编程配合起来使用，则将会使得对同一个模块了解的人数达到一般交换编程的两倍人数。
分析
有了这样的对每一个模块都很熟悉的人员数量的存在，团队的稳定性就会表现出来，任何一个人的变动或者少数人员的变动都不会对团队和开发进度产生较大的影响。因为随时都可以有其他人来接替这个发生变动的人的全部工作，也很容易培养新人进入到团队内来进行工作。
更适合没有绝对高手的团队
表现
当团队内没有绝对高手存在时，也就是说，系统的架构设计将是更多的人一同讨论出来的，并在开发过程中不断的修改和调整。
分析
没有绝对高手存在，系统架构设计就不能够在系统进行分析设计前完成，而同时架构的不稳定，就无法更好地安排任务计划和制定故事，这些都会影响到整个系统的开发进度和过程，同时，敏捷编程所倡导的很多做法就无法在这个大前提下来进行实施。
国外能够很好地采用敏捷的做法来实施项目的一个原因是，他们有很多有一二十年工作经验的开发人员。这些人员的经验积累是非常重要的，他们可以更好地在项目开始的前期对项目进行整体的控制和把握，同时做好项目计划和制定好任务故事，而这一点在国内尤其是软件公司中还不具备这个条件，因此，很多项目我们都处于的状态类似于我前面所举的电信项目的团队情况，甚至情况比那个团队还要差得多。
团队内交流增加
表现
前面已经提到,“因此在那个团队的开发过程中，我们经常是大呼小叫，无论走到哪里，都是十分热闹的场景。”这种频繁的交流，无形中使得团队的凝聚力提高，相互之间的关系和合作也都更为密切。
分析
如果是一个人从头到尾开发一个模块，他就几乎不需要和团队内非管理人员进行交流，甚至在某些情况下他只需要和客户做好沟通就足够了。而这时候，即使进行了同行评审，这个技术人员也可能会认为两三天的时间内这些人不可能了解这个系统模块的内容。这种评审也就容易流于形式而无法得到真正的重视。其他人也会认为评审是浪费自己的开发时间，于是到了一定程度评审就会成为可有可无的状态。如果有较多的人参与了这个模块的前后期分析和开发，每一个阶段都可以找到别人来进行讨论，在评审时对这些人提出的意见也就更容易接受——因为他至少会认为这几个人比他更早介入这个模块的分析，在某些程度上会比自己了解的更为深入。
唯一可能的劣势
表现
由于存在多人之间的交换，在某一个具体工件的开发的时间上会比一个程序员一直做下来略有延长。
分析
由于在任何一次交换之间都需要前一阶段开发者队后一阶段开发者进行关于业务和技术方面的沟通和交流，因此会延长项目在初期的开发时间。尤其当团队成员相互之间的熟悉程度不够或者配合不协调的时候，这个问题会表现得较为突出，甚至可能影响一些项目的进度以及开发工作的进展。
但是，这个影响会在相应的程度上促进团队内人员之间更快地相互熟悉，这个周期要比结对编程短很多，一般来说，不会超过一个月的时间就可以让团队成员之间相互熟悉（由于不是坐在一起开发，这个熟悉的程度比结对编程的要求低很多，因此时间也相应会缩短很多）。
深入讨论
交换编程的应用方式是有其适用环境的，另外在我的实践和研究中还建议如果团队合适，可以考虑与结对编程配合使用。
适用环境：这种开发方法的适应性较强，这里分为团队状况和项目情况两个部分进行一些说明。
团队状况：交换编程适用于人数超过两个人的开发团队，因为交换一次至少也需要两个开发人员。大的团队也可以应用交换编程的方式，来进行项目开发。要求团队内的成员有一两个具有两三年以上开发经验的，这是对于一般的项目（哪怕没有什么技术难度）的最基本要求。
项目情况：项目规模不限，开发周期的适应性也较强，对于任何类型的项目都可以适用。
与结对编程配合使用：如果领导比较认可结对编程的开发方式，这个时候，您引入交换编程也会带来同样的好处，比如团队稳定性，至少从对系统业务模块熟悉的人数上来看增加了一倍，以及团队凝聚力，因为频繁的交流，从而更多地降低因为少数人的思想和考虑偏差造成对用户需求理解不足等问题。
有了上述的情况表现，也使得团队的规范化操作能力更强，也可以使得很多问题能够在有效的沟通中的到解决。
由此可见，交换编程的存在是有其道理的，没有用过的朋友不妨尝试一下，至少对您的团队没有什么伤害和大的变动。
作者介绍：白慧冬，网名青润，独立软件咨询师，《软件工程之全程建模实现》一书作者，CSDN软件工程/管理版块大版主，一个在不断摸索实践的国内软件工程方法和技术的亲历者。底开发完成了一套软件度量概算产品，并对一些行业应用软件进行了较为成功的度量分析。20完成了全程建模方法中需求与代码影射关系的分析与实践探索。个人Blog为：blog.csdn.net/qingrun 。
来自：blog.csdn.net/programmer_editor/archive//12/07/1433092.aspx
1、什么是敏捷模式：
敏捷模式是一种应对快速变化的需求的一种软件开发模式，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用，敏捷的模式并不是一个方法论，而是一个世界观。
甚至敏捷不是一个方法论，顶多也是一种世界观。当在做一件事而又不确定哪种方法正确时，就可以参考一下原则，看看是否与原则相违背；
2、敏捷模式的实现方法
采用敏捷的开发模式不是说前期的需求什么的都不需要讨论，系统设计不需要了。在项目的前期，PD需要完成PRD，召开PRD评审会议，或者出原型之类的，务必使项目的成员都了解项目的需求。
对于没有使用过敏捷模式的团队，还需要召开Scrum计划会议，介绍项目的整体管理（流程，方法，工具和团队组建）等。
另外在流程开始之前，我们需要介绍一个名词，UserStory。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：角色——谁要使用这个功能；活动——需要完成什么样的功能；商业价值——为什么需要这个功能，这个功能带来什么样的价值。指定UserStory并没有统一的标准，项目组N个人可能有N种粒度的UserStory；从测试的角度来讲，我们需要保证没有遗漏。
迭代计划：迭代的划分
设定UserStroy
任务的分解
工作量的评估和认领
对整个迭代的整体计划进行确认；
任务执行：开发和测试按照迭代计划执行
每日站立会议：沟通已经完成的进度，当前计划和当前问题
提前进行部分功能交付测试
全部功能测试
团队回顾：评审会议
产品交付验收
3、敏捷模式和非敏捷模式的区别：
使用敏捷的模式开发项目，更多的是要求项目成员之间能够彼此信任，互相协作，同心协作，相互沟通，
使用需要项目组的成员发挥自己的主观能动性。
对比瀑布模型：
个体和交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
对比迭代模型：
迭代模型是以模块为最小划分单位，每个迭代采用的可能是小规模的瀑布模型；而敏捷模式，是以一段时间为止，我们尽可能多的实现UserStory，；
4、敏捷的适用范围
敏捷的是在充分了解项目的基础上进行的一种类似于手工作坊的开发模式。因此在所有的项目中都可以使用敏捷的思想，但是如果完全使用敏捷的开发模式，个人觉得以下类型的项目比较适用：
对实践型需求变更较频繁的项目比较适用：对于那些需要严格按照PRD进行开发的项目不合适，比如微软需要开发一个win9的系统是不可能采用这种敏捷模式的。
对逻辑简单的项目比较适用：对项目逻辑复杂，关键性高，可靠性安全性等方面有较高的要求的项目需要在开发的每个过程中，都需要多方认证，适用敏捷模式不合适。比如需要淘宝的登陆系统，就不可能使用敏捷的模式。
对团队成员少而精的项目比较适用：如果一个项目中，人数越多，面对面的沟通的代价就呈几何级往上增加。
对模块独立的项目比较适用：如果项目中，模块和模块之间的耦合度较高，相互之间依赖严重，整个项目只有很少的UserStory，使用敏捷模式会造成项目敏而不捷。
5、敏捷实践的经验和教训
避免无计划性：在以往的开发模式中，测试计划是绝对时间，而敏捷模式中，测试计划是相对时间。以往的开发模式在某段时间中，任务比较明确，而在敏捷模式中，容易造成无计划没目标。对于这种情况，除了有任务计划之外，能够自己指定一份计划，给任务计划确定具体的完成时间点。
避免无纪律性：敏捷的模式是支持需求变更的，但是我们不能够无谓的变更。所有的开发和测试同学都不希望自己的项目中存在不确定因素，但是使用敏捷模式，我们需要接受这种变更；
任务划分思考不足：从下面的图中（最开始并行上升段）我们可以看到，预计的总的开发时间（蓝色的线）是上升的，表示项目的考虑不够充分！在实际开发的过程中发现了不足之处，然后进行改进，导致整个工作量的增加，例如我们项目使用的是WEBX3，结果hecla不支持webx3，目前仅支持从webx2升级到webx3的兼容模式。
任务填写不准确：不是项目组中的每个同学都能坚持每天都在XPLANNER中填写时间的，如果时间填写不准确，则无法准确表达当前的项目情况（资源投入情况，项目质量等）。
在过去的几年里，我有过许多结对编程的经历，有时在我的团队里进行，有时在客户那里，有时在coding dojo(一种编程模式，几个程序员一起合作完成一个任务)，有时在我的开源项目里。
对于那些知道如何结对编程的程序员来说，这种模式很棒，很高效。
但是你不能指望在两个程序员面前摆台电脑，就指望他们一开始就做得很棒。结对编程需要学习，程序员需要知道实施者（敲键盘的人）和领航员之间的区别。下面来看看些细节。
在结对编程中，我遇到了一些误区，列在下面。
一、领航员误区
1. 发号施令者
喜欢发号施令的人总是对敲键盘的人说：“到末行，加个反括号，然后…”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。
事实上，他希望他自己来掌控键盘。所以当你碰到一个喜欢发号施令的人，那么将键盘交给他吧，转换领航员的角色。
2. 拼写纠错者
拼写纠错者坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正的进行导航。
和纠错者商量一下，当他给你纠错的时候让他请你喝一杯咖啡（或者任何你想要的东西）。
3. 吹毛求疵者
吹毛求疵者会指责你写的每行代码。当他的意见正确时，他会一意孤行，不用你已经写好的代码，而完全照着他的想法。
就如自由爵士音乐人都是复用其他乐队成员的音符，来构造成一首曲子一样，好的结对编程也应基于现有的基础上进行推进。
试着转换角色，也许吹毛求疵者就会变成一个目中无人的人。
4. 默不作声者
默不作声者是那些几乎不发表意见的人。他仅仅坐在那里看着你工作。
试着问下他对你的方法有什么意见，或者问他下一步该写什么测试代码。
5. 心不在焉者
心不在焉的人企图让你分心，而不是提供给你有建设性的意见，帮你解决问题。
那么让他离开吧，比起一个让自己分心的人而言，不如一个人编程。
二、实施者误区
1. 深藏不露者
深藏不露者仅仅自己敲着代码而不告诉别人他在做什么，
领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。
领航员需要问问深藏不露者关于他的计划或想法。
2. 目中无人的人
目中无人的人通常忽略领航员的所有建议，大多数是因为他们觉得自己的想法或编程技能更胜一筹。
当碰到一个目中无人的人时，立即停止结对编程吧，开始下一个任务吧。自大的人往往也不会是个好的领航员。他们很可能变成发号施令者或是吹毛求疵者。
3. 不知所措的人
不知所措的的人往往不习惯结对编程，非常紧张，不能掌控全局。
确保自己的领航员角色做到最好。小心的提出意见，对于不知所措的人主要给予鼓励。
但是，大多数程序员开始都是这种情况。所以，不要对他们的结对编程期望太高。让他们首先成为一个领航员，或者让能够很好的处理人际交往问题的领航员在他们旁边。
4. 跳跃性很大的人
跳跃很大的人喜欢在代码中进行大范围的跳跃，这样领航员不知道进行到哪里了。
领航员需要让他慢下来，问他关于他的计划，并确保自己比他知道更多的快捷键。
5. 不熟悉工具的人
不熟悉工具的人不知道开发环境的快捷键，效率非常低。
交换角色吧，让他看看你的技巧。或者打印一张印有快捷键的cheat sheet。
我相信还有其他的误区，如果你有什么想法请写在评论留言吧。
关于译(作)者:
唐小娟：在武汉生活了二十二年，材料和计算机双学士，材料硕士，在献身材料事业未遂后，转而投向互联网。喜欢互联网，喜欢思考，喜欢看电影，喜欢独立音乐，喜欢旅行。 （新浪围脖：@烫不了大卷）
结对编程(Pair-Programming)可能是近年来最为流行的编程方式，所谓结对编程，也就是两个人写一个程序，其中，一个人叫Driver，另一个人叫Observer，Driver在编程代码，而Observer在旁边实时查看Driver的代码，并帮助Driver编程。并且，Driver和Observer在一起时可以相互讨论，有效地避免了闭门造车，并可以减少后期的code review时间，以及代码的学习成本。
有实验证明，平均下来，结对编程时间花销比单人编程增加10%的时间，但也会比单人编程减少15%的代码BUG。如果再算上后期代码的维护和学习成本，结对编程比单人编程更有效率，还更为节省成本。无论是对开发团队还是对于Business，结对编程都会是非常不错的Programming Practice。
下面是一些结对编程的优点：
程序员互相帮助，互相教对方，可以得到能力上的互补。
可以让编程环境有效地贯彻Design。
增强代码和产品质量，并有效的减少BUG。
降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。
在编程中，相互讨论，可能更快更有效地解决问题，
当然，结队编程也会有一些不好的地方：
对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。
有时候，程序员们会对一个问题各执己见（代码风格可能会是引发技术人员口水战的地方），争吵不休，反而产生重大内耗。
两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
结对编程可能让程序员们相互学习得更快。有些时候，学习对方的长外，可能会和程序员们在起滋生不良气氛一样快。比如，合伙应付工作，敷衍项目。
面对新手，有经验的老手可能会觉得非常的烦躁。不合适的沟通会导到团队的不和谐。
新手在面对有经验的老手时会显得非常的紧张和不安，甚至出现害怕焦虑的的精神状态，从而总是出现低级错误，而老手站在他们后面不停地指责他们导致他们更加紧张，出现恶性循环。最终导致项目进展效率低下，并且团队貌合神离。
有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。
是否使用结对编程，需要具体问题具体分析，不可盲目。任何事手都有他的好与坏，结对编程也不例外，只有知道了好与坏，你才能更好的利用它。
最后，需要我们记住的是，人是一种非常复杂的动物，他们的缺点和内心的阴暗面可能会比你想像得还要糟糕，而这些东西是可以让一切事物失败的。所以，正如《人件》所说，人才是软件开发中最核心，也是最需要花时间去关注的事情。
结对编程软件的论文
1研究性教学
软件工程研究性教学是一种实践性较强的教育教学活动。与现有的软件工程教学不同，研究性学习不再局限于对学生进行纯粹书本知识的传授，而是让学生参加实践活动，在实践中学会学习和获得各种能力。
1.1研究性教学作用
软件工程研究性教学强调知识的联系和运用，不仅是软件工程学科知识的综合运用，更是程序设计、数据库、计算机网络等领域知识的融会贯通。学生通过研究性学习，不但知道如何综合运用学过的知识，还会在已经学过的知识之间建立一定的联系，并主动学习新的知识。软件工程研究性教学能够通过合理的选题充分调动学生的学习兴趣和积极性。研究性学习是一种带有研究性质的综合性学习。软件工程研究性学习主要与传统的接受性学习相对。一般来讲，该学习方式是学生通过自己观察、调查、访谈、分析、设计、实现、测试等方式获取知识、得出结论、形成软件产品，而不是由教师将现成的知识和结论传递式教给学生的学习方式。软件工程研究性学习的本质在于让学生亲历软件开发问题的产生与方案形成的过程，使学生学会独立思考、实践和分析，实现发现问题、取得解决方案与学习三者之间的有机结合与高度统一。
研究性教学和学习有其独特的好处与必要性。软件工程课程包含了丰富的工程化思想和基本原理，然而，这些思想和原理需要通过实践和探索使学生获得切身体会。这种探究对学生的思维构成了挑战，有利于思维能力的培养。探究过程要求综合运用已有的知识经验，有利于学生整合知识、学以致用，培养学生实事求是的科学精神和态度，促进学生学会合作、交流、倾听、批判和反思。在探究过程中，学生经历挫折与失败、曲折与迂回、成功与兴奋，从而最终理解科学的本质。软件研究性学习引导学生自主获得软件开发相关知识或信息，对学生学会思维与实践、加强能力培养、践行可持续发展具有重要意义。
2软件工程研究性教学案例
考虑到软件工程的内容复杂性，作者选择敏捷开发实践的结对编程方法作为研究性教学的探究内容。敏捷开发是一个新的思路，但不是软件开发的终极选择。对于时间长、人数多的大型应用软件的开发，文档的管理与衔接作用是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机结合，是软件开发组织者面临的新课题。敏捷过程将整个软件生命周期分解为若干个小的迭代周期，通过在每个迭代周期结束时交付阶段性成果来获取切实有效的客户反馈，目的是希望通过建立及时的反馈机制，应对随时可能出现的需求变更，并做出相应的调整，从而增强对软件项目的控制能力。因此，敏捷过程对变化的环境具有更好的适应能力，相比于经典软件开发过程的计划性特征，敏捷过程在适应性上具有更大的优势。极限编程实践中有一个非常重要的原则就是结对编程，这里所谓的结对编程并非是一个人在编程，另一个在看着，另外一个人同样起着非常重要的作用，他需要帮助编码的人找到低级的失误，防止其编码出现方向性的错误，特别是当出现编码的人不擅长解决的问题的时候，他会直接替换编码的人进行编程。
结对编程(PairProgramming,PP)是一个非常直观的概念，是指两位程序员肩并肩地坐在同一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起进行分析、设计、写测试用例、编码、单元测试、集成测试、编写文档等工作，基本上所有的开发环节都是面对面、平等、互补地进行，并且两人的角色可以随时交换。结对编程的实施方式分为面对面结对和远程结对两种方式。面对面结对编程是指两个程序员肩并肩坐在同一台电脑前、在同一个软件制品上一起工作的软件开发方式。面对面结对编程的好处在于，程序员可以直接快速地交流，获得高质量的代码并增强程序员工作的乐趣。面对面结对编程最大的优势就是交流非常方便，因为两个人靠得很近，言语和手势的交流非常自然，效果非常好。面对面交流没有隔阂，两个人互相看到对方的表情，产生和谐的气氛，合作也非常愉快。面对面结对编程效率较高，因为一方看着另一方在工作，因此编程的一方就不会想别的事情或停下来关注其他事情，因而能集中精力完成工作，即存在一种“结对压力”。面对面结对编程需要不定期地进行角色交换，以发挥两个人的能力。当面对面结对编程环境配置不当的时候，交换角色时需要双方一同站起来互换位置，然后再继续工作，这样就会导致停顿，引起不便和不顺畅，往往会打断双方的思路。这个问题可以通过提供宽敞的结对环境来解决，例如，提供一个较大的电脑桌，双方交换时只需要移动键盘和鼠标即可。环境受限的情况下，可以通过提供双键盘和双鼠标的方式解决，结对者可以在各自的键盘上工作，可通过系统来控制键盘和鼠标的切换。
鉴于全球化软件发展趋势的继续，要求两名开发者进行面对面的交流并不符合全球化软件发展的需求。这就要求两名程序员虽然在不同的地点，但是他们还能一起合作使用结对编程编写代码，这种方法被称为分布式结对编程。
分布式结对编程是一种编程风格，两个程序员在地理上是分布的，通过网络在同一个软件制品上同步工作。分布式结对编程可以克服面对面结对的一些不足，结对者通过网络可以随时随地结对工作，提高了结对的机会。为了进行分布式结对编程，需要功能较为强大的结对工具支持结对者高效地工作。首先，需要共享的代码编辑工具支持，一方的编辑工作能够被另一方实时地看到，同时，代码能够进行编译，以便能够检查语法错误，因此需要与现有的开发环境集成。第二，结对者需要充分地交流由于双方在不同的地方，合适的交流工具是必要的，基本的.交流工具包括基于文本的交流和基于语音的交流。基于文本的交流比较容易实施，但由于一方在编程，文本交流会造成干扰。语音交流是一个必然选择，交流起来也比较自然，只是对网络带宽有一定的要求。语音交流只能听到声音，看不到对方的表情，影响进一步的了解。随着网络技术的发展，基于视频的交流是今后的必然选择。第三，角色交换支持。结对双方经过一段时间交换角色，这是结对编程的特定要求。分布式结对编程的角色交换本质上就是对编辑器的控制，允许一方处于编辑状态，另一方则处于察看状态。第四，分布式结对编程还要支持用户管理、发起结对等功能基于上述的内容分析，笔者将软件工程研究性教学内容确定为结对编程方法与实践的探索内容。首先，要求学生从理论上理解结对编程的特点、优势和不足，然后，通过亲身结对活动体会其中存在的不足和影响结对的重要因素，进而提出解决结对过程中的问题和设计方案，最后，通过软件来实现这些方案。
3软件工程研究性教学实施过程
根据以上的思路，笔者设计了软件工程研究性教学的实施步骤。
（1）要求学生分析敏捷方法相比传统的软件过程方法的优势，进而理解结对编程式敏捷方法的重要实践原则。分发材料让学生深入理解结对编程的优势和实施过程。
（2）要求学生亲身体验结对过程，通过不同的学生结对编程，发现存在的问题和影响结对效果的因素
阅读有关结对编程的文献，了解影响结对效果的因素。学生通过个性、能力和性别等因素进行结对，发现存在的问题，例如，交换角色的不便因素和结对模式效率影响因素等。
（3）学生针对存在的问题提出解决方案。例如，根据不同的影响因素，可以开发结对模式评测软件系统，匹配最佳的结对组合；结对环境拥挤带来交换角色的不便，可以设计合适的设备环境，如采用双显示器、双键盘和双鼠标的硬件结构，开发相应的控制系统。在后续的教学中，利用软件工程开发过程与方法来开发学生提出的结对系统。在分析阶段，学生根据自己的体会提出软件系统的需求；在设计阶段，设计该系统的结构和算法；在实现阶段，进行编码和测试；在部署阶段，进行安装运行和修改不足。
（4）总结研究性学习效果。进行结对对比实验，分析效果。学生总结一个学期的研究性学习过程，通过提出问题和解决问题的过程来理解软件工程的方法和工程化思想，理解如何分析软件的需求、设计、实现和部署。
4结语
从开始，在本科生三年级的软件工程课程教学中实施了软件工程研究性教学。学生通过分组进行结对编程的实验，发现实施过程中的问题，提出改进方案，并设计了软件系统。在实施过程中，教师提供了研究资料，并给予了启发式引导。学生积极性非常高，积极参与个性评测，总结结对组合模式，提出许多建设性的意见和系统方案。有部分组最终完成了系统的开发和软件部署工作，开发的软件入选结对实验室的示范系统中，并被后续的学生使用，效果非常好。学生的一些工作被作者写入软件工程方法与实践教材中。今后工作室将把这些经验进一步扩展到其他课程（如程序设计课程、计算机基础实验课程）的教学实践当中。
最近几年，结对编程仍旧是最具争议的实践之一，支持者们不吝赞美之词，但是即使不少支持者都不得不承认他们自己公司真正结对编程都困难重重。为什么？Obie Fernandez给出了10个可能的原因。
Obie所在公司Hashrocket的两名员工Desi McAdam和Jim Remsik在《纽约时报》发表了一篇文章，大谈结对编程好处的，为此Obie回应了一篇令人深思的博文，概括了很多公司不能成功实施结对编程的10大原因。他首先澄清并解释他是非常认同结对带来的好处的，他认为”结对编程是Hashrocket里面最重要的竞争优势之一。”
接着他阐述道：“结对编程，尤其是完全100%地实施结对，他不得不逐步提醒大多数敏捷理想主义者：那条路对他们来说可能走不通”，他也解释了为什么。
10 - 大多数软件经理不想在必要的硬件上投资：高效的结对编程需要好的设备，但很多公司不愿意做这种投资。
9 - 大多数软件公司的办公布置不适合结对编程： 很多软件公司让他们的程序员在自己的小隔间工作，但小隔间不能用在结对编程上。
8 - 大多数软件公司还是使用传统的招聘方式： 好的结对意味着有合适的人合适的环境，很多公司的招聘方式并不能保证这一点。
7 - 大多数软件公司会容忍不合群的行为：结对需要双方都谦虚（或者像Obie说的那样，需要强力推行“没有混蛋守则” ）。不合群（不和谐）的行为不能参合到结对里面来，但很多公司并不会积极处理这种有不良举止的程序员。
6 - 大多数人不理解结对的生产力：关于结对的一个由来已久的误解：“难道这不就降低了一半生产力吗？”
5 - 很多软件公司招聘了不合格的开发人员
4 - 很多软件公司都超负荷以及人员不够：结对编程，尤其在刚开始的胡乱搭配阶段，可能需要更多的人（但不需要更多时间），但很多公司没这么多人。
3 - 很多软件开发人员并不会每个人都喜欢：除非你能有个由善于交往的人组成的小团队，不然你得经过一段痛苦期才能让大家开开心心地一起工作
2 - 很多软件开发人员就是不想那么努力工作：结对编程非常紧凑，会引领着你努力工作，但很多人并没有激情那么努力地工作，
1 - 很多软件公司并不真正地追求卓越：投资结对意味着投资工艺，但很多公司并没有兴趣
Obie的列表（我在这里做了精简概括，但在你得出判断前，请完整地阅读一下他的文章），并不武断，引发来很多讨论，大部分都在他博文的那个长长的评论列表中。
Brian Guthrie花了点时间做了一份他自己的列表用来反驳Obie的观点。他这么说道：
Obie和他的公司Hashrockets提供了适宜的结对环境，但是很多初次尝试这一实践的人并不会有那种工作环境，而且你也不必都需要有那些。他在列表里面罗列了他认为Obie遗漏或者不尽然的5项：
5 - 结对编程不需要很昂贵的硬件： 如果这是你能用的全部，那么一台配置完好的电脑，一些备用的鼠标和键盘，一个会议室就足够你开始结对了。
4 - 每个人不需要立马能一起工作，并互相欣赏的。合作不好就不结对，但强推一些基本必要的行为准则是每个公司应该能去做的。
3 - 很多公司很乐意去试试结对：公司其实并不像你们说得那样害怕结对。
2 - 很多软件公司非常关注投资回报率：大多数公司并不在乎“卓越”本身，但他们其实很关注减少缺陷以及知识传播，而这些结对能很好地做到。
1 - 结对编程并不是仅仅适用于精英：每个人都可以做到，而且很可能喜欢上结对，并且从中受益良多。这不是核心程序员的专利。
请花点时间完整地读读Obie和Brain的这两篇博文。很可能你自己的经验和想法与这些观点不谋而合。
查看英文原文：Opinion: Pair Programming Is Not For The Masses本文来自：www.infoq.com/cn/news//09/obie-pairing-not-for-everyone
文 / 朱少民
有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改，这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊！
什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：
究竟什么是敏捷测试？
敏捷测试有哪些流程改进？
测试人员如何面对敏捷测试的挑战？
在敏捷测试中如何制定相应的自动化测试策略？
什么是敏捷测试
假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。
图1 敏捷测试定义的形象描述
敏捷测试流程的优化
在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。
在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。
图2 敏捷测试流程简要图
在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：
测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。
参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。
新功能的测试和回归测试策略
测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：
不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。
基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。
回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：
通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小，
基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。
自动化测试策略
由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。
图3 自动化测试的策略
构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试
集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。
敏捷测试工具
自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。
单元测试工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
功能测试自动化：ThoughtWorks Twist。
Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
Web service测试工具（backend）：soapUI。
性能测试：JMeter+BadBoy。
验收测试框架：Fitnesse、Tellurium。
敏捷测试过程管理工具：微软的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。
测试人员在敏捷方法中的价值
在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？
在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。
在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。
产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。
一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。
理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。
总结
根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：
敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。
敏捷功能测试 = 新特性的手工测试（Use Case验证和探索性测试） + 原有功能的自动化测试 （回归测试）。
敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。
作者朱少民，网迅（中国）软件有限公司资深QA总监。中国科技大学软件学院教学指导委员会委员，中国软件测试认证委员会（CSTQB）资深专家。在软件工程 领域颇有建树，先后获得多项科技进步奖、出版十多部著作和高校精品教材，如《全程软件测试》、《软件测试方法和技术》等。
本文选自《程序员》杂志2010年10期，更多精彩内容敬请关注10期杂志
★ 敏捷测试实践
★ 敏捷的反义词
★ 编程学习计划
★ 数控编程技巧
★ 信息编程论文
