敏捷开发一千零一问系列之三十一：敏捷开发与野路子的区别是什么？（一）

这是敏捷开发一千零一问系列的第三十一篇。（在这里提问，之一，之二，之三，问题总目录）

这是在QQ群中偶然有人提到的一个问题，估计很多人都想知道。特别是有一次培训到半小时左右的，也就是刚听了敏捷概论的时候，有一位客户感慨说：“嘿，我感觉我们做的就是敏捷开发啊”。这是很多人第一次听到敏捷开发时候的正常反应。不过当然两天的课程下来，就会变成“哎呀，以为敏捷主要是一个理念，没想到还有很多具体要做的团队、管理、技术相关的事情”。

那么，这些要做的团队、过程、技术相关的事情，与瀑布/CMM相比很容易找到差距，但I与野路子、游击队的做法相比，到底有什么差别呢？

敏捷开发与野路子的四个主要区别

问题1和2更接近团队管理，问题3和4接近过程管理。

1. 对团队与个体关系的理解不同

在野路子环境里边，由于缺少团队合作，个体和团队的关系不好掌握。比如这些问题比较容易出现：

1.1 忙的忙死闲的闲死

1.2 最难的事情没人做

1.3 出了问题，大家埋怨多帮助少

1.4 高手封闭，新人成长无人问津

……

所以，无论用了什么敏捷，或者不是传统敏捷的方法，都应该问自己：这些问题解决了吗？否则即使名义上不是“野路子”，实际上还是。

敏捷开发里边提到了很多团队合作的事情，但又多次提到放弃，“鸡”不要去干扰“猪”，让具体任务的承担者做决定……面对这些貌似冲突的说法，一定要理解他们都是来解决上面提到的问题的，才能知道如何取舍，或融合使用。

比如139团队和松结对编程就是一个比较完善而且容易掌握的方法，基本上解决了上面说的4个问题。其实139团队是一个野路子出身的方法，之前从未见诸于书籍网络，但每个企业内部可能都多多少少有点影子。如果已经有些雏形了，再思考并解决一个问题：“我的团队模型现在能防止这些问题吗？”，那么很多企业都能实行这种团队模型。

2. 长期与短期利益的理解不同

在野路子环境里边，由于缺少对长期利益的思考，经常只顾眼前。比如这些问题比较容易出现：

2.1 因着急赶工而缺乏文档

2.2 因偷懒、不喜欢而不写文档

2.3 因为自己用不着文档就能写代码，而对日后可能看的人是否理解不关心

……

有很多团队选择敏捷开发而不是其他方法，是因为“敏捷开发比其他方法更省事”，但这样做着做着，就可能变成野路子了。因为野路子比敏捷开发更省事，只是大家不好意思提，拿敏捷开发做个挡箭牌。

比如需求和设计（不单纯指文档），存在的周期都很长；而代码中的注释，或可以取代注释的良好结构，日后被追溯的几率都很大。但并非每个敏捷开发团队都具备这些，甚至连“最敏捷”的“代码即注释”也做不到。最后，本来是激励做好编码的“代码即注释”或“代码即设计”等口号，最后变成忽视长期利益的借口。  

3. 过程改进的动力不同

当发现已有方法不适合新情况的时候，团队会如何？野路子团队很可能：

3.1 如果改进需要一些人暂时付出，这些人可能会不同意前行

3.2 如果改进需要整个团队暂时付出，整个团队可能会担心近期绩效的下降而放弃

这两个实际上是大问题1和大问题2的衍生品，如果野路子团队的队长缺少勇气和胆略，这两个问题很难解决；当然，若不缺少，则问题不大。这个说起来其实是敏捷开发自己的理论：人的能动性（队长和队员），胜过过程（就是下面要说的敏捷开发的自我改进）。

敏捷开发中提倡反思。

这个反思，还不完全是Scrum中的反思会，而是真正的反思。技术层面上包括重构，过程层面上包括对管理方法的反思。其实重构和反思正是敏捷12原则中的两个。尽管野路子团队未必就不会反思，但敏捷反思应该包含以下几点：

a. 基于团队的利益进行反思，包括因此产生的项目、产品、客户、企业的利益，而非个体的利益

多数“存在但不合理的”过程，多数都是局部利益僵持不下的结果。

b. 基于长期和短期利益均衡的结果

在混沌管理中，不但空间上人们看不远（更多只能看到自己），时间上也不会远。比如重构其实是需要“可重构的架构”的，如果产品代码是散装的，那么重构的难度可想而知；但如果产品代码是分布在很多很小的基本函数内部，那么每次重构实际要修改的代码可能就很少，多数只是重新排解调用顺序和接口的问题（这个就是“L型代码结构”中发生的事情）。

（待续）