闲谈：敏捷与否的区分方法、对组织内部人员的现实作用与长远利益

首先说明，这个问题上只是八卦一下一下哈。我认为所谓的对敏捷的理解错误，就是没把“人”放到首位。但敏捷这种放法实际上是虚伪的，我提到好几次的微软自己出版的那本书（叫做《Debugging the Development Process》，有中文版，一时翻不着了，应该叫做《微软研发XX策略》什么的），事实上也强调了如何让程序员顺利展开工作，但却没有敏捷上种种讨人喜欢的说辞。

为什么说它是虚伪的呢，这是因为这种首位并不是真正的关心与重视。你可以观察到，实施敏捷的公司，往往都是外包公司而不是其它。实际上这些组织中任何一个程序员，都不是不可替代的。而结对编程等一系列手段，事实上正是通过人之间的相互作用，加大了劳动强度而不是减小；增加人的可替代性而不是鼓励保留和发展人的独一无二的价值。

在这里我只是想说对内的方面，正是这些让我非常不舒适。敏捷的核心明明是保证劳动强度（和工作整体时间相区别），把人当机器使，但是它却把这一点掩藏得很好。确实，很多单身汉在公司长期加班，身心疲惫但效率很低。这效果比高劳动强度但顺利的进行，效果要差很多，这一点是敏捷真正的优势。但是实际上他的出发点和宣扬加班却不能取得效果的废物管理者，并无二致。

也许正是因为我看过微软对这些问题的阐述（似乎出版于94年），让我觉得这方面的改进，并非非要放到这样一个假模假式的角度去宣传，只要老老实实交代来龙去脉即可。而且敏捷目前采取的这种宣传方式，实际上本身不利于剖析敏捷起作用的核心要点；因为它表面上看起来冠冕堂皇，事实上却不利于跟随者体会其中诀窍。大家都是成年人，光靠忽悠没有用，把事实和道理真正的摆到台面上，即便对于被管理的员工来说，也是可以理解的。从舆论上来看，敏捷似乎正在流行；但是我觉得这是宣传上的流行，而非事实上的流行。这便是好听但词不达意的说法所造成的障碍。

这些障碍的其中一个是在宣传中，处于敏捷团队中的程序员至少有几个水平不错角色，这点上有一个误区。过去我也曾认为，敏捷适合的是有经验的团队；现在我不这么想了。

实际上敏捷的很多手段正是用来对付外包企业中那些马马虎虎能写点代码的Coder，提高他们的效率和工作质量的。不客气的说，事实上大多数Coder和所谓的架构师，如果不在（计算机专业、行业相关、管理经验等等）水平上取得质的突破，也只能是螺丝钉。而通常被敏捷打上“水平差”标签的那些人，实际上是不合格产品，连螺丝钉都当不了。细细一想似乎敏捷也不是完全这么宣传的（想像那些小故事里安排的“新手”角色），这宣传的不同部分，更多的是为了换取受众的自我认同。

需求快速变化是另一个说辞。写写网站、做做外包的工作确实经常面临变化，但对我们这个行业本身的要求就是千变万化的。SAP的核心组件、或者像Windows操作系统，实际上面对的需求和要求要比外包公司实际上是多而不是少。但是开发这些核心部件的公司又如何呢，他们的做法是尽量让产品适应性强、操作简单，自动化程度高、学习成本低。比如，一个正则表达式引擎，提高了多少字符串相关编程的效率呢？

外包公司或者相仿的公司，正是因为做不到这些，而供应链上的其它厂商也暂时性的（相比长远来看）没能提供更加合用的部件，才不得不意识到，*眼前*只能靠公司内部雇佣的Coder，于是我们就要把如何提高工作效率，放到一个首要的位置。很重要的一点自然是，既然是处理人的问题，就要采取合理的行政手段。相比那些把人不当人看的过程方法，这实际上仅仅是不得不做出的妥协。这种妥协恰恰是因为是敏捷要处理的Coder们水平太低，而能拿出通用性强、适应程度高的中间件或者自动化部件的程序员太少了。

