2014年7月1日Scrum中文网深圳敏捷大讲坛的演讲稿。
各位朋友，下午好!
我今天要演讲的题目是：为什么要拥抱Scrum——我的Scrum心路历程。我的名字是Glen Wang。我今天的演讲没有PPT，不过有一份演讲稿，就是我手上的这一份。这份演讲稿将会在3天之内发表在图灵社区，并且也会在我的微博上放一个链接。大家可以用我演讲的题目或者我的名字搜索到。
我相信各位今天来到这里，都带着一双敏捷的耳朵，希望捕捉到一些与敏捷有关的信息。而我今天的演讲比较特别一点，初听起来似乎跟敏捷没什么关系。不过我恳请大家耐心听下去，一定会有所收获的。
Read more →
何时引入敏捷培训或咨询？
这是很多企业都问过的问题，尤其是那些底子比较薄弱，想引入敏捷开发但又很担心失败的公司。
分析
现在整体上敏捷开发培训市场的课程分为几大类。
第一类：概念类 Read more →
功能点估算
第一级简化
上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。
谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。
Read more →
直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。
敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故事点，在老板眼中更接近生产率绩效。
Read more →
度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。
度量敏捷生产率的目的
真正难以回答的是度量生产率的目的是什么？
Read more →
破除法执之后，很容易落入空执，就是认为不存在绝对最好的方法，因此无需追寻，甘于现状。平衡空与有非常困难，这是本篇的内容。
法与空
法与空的对立统一由来已久。
吴伯凡老师举了个例子：“一切事物都是相对的”这句话有什么问题？
Read more →
所谓无住，包括两个含义：不住于法，不住于空。前者比较好理解，后者会在下篇详述。
不住于法，就是不执着于具体方法的意思，就是所使用的方法应该基于实际情况作出判断，而不是认为世界上有最好的方法，必须遵守。
法执
对法的执着，称为法执。
典型的法执，是很多企业使用CMMI的方法。
本人曾经做过10多家企业的CMMI培训、咨询，所需工作日从41天～43天不等。你能想象这么多企业，起点不同，终点不同，人员不同，行业不同，能用相同的咨询工作量完成CMMI改进吗？我和我所在的公司都不是不负责任的公司，我们因此而丢失了几乎所有的要求41天之下的咨询单子，这实际上是一个下限日期，但所有企业都义无反顾地选择了它。
后来我去了欧洲的咨询公司DNV，因为这家公司告诉我他们在欧洲的咨询是150天×2年=1个CMMI级别，在欧洲本部与国外咨询师们交流时真相也是如此，因此充满了新的希望。但结果是我们的咨询业务在国内举步维艰，因为这样做的费用太高了，时间太长了。
41～43的精确性，表明即使用户不只是想要一纸证书，也幻想一定有一种大致统一的方法让企业得以改进。
从98年开始的“言必称MOTO”，到后来的学联想，学华为，到后来不知道该学什么了，请直接给我套模板吧，都是法执的体现。
敏捷法执
敏捷破掉了旧法，但也立了新法。何以见得？
“怎么知道我们敏捷了呢？”“我们这样做，算是敏捷吗？”这些问题，都表明敏捷是有法可依的，否则这些问题就无从说起。而若破除法执，这些问题也就成了伪命题，没有答案也不用回答。
之后细讲“敏捷的未来如何”的时候，会讲到“敏捷开发无论本意如何好，在推广的时候都一定会被掺杂商业利益，从而变坏。”（上次聚会一个专家的话，大家齐点头）
其实在敏捷界早有纷争，各说各的流派好。这些都是因为大家在推广不同的法，自然就会出现纷争。
而实际上，诸法平等无有高下，只有因缘（内因，外缘）的差别，导致不同场景应该使用不同的方法，甚至什么方法都不用而用自创的新的方法。这个在智慧敏捷系列中已有描述。
所以下面这些问题，作为敏捷语境的交流可以，但作为立意的出发点，就有问题：
1. “我们每日立会还开不起来，下个月想推一下”
2. “现在的自动化测试覆盖率是80%，争取做到90%”
3. “我们现在的迭代周期是2周，争取做到一周”
把法当作达到目的的方法，而不是目的，是破除法执的关键。而所谓无住，就是破除了法执，不执着地停留在固有之法上。
破除法执之后，很容易落入空执，就是认为不存在绝对最好的方法，因此无需追寻，甘于现状。平衡空与有非常困难，这是下篇的内容。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
经常听到有人提到敏捷开发与“本能反应”非常近似，比如凡事都需“看着办”，比如“不拘泥于形式”，比如“直击代码，不写无用的文档”等等。
那么敏捷开发与本能反应之间的差别是什么呢？
简单地说，敏捷开发就是无我状态的本能反应。
无我，无人（无我，无人，无众生）
按理说，本能反应是最接近最佳路径的，一线人员，工作现场，当下的问题，一定能在事先预定的路径之外找到更好的方法，除非有个“我”字。
1. 比如测试人员最近的工作繁忙，需要多调度几个测试人员过来，才能保证测试不延期。如果按照本能反应，开发人员中的一些人极有可能过来帮忙测试，或帮助编写一些节省人工的自动测试代码（后者是01年我们团队的做法，最终结果是25个开发人员只需要1个测试人员就能完成测试）；但如果“我们是开发人员，他们是测试人员”，尤其是“每发现一个缺陷，他们得10元，我们扣10元”，这件事情多半就办不成。
2. 比如有一个人在每日例会上说遇到了困难，而另有人对此有非常容易解决的方法。如果按照本能反应，可能一句话就能帮助节省几个小时；但如果“我有我的工作，他有他的工作”，尤其是“如果帮助了他，我的工作可能完不成”，这件事情也多半办不成。
3. 比如某个文档在这个产品中的确不需要写，但是“如果他们不写，做CMMI评估的时候我们EPG组就会比较难办”，那么这个文档到底要还是不要写就真成了一个问题。
这些我与别人的分隔，使得很难在事情上走最佳路径，而多半会在人和分工上走最佳路径，尤其是按“我”的利益来走最佳路径。在这种情况下，本能反应就是错误的。
无现在的我，无未来的我（无寿者）
一个人的时候，也会出问题。
1. 一个设计非常复杂，按本能反应，怎么也应该记录下来点东西。但是如果“我现在心里清楚设计不用写，未来也不一定是谁在维护这些代码”，那么就很容易不写这个文档，却在未来产生很大的麻烦。
2. 一个代码这样写未来可能产生缺陷，但是这个版本这样写最快。如果“我要按最快的方法写，管他未来是谁”，那么多半代码就会很烂。
如果一个人说：我不写文档的原因是“我把设计表达在代码里”，如果代码很漂亮则的确如此，如果代码又很烂，就可见前者只是一个借口。
说实话多数吆喝“代码即设计”的程序员代码都很烂。
创造无我的环境
在多数有我的环境中，对某件事情而言，每个人提出的解决方案都不相同，而且没有一个是与这个事情的最佳解决方案重合的，因为每个“我”都按自己的利益行事。
最终的结果，是为了让这些我能凑在一起工作，创造出无数的部门规范、工作流程、中间文档、计划、中间文档的评审标准等等，用来约束每个我的工作。本能反应也就被压抑了。
“如何创造一个无我的环境？”这个问题在每个具体环境中，都有具体的最佳答案，受到具体人、事、物的限制，很难一概而论。
但如果没有任何前提条件地回答这个问题，倒也有一个“般若”一点的答案，就是“共振”。
所谓共振，就是在能控制的范围内先取得一些成效，以此换取他人及未来的共鸣，从而推广下去的方法。世界上的各种伟人，无一不是以这种方法工作的，影响力能远达万里、千年。
作为个人，首先可以破除现在的我；作为小团队（比如3个人），可以小范围破除我人之分，共进退；作为开发组，可以局部破除分割和个体考核；作为研发部，可以在部门内部推行新的绩效考核体系，等等。
尽管这些事情看起来都有其困难之处，但与那些“万里、千年”的事情相比，却微不足道，几乎可以说基本上只要去做，没有做不成的。
不过共振的原理，就是不谋求一说就通，一做就成，而是找到事物推广的固有频率，走得太快了，难免做不成先驱，反而成为先烈。
本人曾经在10年里频繁地更换工作，目的是找到一个可以“大展宏图”的地方，但都失败了。直到在一家企业固守了3年，结局令我大吃一惊，原来每个企业都是很容易被推动的，唯一要判断的其实只有一个问题：“这个企业值得推动吗？”
共振的内容，在本系列的以后会有2篇以上的文章还会提及。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
重新认识CMMI
CMMI其实是一种敏捷开发方法，何以见得？
CMMI是由美国军方的甲乙双方密切配合产生的国防部招标标准，在美国国防部招标的时候使用这个标准，既没有多余的让某方别扭的，也没有缺少的让某方担心的。
CMMI还是不断改进的，一个涉众如此之广的产品能以这个速度改进，已经很难得了。在招标过程中发现问题，随时都会提交到变更委员会。
所以在CMMI里边，充满了无我之心，无住之法。但是，那里的我和那里的法，不是我们身边的我身边的法。
互联网行业、消费电子行业把CMMI当作起点寻找适合自己的终点，就像北京人去天津旅游的时候绕道上海一样。
CMMI与敏捷能融合吗？
不能。
本人在国内还算是少数CMMI和敏捷客户都是两位数的咨询师，这里断言为不能，不是笔者不知道CMMI中增加了敏捷的内容，也不是笔者不知道双方可以互相借鉴，也不是笔者不认为CMMI与敏捷无法在一个企业中共存。
所谓融合，就是两个体系中其中一个消失，而被另外一个完全包括；或者两个都消失，而合并为一个。
原生态的CMMI与原生态的敏捷开发适应的行业差别很大，这两个行业的业务差别很大，面临的问题和其自身规律差别也很大。在这些行业、问题、规律本身融合之前，方法上的融合只是表面上的。
在未认清两者为何要共存于一处，各自来解决什么问题时，把他们拉到一起来很容易让开发者和企业困惑。
第一段还“其实是一种敏捷开发方法”的CMMI怎么就突然又不能与敏捷融合了？
很简单，这就像适合你的敏捷开发，都无法与适合我的敏捷开发融合一样。你我不同，融合它们两个干嘛。
CMMI与敏捷能共存吗？
能。
这就像桌子和椅子，没有融合的必要，但摆在一起还是挺搭配的。
但是桌子是桌子，椅子是椅子，各有各的用途。
如果觉得吃饭只有桌子不舒服，可以搬椅子来坐；如果觉得干坐在椅子上玩电脑不舒服，可以买个电脑桌。
但如果偏偏用敏捷开发管理军工项目，用CMMI管理互联网产品，就有点碗筷、电脑房子椅子上，人坐在桌子上一样，似乎可行，又无比别扭。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
正法，像法，末法
任何事物，都会经过这三个阶段，有的短至几年，有的长达几千年。
正法时代一般是原创者掌握话语权的时期，因此能正确地解释和传播。
正法时代传播的是智慧和般若，而不是知识（方法，具体的实践等）。
Read more →
