【IT168 评论】在敏捷开发中有很多好的想法和实践，这些想法和实践都非常管用：把项目分成小版本发布来进行风险管理和加速回馈;用时间盒(time-boxing)来限制WIP(Working In Process)并让所有人团结一致集中在项目中;仅依靠软件来作为进程度量;进行简单的估算并使用速度来预测团队的表现;和客户保持频繁而紧密的合作;持续集成持续发布以保证代码始终稳定可运行。

　　但是还有一些别的并不是那么重要但被很多人接受的想法和实践：就算你不遵守这些想法和实践你的项目依然可以圆满成功，也不会有糟糕的事情发生。但是有一些想法实践你最好不要去遵守。

　　测试驱动的开发

　　做快速开发的团队需要依赖于一个快速高效测试安全网。在一个测试先行的或者是测试驱动(TDD)的敏捷开发中，没有任何借口可以不写测试用例。在你开始编码前你必须先写好测试用例，然后你就可以采用一些高效的自动测试工具来保证有一个高水平的覆盖测试和回归测试。

　　TDD不仅仅是一种供开发人员测试他们代码的保证手段，它更重要的一种开发技术，这种开发技术能够得到更高质量的代码和一个简单整洁的设计。

　　微软和IBM(通过测试驱动开发实现质量改进，微软研究院，2008)的研究团队发现，虽然TDD增加了15%-35%前期成本(TDD要求开发人员改变他们的想法和工作方式，这减缓了他们的的开发速度，至少在一开始他们的开发速度慢了很多)，但是跟没有采取单元测试的团队相比缺陷密度降低了40%(IBM)或多达60%-90%(微软)。

　　但是在软件制作第12章“测试驱动开发的有效性有多好”中，由Burak Turhan主导的研究表明虽然TDD表面上提高了质量(根据一个或多个通过的测试用例，缺陷的数量，缺陷密度，每次测试发现缺陷数，修复缺陷的工作量，修复密度，预防性维护比例等本衡量)并且可以提高测试的质量(可以使测试错误降低，使测试变得更加容易)，但TDD并不能一直提高设计质量。TDD似乎可以降低代码的复杂度，提高代码的重用率，但是它也能给耦合内聚带来负面的影响。虽然使用测试驱动的开发可以使得方法级和类级的复杂度降低，但包级和项目级却为之变得更加复杂。

　　喜欢TDD的人为之疯狂，如果你也热衷于TDD，那就尽管用它吧。就算你对TDD并不那么感冒，测试先行非常自然的场景也是时不时出现——尤其是当你不得不通过一种特殊的方式来解决一个特殊的问题，或者你要修正一个bug而测试用例已经为你写好的时候。但是更重要的是，你要写一组很好的测试用例不断更新并且时不时运行它们，这跟你在写代码前还写写好代码后没有关系。

　　结对编程

　　根据VersionOne State of Agile Development Survey 2012(敏捷开发调查状况2012)，几乎有1/3的团队采用了结对编程的开发方式——这是一个出乎意料的高数字，这显示出结对编程的良好的组织纪律性，同时表明有很多的团队使用了可以进行结对编程的XP(2%)和Scrum/XP(11%)方法。

　　有采用结对编程的非常好的理由：开发人员一起工作可以通过持续的非正式的审查来提高代码质量和进行信息共享。让开发人员结对或者让开发人员和测试人员结对来一起工作的情况非常常见，尤其是当你在解决一个非常困难的设计问题，或者你碰到一段以前从来都没有接触过的代码而以前开发过类似代码的人就在旁边可以请教，或者你碰到了一个高压力的问题需要解决为此你豪无头绪，或者你在测试系统的一个非常难的部分，或者你的团队又加入了新的成员而这些成员需要基础学习的时候。

　　一些(尤其是性格外向的)人非常喜欢结对编程，喜欢它提供的非常强大的能量和非常难得的认识团队其他成员的机会。但是去强迫那些更喜欢自己单独工作的人去和自己不喜欢的人进行紧密的合作，这显然不是什么明智的作法。结对编程要花费社交成本：和一些有能力的，技术强的，有工作经验的，有自己独特方式的，有自己鲜明个性的或者是有自己职业道德的人一起结对编程你需要非常小心。而且长时间的结对编程让人精疲力竭——一项研究(Vanhanen and Lassenius 2007)发现人们通常一天只结对编程1.5至4个小时，因为成天的结对编程工作强度太大以致于无法接受。

　　在结对《编程或许是有害的》一文中，Jon Evans说结对编程对创造力有负面影响：

　　研究强烈支持这个观点：当在享受更多的不被打扰的自由和隐私空间时，人们才有最好的创意......区别表现突出的大公司的开发人员的并不是更丰厚的工作经验和更高的薪酬，而是他们可以享受的不被打扰的自由的私人空间。”一篇纽约时报的文章大骂结对编程这种所谓“新的集体思维”时这样说。

　　另外在Pete McBreen的“依然质疑极限编程”中指出了一些结对编程的其他缺点和弱点：

　　不鼓励钻研思路，结对编程时开发专注编写代码，所以除非有一天的时间来钻研团队代码才能对代码有一点肤浅的理解。

　　开发变得过度依赖单元测试，假如测试通过了，那么代码就OK了。(这就缺乏钻研了)

　　没有进行详细的极端测试和边缘测试研究，特别是如果他们很难写出测试。

　　当结对编程时很难做到经过详细思考设计的编码，除非另外一个搭档完全控制这个编码过程。通过平时搭档间的权衡，很难建立技术复杂的设计，除非他们已经确定了一个独自会话。

　　结对编程时的个人风格问题，并不是所有的结对者都能像其他人一样。

　　和打字技能、熟练程度不同的人结对编程，往往会导致打字技能好的人完成全部的编码而其他人变得完全被动。