不知哪儿吹来的一股风，近年来敏捷开发大行其道，都快带上了迷信色彩。似乎个个公司都想变得“敏捷”，这也养活了一大堆专搞敏捷咨询的皮包公司。我工作的公司也没有免俗，请外部咨询公司的砖家亲临指导工作也不是一次两次了。然而每经过一次培训，我就对敏捷多一份疑虑。前两天看到这篇《敏捷开发（名字起得很帅，很忽悠人）原则 括号里面加了自己的理解笔记》，更加坚信自己的怀疑是合理的。下面我也根据自己的实践，小批一下敏捷的三个方面的问题：

  1. 结对编程
    假设先把开发人员简单分为两等（其实多少等都一样）：高手和菜鸟。我们来看结对的结果：两个高手往往争得面红耳赤，因为大多数高手都有自己的特有习惯，更不喜欢自己做东西的时候被人盯着，往往不欢而散，顶多事倍功半；高手加菜鸟，让高手敲键盘吧，得不时给菜鸟讲解影响思路，让菜鸟敲键盘吧，还不把高手给猴急得？两个菜鸟还用说，面面相觑，傻笑吧……
  2. 测试驱动开发
    把传统的方式倒转过来，先写单元测试，再实现，接着重构，最后设计结构。为了单元测试，要抽取本来不需要的接口，要增加本来不需要的属性设置方法，提高了复杂度，降低了效率。对有多分支的复杂逻辑，大多数的时间都耗在了单元测试上，而且因为逻辑复杂，谁又来保证单元测试本身的正确性？对于真正需要特别谨慎对待的业务逻辑，例如用 SQL 查询数据库，却因为不够单元而只能进行传统的验收测试。因为没有早期的接口设计，重构往往成了重写。等最后想把一堆石子凑成一块石头，却发现它们早就变成了一盘散沙……
  3. 开会
    每个冲刺都是前有梳理，后有回顾，两三天就这么在一片欢呼声中流逝过去了。尤其值得声讨的是估计工作量。砖家们往往拿距离的相对大小来说明工作量的估计方法。事实上工作量是一个无法量化的东西，估计它和估计距离简直是风马牛不相及。于是乎估计的过程就成了众人拍脑袋再去掉一个最高分和一个最低分……