解读敏捷2 - 敏捷实施的六个陷阱
随着敏捷日益成为主流，各种各样的敏捷会议召开，一本又一本的敏捷图书出版，一个又一个的公司前赴后继的迈向敏捷，好一番火热景象。这让我回忆起了当年看报时的一个感受，当时每张报纸的显眼处都能看到牛皮癣和肝病的广告，咋一看感觉会治病的人很多，仔细思考下才发觉是根本原因是能治好病的人很少，否则市场上不会那么热闹。敏捷的现状是不是也是如此呢？
“与其做敏捷，不如变敏捷！Be agile rather than do agile.”但对于大多数公司来讲，如果没做过敏捷，怎么知道如何变敏捷。而且做敏捷可以检查和测量，变敏捷则不能，这违背了“不能被测量则不能被管理”的管理定律。但大多数敏捷实施会失败！那些被敏捷后的美好前景吸引、前赴后继奔向敏捷的公司基本上是在自寻烦恼，“苦逼敏捷”开始盛行。
窃以为要想成功实施敏捷必须先解决下面六个问题：
1. 没有目标，为敏捷而敏捷
为敏捷而敏捷，并不是为了解决真正的问题，把手段当做目标。不少公司简单的被市场宣传打动，认为敏捷就代表着好，不敏捷就不好。这些公司往往会被轻易的忽悠，高估敏捷实施的效果，希望通过简单的敏捷实施就能解决面临的很多问题。因为没有目标，他们在实施的时候只能力求规范。这是一种符合国情的管理方式，俗称运动式管理。运动式管理的目标仅仅是为了运动，运动之后才知道自己在裸泳。
贵公司当前的主要问题是什么？实施敏捷要解决哪些问题？哪些问题是不能通过实施敏捷解决的？
2. 没搞懂敏捷
不想变敏捷，只想做敏捷。没有真正投入成本研究敏捷的公司并不知道敏捷因何生效。当然，他们也有研究，例如派人参加两天的CSM培训，拿到证书；或者买进两本敏捷的书籍，看看红绿模式或者知道每天早上要回答三个问题。这种肤浅的研究把敏捷看做过程，而且是非常简单的过程。他们往往会低估敏捷实施的难度，高估敏捷实施的效果，结果在真正实施的时候碰的头破血流。在这种情况下实施敏捷就是一个悲剧。“我遵守所有的规则，人的和神的。而你不遵守规则，但他们爱你胜过爱我。“——《燃情岁月》
敏捷是什么？敏捷到底是怎样发挥作用的？需要多长时间？敏捷对什么没用？
They told me that the world would be changed if I could answer three questions every morning. Now I’ve answered them for a month, why hasn’t the world been changed?
3. 错误的方法：套装癖
套装癖是指人们更喜欢看起来完整的东西来满足他们的心理愿望，以逃避独立思考和解决问题的真正困难。套装癖现象不仅仅发生在敏捷软件开发，它体现了人们对解决方案而不是解决问题的热爱。瀑布模型并不是瀑布模型提出者的本意，但它被曲解成了瀑布模型这样一个软件开发解决方案；之所以提出CMM是为了衡量过程中的质量，但它变成了解决软件开发企业管理问题的解决方案；Scrum不是解决方案，但人们或者是抱怨Scrum解决方案没有提供足够的实践，或者是自己为它加上用户故事、计划扑克和其他实践，一定要把它变成解决方案。人们一边在市场上追逐套装，一边在抱怨套装原来是中看不中用啊。的确，实施一个套装比实施一个实践难多了，但套装癖们还是乐此不疲。
实施敏捷就是实施Scrum吗？真的需要所有的实践吗？有没有哪一个实践做好了，真的有效了？
4. 基础不行
敏捷软件开发还是软件开发，不会因为实施了敏捷，就可以招聘技能更低的人完成工作了。以Scrum为例，Scrum是暴露问题而不是解决问题，解决问题还是要靠人。人与人之间的冲突需要冲突解决能力，团队建设需要领导能力，对业务的深入理解需要对业务的掌握和分析能力，开发人员的设计编码能力更别说。Scrum的创始人说过，白痴也可以用Scrum，然后他又补充了一句，当然，他们只能产出垃圾而已。你们公司需要垃圾吗？
贵公司现在的软件开发能力如何？经过6-12月后，代码的质量能保障吗？开发人员理解业务吗？架构是不是让人很崩溃？
5. 环境冲突
要实施敏捷，却没有实施敏捷所需的环境、人和文化。大多数的公司无法包容为了解决问题突破公司规定，敢指出领导问题的人，在这种公司大规模实施敏捷，纯属找抽。这也是很多人谈到敏捷都会说，敏捷很好，但是在我们公司不适合的原因所在。而且实施敏捷带来的透明性会让坏消息在开始的时候满天飞，能否容忍坏消息？能否正确引导团队的认识？对管理层是极大的考验，其实坏消息一直存在，只是以前被捂住了而已。“贪官奸，清官要更奸。”——来自周星驰《九品芝麻官》
贵公司有没有更奸的清官？能不能容忍坏消息？能容忍多久？鼓励尝试吗？还是对任何“错误”都要惩罚？
6. 高估研发管理能力
软件研发管理能力是被软件开发公司忽视的癌症。有一个非常简单的问题来考察软件研发管理能力，“请问贵公司Code review做的怎么样？”看看管理层如何回答这个问题，到几个项目团队去看看实际做的怎么样，问问开发人员对Code review的感受。Code review是搞软件的人都懂的实践，人人都知道应该做，但是大多数公司在这一点上都不合格。
贵公司有没有一个软件开发实践是真正推下去了，没有应付了事的？哪一个敏捷实践是贵公司准备实施的？怎么真正推下去？
解读敏捷
这就是解读敏捷这个系列的目的了，希望通过这个系列达到如下目的：1）展示我对敏捷的理解，以帮助更多的人真正了解敏捷；2）对实施敏捷提出想法和建议；3）提供一些实例供参考。
虽然看起来很容易，但是敏捷真的很难，需要多年的学习和实践。只想按葫芦画瓢，结果就会是按下葫芦浮起瓢。我的格言是：简简单单就能做好的事不值得付出努力。就是因为难，所以做好了才能成为竞争力，才能与众不同，是这个道理吧。
后续的内容还没有全部构思好，但考虑中的内容包括：
1）实践与理论解析
敏捷有多难？从细节看全局，如何将细节做到极致，从细节理解敏捷。请看后续：解读敏捷实践之结对Review，解读敏捷实践之每日立会。怎么理解套装的Scrum、XP等等。
敏捷背后的理论解析，排队论，博弈等等。
2）实施方法与样例
你想解决什么问题？采用什么方法？问题域分析与道法术器。
3）杂谈
一些相关的事例与感悟。
PS：@larrycaiyu 建议我把名字从《大多数敏捷实施会失败》改成《敏捷实施的六个陷阱》，欣然改之。
