敏捷实践的另一种声音

敏捷实践已经获得了越来越多软件公司的支持和推广，但是 Jim Bird 最近在一篇文章中指出，某些敏捷最佳实践其实可以无需遵循，因为它们不会给你带来太多好处，有时甚至是负面影响，这些“不重要”的实践包括：测试驱动开发、结对编程、每日站立会议等。

测试驱动开发

做快速开发的团队需要依赖于一个快速高效测试安全网。在一个测试先行的或者是测试驱动（TDD）的敏捷开发中，没有任何借口可以不写测试用例。在开始编码前你必须先写好测试用例，然后就可以采用一些高效的自动测试工具来保证有一个高水平的覆盖测试和回归测试。TDD 不仅仅是一种供开发人员测试他们代码的保证手段，它更重要的一种开发技术，这种开发技术能够得到更高质量的代码和一个简单整洁的设计。

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

由 Burak Turhan 主导的研究表明虽然 TDD 表面上提高了质量并且可以提高测试的质量，但 TDD 并不能一直提高设计质量。TDD 似乎可以降低代码的复杂度，提高代码的重用率，但是它也能给耦合内聚带来负面的影响。虽然使用测试驱动的开发可以使得方法级和类级的复杂度降低，但包级和项目级却为之变得更加复杂。

结对编程

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

采用结对编程的非常好的理由包括：

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

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

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

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

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

• 不鼓励钻研思路，结对编程时开发专注编写代码，所以除非有一天的时间来钻研团队代码才能对代码有一点肤浅的理解。
• 开发变得过度依赖单元测试，假如测试通过了，那么代码就 OK 了。（这就缺乏钻研了）
• 没有进行详细的极端测试和边缘测试研究，特别是如果他们很难写出测试。
• 当结对编程时很难做到经过详细思考设计的编码，除非另外一个搭档完全控制这个编码过程。通过平时搭档间的权衡，很难建立技术复杂的设计，除非他们已经确定了一个独自会话。
• 结对编程时的个人风格问题，并不是所有的结对者都能像其他人一样。
• 和打字技能、熟练程度不同的人结对编程，往往会导致打字技能好的人完成全部的编码而其他人变得完全被动。

虽然结对编程相比独自编程提高了代码质量，你也可以通过较低代价的代码复审来获得同样的代码质量提高，并且还有一些信息共享的优势。代码复审——特别轻便，离线复审——比结对编程更容易安排，代价更低点并且没有打扰。就像詹森科恩指出的那样，即使开发者们结对编程，你或许仍然需要代码复审, 因为结对编程确实是共同解决问题，但是它并没有包含所有代码复审所涉及的全部问题。还是乔恩埃文斯关于结对编程的老话：

真正的答案是没有答案：独自编程、结对编程还是小组合作要根据环境用你最好的判断来动态结合才是最有效的。 结对编程的确有它存在的意义。（定律又没用了！）在某些情况下，甚至是“绝对对的”。但是坚持 100% 结对编程是盲目的教条主义，和所有的盲目教条主义一样，最终只会适得其反。

每日站立会议

当你有了一支新的团队，而每个人都需要相互了解，并且需要更多的时间理解项目是关于什么的；或者当这个团队迫于上级压力，正在试图修复些什么或者结束些什么的紧急的状况，那么将大家聚集起来开工作例会，甚至也许一天超过一次，这是必要的且有价值的。但是每个人是站还是坐，最终他们在会议上讨论些什么，将由你决定。

如果你的团队已经合作一段时间也合作的很好，而他们每个人都互相了解并且知道他们在做的是什么，如果开发人员做完事情的时候，在任务板或看板上更新卡片，或者在一个电子系统里更新状态，如果他们足够成熟可以在需要的时候请求帮助，那么你不需要每个早上在房间里 让他们都站着。