敏捷开发一千零一问系列之二：序言及解决问题的心法（无住）

 

无住

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

不住于法

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

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

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

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

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

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

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

但若是觉得已经找到了就停了下来，就不敏捷了。

不住于空

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

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

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

不住于空，就是尽管没有最好的方法，可是不能所以放弃寻找更好的方法。

以往研发管理的教训

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

“为何牛奶要检测氮含量？”“由于氮含量高，就意味着有更多的蛋白质，于是对人体更加有益。”若是把后两句给忘了，就产生了往牛奶里边添加三聚氰胺的作法。

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

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

重读敏捷宣言

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

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

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