敏捷开发般若敏捷系列之六：如何推广敏捷（下）（以无我之心，行无住之法）
说了这么多，五六七这三篇与如何推广敏捷有什么关系呢？
推广CMMI过程中的失误
在回答如何推广敏捷敏捷之前，先回顾一下推广CMMI中存在的失误。
本人在3家企业内部推广过CMMI，为10多家企业从外部做过咨询和培训，CMMI肯定对企业有帮助，但是并没有想象中那么好。试点项目完成后，证书拿到，多数企业并没有在其内部完整推广，甚至试点项目都发生了退步。究其原因，莫过如下：
1. 各利益单位的目的不同，利益不统一（执着于我，人，众生）
一次CMMI认证的主要受益者包括：政府/软件园涨面子，企业/市场/销售部门有证书能拿单子，EPG组完成任务有绩效
但对于主要投入人员即项目组，其利益本来是用过程来管理项目，减少浪费，节约人力。但由于前面一个利益受众过于执着于自己的利益，所做的过程更像能迅速通过CMMI的，而不像能帮助项目的。所以多数项目，都把自己当作受害者。
2. 对回报要求太直接，太短期（执着于寿者，即回报）
证书，是一个直接，但是也很短期的回报。
真正长期的回报：改善整体绩效，却以非常微弱的身份存在。
上面两个问题出，或许有很多人反驳说：我们做的挺实在的，我们挑选咨询师的时候专门挑选了有实战经验的，我们的过程都是让一线人员评审过的……
但是国外一个CMMI级别要平均两年，咨询师要花费300人天的现场咨询，与中国的7～12个月+约40人天相比，差距巨大。
有一次我问一个国外咨询师同事：为什么我们那些客户比如宝马、西门子都只是三级？回答说：“四五级的开发成本太高（而不是咨询、过级成本），对他们的客户不利。”反观国内，有几个5级企业是业务需要所做的级别？
还有一个经典问题：CMMI企业能推广敏捷吗？这个问题之所以成为问题，不是因为有人担心敏捷开发不能帮助按CMMI管理的企业，而是想知道用了敏捷开发，CMMI评估是否能过。
无住之法
所谓无住之法，不是说放着现成的书上的敏捷开发方法而不用，要自己发明方法；也不是说我们没事就要改变我们以往的方法，以求无住。
无住之法实际上说：行业不同，企业不同，团队不同，我们自身的位置和问题本来就不同；项目不同，人员经验不同，竞争环境不同，我们自身的位置和问题还在不断变化。
倘若我们在最短时间要找到适合我们的方法，有两个步骤肯定要做：第一，找到一个离我们现在状况很近的起点，比如Scrum，到达这个起点附近；第二，从这个起点开始，寻找适合自己的方法。（不住于空，不住于法；非非法，非法）
这是为什么说“怎么知道我们敏捷了？”是个伪命题，因为首先不需要去“完美敏捷”，所以也不用仔细丈量距离“完美敏捷”的距离。
位置不同，要解决的问题不同，不可能出现一个完美的点，让大家一起靠拢过去。
那么现在书上写的敏捷开发比如Scrum有什么用呢？Scrum是一个很好的起点，但它不是终点。我们朝灯塔航行的目的，是想到达自己的码头，而不是撞上灯塔。
无我之心
即使一个项目经理只想在自己项目里边实施敏捷，都可能陷入我执。何以见得？
比如为了更像敏捷，项目极可能做出一些伤害企业的事情来。比如有家企业就告诉我，他们的PO是客户代表，因为这样“更能拥抱客户价值”。对于定额项目开发，这极可能是灾难性的，因为这位PO不会考虑企业的成本，也不会考虑此项目未来的前景（市场上还有那些客户想要），等等。
而想在整个企业推广敏捷的时候，利益体多了，更容易陷入我执。
因此敏捷开发推广者要以真正的无我之心来推广敏捷。
从空间上说，要综合开发、测试各个团队乃至个人的利益，尤其是那些一般不在“开发团队”范围内的销售、产品、售前、售后人员的利益，进而上升到企业利益的层面上，才能有效推广敏捷。
尤其是自上而下的非一线人员推动的敏捷，极有可能将团队推向“完美敏捷”，而不是团队实际所需最佳敏捷。
本站博客的敏捷开发松结对编程系列大致描述了团队不同个体的利益统一方法，敏捷外包工程系列和项目经理的商业指南系列大致描述了项目经理与销售、售前乃至企业的利益统一方法，敏捷绩效管理系列大致描述了个体、团队的利益统一方法，敏捷开发产品管理系列大致描述了开发团队、产品经理、企业的利益统一方法，敏捷开发智慧敏捷系列则在一些具体场景中，分析了心法的应用（几乎每个场景都涉及两种以上角色的，或短期长期的利益的冲突）。
这些方法的共同特点，是极少出现“制衡”“博弈”等词汇，而更多的是“沟通”“理解”“帮助”“协作”等词汇，这是无我之心的要点。
总结
上月在微博上偶然看见“心法人事物”这五个字，豁然开朗。
心是基本出发点。
法是根本的方法。
人事物则是导致方法成功或失败的内因与外缘。
若以无我之心行无住之法，则可以超越人事物的因缘局限，在任何环境中推行敏捷。
但万事万物需要一个起点，心、法已经确立了，如何在万难的企业环境中开始推行敏捷呢？这就是以后会提到的“共振”。
