首页上又有兄弟讨论敏捷了。把最近的想法记录一下。
前两天和朋友提到：敏捷，除了对付客户的那一套，其余的更多是一种行政手腕，为了让一般程序员能够保证最低限度效率。说穿了值得注意的具体事项，就那么几个：
1.跟客户搞好关系
2.把东西做的尽量接近对付事的底线
3.压抑或者转移程序员烦燥
4.有效但隐蔽的监督
5.仍旧按部就班的做事
....
其中1最重要，2要做的聪明，3是最不重要的，4和5是要保持的；这基本就涵盖了敏捷的全部内容。这里解释一下，关于5，与比如瀑布式流程相比，实际上是被动态化而且隐藏了。
朋友说：不是敏捷的时候，也是按这个行事啊。
我说：但是有一点是比较阴险的，敏捷强调程序员的个人尊严，忽悠程序员自觉遵守这些。
最不重要的是3，但是对人的重视却要在口头上放到最前线。这就是猴子的那个朝三暮四的故事：越敏捷，就越像这个故事。Scrum是我看起来比较顺眼的一种做法；因为它比较不像这个故事。不过现在Scrum like的做法，往往被划归到敏捷；以前的一些重型方法，非要带上敏捷的帽子。前者是敏捷宣传者们为了在嘴上立于不败之地，扩充自己的范围；后者则属于那些方法的宣传者一种自保的反应，乱认亲戚。
怎么说呢。其实199X年，微软就出版了一本书，详述了很多非常棒的工程策略；书讲的很具体，而这些具体点背后的骨架就类似于Scrum的模型；这也是微软在多年困扰之后逐步发展的。那时候Martin Fowler还处于网管向靠忽悠面向对象（以及一些重型方法）的吃饭的成长期，其它敏捷明星也还没诞生。实际上这些策略，无关什么原则、或者取向，仅仅是一种适合微软和很多其它组织以及组织中的人的研发过程或方法。
你可以说他们轻量、也可以说他们重量。如果考虑到，近年来所认为的重型方法从来就没有广泛成功过，我个人认为很多被敏捷划归帐下的方法，相比历史上不同时期、不同规模的软件开发，实际上还是偏重的、甚至是僵硬的。这不是因为Scrum like缺乏什么现代敏捷的其它内容，事实上，我认为对于很多不同类型的正经软件公司它都刚刚好。如果说微软这些年有什么变化，在我看来一些本身特性就适合乱干的目标上，其流程可能是更加自由了；另一方面就真正的软件开发而言，微软所采用的过程，实际上并不是更轻了而是更重了。
也许有人会不同意，而拿出一些局部的例子来反对这个说法；不过真正比较一下8x年的微软，9x年的微软，和目前Joel嘴里90%的力量保证和谐的微软，就一目了然了。我相信这种趋势很可能存在着一定必然性：除了微软自己，谁也不知道任何其它更合适的驱动这台软件制造机器的方法了。不过，敏捷的宣传者从不会真的去比较和计较这些；因为事实如何根本不重要。
而那些从OOP成长起来并且进入软件工程的权威人士，却犯了一个严重的错误：他们因为自己的屠龙术不堪大用，开始希望向新一轮的鼓噪者联姻。这造成了目前，没有什么方法不是敏捷的局面。但是，重量级宣传者们忽视了一个很重要的问题，即尊严问题。没有这一点，就没有把握住敏捷能在缺乏真正的基础和论证、杂凑各种“最佳实践”就在舆论上获得优势的真正原因。
换句话说，即使Coder实际上只是一个承受了很大重量、但可随时替换的螺母，你也要让他们觉得心甘情愿、或者被某种道德所约束而无话可说，这就是敏捷、这才是敏捷。敏捷没有新东西，但有新说法，这种新说法能驱动一部分人；这本身已经很好。不过作为思考，这还不够。敏捷那含混的宣言和冠冕堂皇的原则下面，其实质到底是什么？
妥协。
这就是敏捷的真正的核心。向人是感情动物妥协、向差劲的编程水平妥协，等等；但归根结底是向目前仍然有待发展的低下自动化水平妥协。在很多工作还不得不用人来代替的情况下，那么如何照顾好这些人肉生产线上的部件，让他们发挥一个可预测的生产力，这着实是门学问。妥协，有时候可以认为是尽量糊弄，从客户到员工；但是妥协并非是不作为：这就造就了敏捷与混乱管理之间的区别。实际上，敏捷确实是如此：他可以是什么过程都没有，也可以是最重型的方法。
关键在于，无论对谁你都必须给他罩上一层含情脉脉的面纱；在这种情况下，谁还敢撕破脸谁就是罪人。至于具体手法，那就自便了。
那么敏捷就是没有弱点了吗？不是。没有人能站在道德高峰上一辈子。实际上敏捷就是当今IT领域的伪卢德派，它对普通受众过分强调了人的作用，而有意忽略了生产力发展的客观需要。谁真真正正的依赖于敏捷那些“XX胜过XX”背后的核心精神，谁就是真正的作坊（而因为Scrum而被划入敏捷的微软并不依赖这些）；而且这种作坊的普遍落后使得它无法像手工机械表那样真正保留一席之地。
当然，敏捷也在提倡持续集成等一系列实践，这充分说明了某些倡导者并不傻。可以自动化的还有什么？这就又要提到几个月前所谓的批量生产的专业人士和依赖少数牛人的争论了：每当自动化前进一步，哪些人会失业？
敏捷是一种令人作呕的姿态。这就是我在网络上站在反对（而不是在现实中拒绝）敏捷的坚定立场上的原因之一。