事实上拥有后面这种水平的公司即便从事外包，外包团队和核心团队也是明显区隔的。我以前就说过，敏捷往往不是能够用来对付具有核心技术的团队的手段。不过大多数外包公司的问题是根本缺少核心技术，也就只能那样了。哪样呢？解决目前的生存与效益问题。什么时候不具有竞争力了（这是因为来自于通用、易用的自动化组件的竞争），什么时候关张拿钱走人，这只是时间问题。

对于Coder来说，敏捷所制造的气氛往往会造成一种错觉，认为自己的团队是不错的、有经验的团队，自己是具有价值的人。这一点也是我所反感的。当然，手头的工作被机器取代，这自从工业革命开始就是趋势。关键让人痛心的是，咱们这一代人，当我们40、50以后，那会儿失去工作，我们还有多少机会转移到其它领域，或者在编程领域继续提升。这似乎是一个没法改变的命运。毕竟，那些真正掌握核心技术、能在中青年时代积攒足够退休金的人也注定是少数。

只是，过去很多外包公司或者说血汗工厂，确实没意识到螺丝钉也是人（或者说没意识到这些螺丝钉的工作和纺织女工相比有更大的自由发挥空间），想让他们当好螺丝钉，就要使用人的手段的去对付，而不是拿着锤子敲打。这方面就像大家看到的，敏捷的这部分说辞，确实是起到了好的作用。

但无论如何，敏捷实际上是在堂而皇之的忽略这个和每一个普通劳动者的未来息息相关的事实。一个老板可以这样，一套希望在社会上广泛推行的办法也这样就有点说不过去了。

它的手段拙劣在于，他通过借助Coder作为人所具有的道德约束与自我实现心理，唤起一种不那么靠谱的归属感（对敏捷阵营和实施敏捷的组织）。而这种自我实现的感觉是否真的恰如其分的描述了个人和团队在社会中的真实价值，以及这种价值是否能够继续提升，敏捷却丝毫不关心。如果这不能让我们想起什么的话，大家可以想想安利、玫琳凯，或者淘宝的销售团队。

当然，我说的这些并不稀奇。比较一下外包公司的薪水和掌握核心技术的公司的薪水，就知道谁是什么价值，市场和这个社会本身就给出了答案。当然，不现实的事情确实也没必要考虑太多，但是我不认可敏捷的宣传方式。使用假大空的方法，必然造成目前的局面，即表面上声势浩大的运动，实际上大多数人无法受益。当然在这场运动中，很多提供培训的公司并不希望每个公司自己找到问题的解决之道。

说到具体的成功与失败，在Scrum like的基础上，我认为根据组织的具体情况，肯定是要进行具体的填充的。我为什么提到微软那本书，这是为了说明在更低的层次上，实际上有各种各样的好的实践和解决办法。Scrum当然不能达到敏捷，因为Scrum本身就不是为了敏捷去的，这也是我们可以观察到的一件事。

敏捷不是目的，而是具有某些特征的手段的集合。即便作为一种手段，是不是要往敏捷上靠，尤其是是不是适应于一个公司的手段，就因为它还算成功，它就是敏捷的，这是我要说的另一件事。即便是围绕人展开的工作，实际上早在敏捷被提出之前，就已经在实行了。像微软，它既然提出了相似的做法，我们到底怎么判断，我们不能一会儿说他是敏捷（因为手段甚至一部分内涵相似且很成功），一会儿又说他不是敏捷（因为它行动缓慢）。凡是好的效果都是敏捷的，不好的效果就不是来自于敏捷的，全是你自己的问题。

实际上拿对程序员的伺候来说，微软在一定程度上来说是真的，而敏捷才是那个假货。因为在微软内部确实有一批真正具有价值的非螺丝钉程序员，而后者却仅仅为了创造一种增加劳动强度和工作质量的氛围。我认为从这一点上，就能很好的区别非敏捷和敏捷了；而用使用了什么手段或者取得了什么样的效果，即无益于识别，也无益于掌握敏捷对内如何发挥作用的关键点。

虽然我这种区分方式似乎是在致敏捷于不义之地，可事实上问题的关键在于有没有效果，如何起作用，对于从组织到个人，短期和长期的利益分别又是如何；这些必须落实到实处。这正是西方文化的根本。敏捷通过含糊的说词，把自己变成了和“成功”等价的一个词汇，这实际上是偷换概念；这是另一个宣传过程中让人反感的点了。