敏捷还是银弹，这是一个问题

看了几个谈敏捷的帖子，有点小想法。

这是一个浮躁的年代，言不谈敏捷就显得自己落伍，不搞搞scrum就好像没有过程。

敏捷的核心只有两个：短迭代和快修正。

目前讲敏捷过程的书，我看过的最好的是 Applying UML and Patterns第三版。讲的是敏捷式UP过程，实战且可操作。

现在太多人大谈的极限式敏捷，很大程度上依赖于测试驱动，就我所知，国内几乎没有公司可以做到真正的TDD。尤其以敏捷正统自居的ThoughWorks,他们搞的基本都相当于邪教了。

回到最终，需要牢记的一点是：没有银弹。修正与妥协才是寻求成功交付的正确态度。

国内绝大多数的大谈Scrum过程的人，理想主义且缺乏自我认知，他们的理念概括起来是“因为爱所以爱”

无知者无畏。。

这个调调吧，我听着总觉得特可爱。
做不到就怎么样？做不到所以它就不是正确的？大家都做不到所以我做不到也是理所当然的？
人嘛总是需要点自我安慰的对吧？

不过我还是忍不住要好奇一下…
做不到的就是不正确的
所以这正确的“新方法”全都是你能做到的
那这“新方法”它到底新在哪里呢？

这就很有意思了。
敏捷的思辨方式是现实且有一些悲观主义色彩的，内涵无非是在不断小步修正中趋于近似值；我不怀疑由Bob大叔这种层次的选手组成的团队可以轻松驾驭测试驱动；但现实是极限敏捷非常之困难，而国内大肆鼓吹极限敏捷的人貌似都是极度自信的理想主义者。

现实与理想的矛盾，这是不是就是对敏捷本身的亵渎？

有些东西可以试试，当成信仰或银弹就搞笑了。

呵呵，做不到就承认自己做不到。承认以后呢，要是有工夫有兴趣可以花点时间来学学别人怎么做的，可能就学会了也不一定。要是没工夫没兴趣呢，那就认了，毕竟咱们就是比西方发达资本主义国家落后几十年，谁也不能要求说软件就非得挣回这个差距了。

但是你得知道，这些事有人能做到，有很多人能做到，有很多很普通的软件企业里的人能做到，做到了以后效果很好。这样你才有学习的可能性。

所以说到底，其实真没必要太紧张。谁都有不会的事，没必要一见自己做不到的事就赶快贴上个“这事不可能”的标签才能让自己心安。没必要。太紧张会让人失去学习的机会。其实说到底，你学习不学习，跟谁都没有一毛钱关系，无非是你自己的事而已。

对于世间万物的事包括项目，我目前的看法是无论哪种方法都会出现相应的问题，只能去做到平衡，和谐

听朋友说你去给他们公司培训，随便拿一段代码就能重构成非常漂亮的，非常之牛X~

我跟几个人在不同的团队实践过TDD，结对编程，和重构，反正用过的都说好。TDD是个比较模糊的量化标准，有时可以步子大有时可以步子小，也分不清是测试驱动了代码，还是脑袋里别的东西驱动了代码。后来我就变成衡量一个功能完成没，要看相应的测试用例是否全跑通了，测试用例是不是全了。而你的代码是测试驱动出来的，还是别的驱动出来的（比如领域驱动设计，职责驱动设计，设计模式驱动设计之类的），先写了一大堆代码才写的测试用例还是先写的测试用例再在需要时创建产品代码，我就不管了，也管不了。

不过以堆砌代码完成业务当一天和尚撞一天钟的人而言，XP确实是不可能的了。

陛下就是陛下，说的全部是废话

没有测试驱动，根本敏捷不起来。