敏捷开发心法之无住

无住
在般若敏捷系列中已经提过，包括不住于法，不住于空。

不住于法
就是不停留在一种固定的方法上。

如果把“敏捷”理解成一个名词，就会出现一个问题：什么是敏捷？又会扩展成Scrum是敏捷，还是XP是敏捷？RUP是不是敏捷？等等问题。

如果把“敏捷”理解成一个形容词，也就是“敏捷的开发方法”，大致能找到敏捷新的定义：敏捷是一种轻量级的开发方法。

如果把“敏捷”理解成一个副词，也就是“敏捷地开发”，就会找到一个更新的定义：敏捷就是不拘泥与形式不断优化地改进开发方法。

用最后一个理解看待开发，敏捷方法的定义就有很大不同。

比如CMMI，如果CMMI1.3修订之后更加适合美国国防部寻找适合的供应商开发军工项目（CMMI是美国国防部的供应商评价标准，而不是一个学术机构总结的通用最佳实践），那么CMMI就很敏捷；而一家企业已经实施Scrum很久了，但其质量、进度与日剧减，但大家坚持使用原汁原味的Scrum，那么反而很不敏捷。

那为什么现在的敏捷方法看起来更像是“轻量级的开发方法”呢？这是因为重量级的敏捷开发方法早就有了（最早的软件工程始于军工、航空航天、银行业），其他行业比如敏捷宣言发表时乃至今日仍盛行的互联网行业却一直没有方法。当他们“敏捷地”寻找的时候，找到了“敏捷的”方法。

但如果以为已经找到了就停了下来，就不敏捷了。

不住于空
“既然敏捷开发也不是最好的方法，那我们何苦要用敏捷方法呢？”“去年你们推CMMI，今年又推敏捷，明年天知道你们又会推什么方法（所以我打算不配合）”。

因为世界上没有绝对最好的编码规范，所以你们别说我的编码烂；因为世界上没有最好的管理方法，所以你们也别说我的方法乱；因为世界上没有绝对的好人，所以且容我再当一次坏人……这是很多人处世的哲学，开发团队也不乏这样的“老油条”“刺头”。

如果把“好”当作一个点，的确没有一种方法只好不坏。但如果把好当作一个方向，那么眼前，这里，这个项目，这个团队，的确有一些方法比另外一些方法好。虽然不是普适的最佳方法，但仍然值得追求。

不住于空，就是尽管没有最好的方法，但是不能因此放弃寻找更好的方法。

以往研发管理的教训
这里不得不提一下以往软件研发管理的教训，尤其是推广CMMI时的教训。

“为什么牛奶要检测氮含量？”“因为氮含量高，就意味着有更多的蛋白质，因而对人体更加有益。”如果把后两句给忘了，就产生了往牛奶里边添加三聚氰胺的做法。

昨天一个学员就提到说他们企业坚持要他们编写一些文档，而他们明明知道这些文档被扔在那里从来没有人看过，不写又不行，问应该怎么办（这个将是1001问系列中的一个问题）。

很多软件企业中的文档、评审、计划、会议并没有起到应有的作用，但却被盲目地坚持着。人们对这些方法的关注甚至超过了最终项目的成败和企业的盈利能力（神奇的是，美国国防部通过对这些方法的关注而大大提高了项目的成功率，但要认为我们只需要学习他们就能成功，则住在法上了）。

重读敏捷宣言
敏捷宣言中关于可运行软件胜过繁杂文档 及 响应变化胜过遵循计划的描述，说的就是这件事情。

不过，为了通俗易懂，敏捷宣言把“敏捷地找到”的方法贴出来了，所以变成了“敏捷的方法”，如果住在上面，就会出问题。

这就像“打土豪分田地”是一个通俗易懂的口号，但如果认为这就是共产主义，等土豪没了，田地分了，也就迷茫乃至要走上歧路了。


ref：http://blog.csdn.net/cheny_com/article/details/7190094