摘要
某年会上我作为“砖家”和其他专家一起被摆上台，有人问了一个问题：什么是敏捷？这个问题很难回答，当时我用四个字回答：简单有效。人家一听，这不是大忽悠嘛！本系列文章将会分几篇文章为你分享什么是敏捷，敏捷的“官方”定义，敏捷流程框架及最佳实践，敏捷在中国面临的挑战，实践敏捷所需要的土壤，最后给出我对敏捷的理解。本文是第一篇，我们将从“打针”说起！有没有搞错，“打针”居然和敏捷有关系？是滴，快看看吧！
本文大纲
1.从“打针”说起
2.敏捷的各大门派
3.敏捷四大宣言
4.敏捷十二个准则
5.敏捷的“官方”定义
1.从“打针”说起
互联网中有一张关于敏捷的“神图”，请仔细品味一下：
图1.1 打针与敏捷的关系
在敏捷面前我们都是“小朋友”，小朋友要打的这个针叫“敏捷”！
A）最左边的小胖帅哥，正在打针（正在实施敏捷），你看到他的“精彩”表情了吧！
B）中级的戴眼镜的小帅哥，马上就要到他打针了（即将实施敏捷），他见到小胖哥的夸张表情，整理犹豫和忐忑当中……
C）右边一堆暂时还不需要打针（敏捷“围观”群众）的小朋友，他们是不明“敏捷”真相的围观群众。所谓针不到肉不知道疼，先围观乐着呗……
这个图实在太神了！你属于哪种情况呢？正在实施敏捷？即将实施敏捷？还是围观当中？
2.敏捷的各大门派
2000年初我听说的一种敏捷叫做“XP”，当时还以为这个“XP”与 WindowsXP 有关系呢！长时间的工作积累，让我认识和实践了多种敏捷，以下的敏捷门派，你听说过吗？
1）OpenUP（RUP敏捷版）
2）精益开发
3）极限编程（Extreme Programming,简称：XP）
4）SCRUM
5）MSF（英文：Microsoft Solution Framework，中文直译：微软解决方案框架，可以理解为：微软研发的最佳实践）
6）水晶方法
7）特性驱动开发
有一本书叫《敏捷开发知识体系》对上述提到的大部分敏捷门派都有所介绍，可以考虑入手一本看看。我还是这本书的编委之一呢，不过实在惭愧，我对本书贡献很小，不过我会通过博客和网站陆续为大家分享敏捷方面的文章。
当我提到MSF也算敏捷门派一种时，可能会有朋友会说：不是吧？且听我逐一道来……
MSF是我第一次全面学习和实践的软件研发方法论，后续我又学习和实践了XP和SCRUM，我觉得无论是哪一种都具备敏捷的特点，并且我认为MSF是最全面、严谨和有效的一种。关于MSF，我曾经分享了一个视频课程“微软研发那些事儿”，欢迎看看：http://www.umlonline.org/school/viewthread.php?tid=2491
本系列文章并不会深入讨论MSF，MSF似乎已经“廉颇老矣”，我会分享SCRUM及极限编程方面的敏捷实践为主，将来有机会再详细分享MSF。这里也需要稍微啰嗦一下，我其实并不熟悉全部的敏捷门派，仅仅是对MSF、XP和SCRUM都比较熟，积累了一些实践经验，并且有自己的想法和体会。
3.敏捷四大宣言
敏捷其实无所谓“官方”，你只要足够牛B，你自己都可以建立自己的门派，用你喜欢的名字来命名你的门派！但问题来了，如果这么多门派都说自己才是正宗的敏捷，咋办？
那简单，开一个武林大会决一胜负就是了，谁赢就是正宗滴！所以美国各大敏捷门派开了一个敏捷大会，各大门派血战九九八十一天，决不出胜负，干脆成立了一个敏捷联盟，达成了一个重要的一致决定，那就是：敏捷的四大宣言和十二准则，要满足这四大宣言和十二准则才能叫敏捷！这下好了，决不出胜负，他们干脆抱团结盟，为敏捷立下了门槛了。
哈哈，上述一段是戏说，当家不要完全当真。其实事实真相是：美国各大敏捷流派经过讨论协商后，提炼出各大门派的共性，这就是四大宣言和十二准则。当然可能有人会跳起来说：干嘛是美国？不能是中国吗？我也很想是中国啊，可惜我们在这方面是落后于人家滴，所以只能说人家制定标准，我们学习罗！有朝一日，希望我们能超过美国吧！
我们用一个图看看敏捷四大宣言吧：
图1.2 敏捷四大宣言
看这个图是需要一点“学问”滴，这个图要点是：敏捷是一个相对的词汇，敏捷代表左边比右边更好一点。于是这个图可以用以下四句话来表达：
1）“个体和互动”更优于“流程和工具”；
2）“工作的软件”更优于“详尽的文档”；
3）“客户合作”更优于“合同谈判”；
4）“相应变化”更优于“遵循计划”。
这四句话怎样理解呢？我们先通过几个简单例子来体会一下吧，后面再为大家分享更多文章。
例1：有人说做CMMI就是用一套流程和文档将事情复杂化，然后为了管理这一套流程和文档，再用一套流程和文档来管理前面的这一套流程和文档。这样是相当悲催的事情，说它是反敏捷已经轻了，我觉得是反人类！这样的做法明显就是违背了敏捷宣言的第1、2句话。
例2：某公司过了CMMI3级，过程要求必须产生一系列的文档，结果文档有了，但软件不能工作。这样做明显违背了敏捷宣言的第2句话。实践敏捷的你觉得爽了，这下可以“打正旗号”地不写文档了，但问题哪怕文档不用写，你能保证软件是可以工作的吗？你能做到“持续集成”和“测试先行”吗？“持续集成”和“测试先行”其实就是第2句话所演化出来的最佳实践。（后续文章再为详细大家分享“持续集成”和“测试先行”）
例3：某软件公司为了让客户“高兴”，一直满足客户的“无理”要求，但客户最后还是将软件公司告上法庭，于是双方在法庭上引用合同条款互殴。软件公司律师辩护的理据：一直按照客户的要求来做出软件，软件公司没有过失。客户律师的理据：软件公司没有提供专业服务，没有能满足客户的真正需要。最后法庭判客户胜诉！遇到强势的客户，可能你会觉得难以做到“客户合作”，但如果你一味奉承客户，而不想办法和客户好好沟通，达至双方合作和双赢，最后如果要闹上法庭，我们软件公司败诉的机会是很大的。因为软件是一项专业的服务，客户并不是专业人士，我们要承担更多的过失责任。这个案例体现了“客户合作”更优于“合同谈判”。
例4：为了更好实践敏捷宣言第4句话，我们的项目干脆就不需要计划了，因为计划赶不上变化！请问这是在敏捷吗？恰恰相反，计划正是应对变化的最好办法，但我们的计划需要及时响应变化。“敏捷”常常成为“伪敏捷”外壳，或者成为“手工作坊”模式的遮丑布，这些都是我们需要注意的。
上述4个例子还不能充分说明这四句话的内涵，先简单体会一下吧，我们还需要在实践中反复体会这四句话。
4.敏捷的十二个准则
四大宣言可能有点粗，所以美国敏捷联盟还弄了12个准则，这12个准则可以看成是这四大宣言的细化。
12准则如下：
1）我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2）欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3）要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4）项目过程中，业务人员与开发人员必须在一起工作。
5）要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6）无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7）可用的软件是衡量进度的主要指标。
8）敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9）对技术的精益求精以及对设计的不断完善将提升敏捷性。
10）要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11）最佳的架构、需求和设计出自于自组织的团队。
12）团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
这12个准则比四大宣言多了不少字，是不是已经可以帮助你精准理解敏捷了？
如果你回答是，恭喜你，你是超级小神童！如果你的回答是否，那我们要握一下爪了，伙计，我终于找到一个和我一样的正常人了！
12个准则只能帮助我们稍微了解更多，但可能会带给我们更多的疑问。上述这12个准则，无论你现在理解成怎样，我强烈建议你和你目前的实际工作联系起来，对上述12条准则逐条打分。如果你觉得你目前工作能完全实践这条准则可打10分，如果完全没有实践可打1分，根据你的感觉打1-10分。如果部分准则你完全理解不了，那先不要打分，带着疑问看我后面的文章。
敏捷四大宣言和十二准则，需要不断地通过实际工作来理解和体会！
5.敏捷的“官方”定义
那次年会被人措手不及的问了这个问题：什么是敏捷？
当时我招架不了，回答了：敏捷就是用“简单有效”的原则做事情。
到现在我还死要面子，坚持这个回答是正确的。好吧，我承认我不是什么名人，我说什么是敏捷不算数，那么就来个“官方”定义吧：
那就是“符合敏捷四大宣言和十二个准则的做法，都是敏捷！”
这可不是我说的，是美国敏捷联盟达成一致的结果。但这句话说得轻巧，要理解敏捷四大宣言和十二个准则，需要花多长的时间去实践和体会啊。
作为敏捷入门者来说，先简单了解到这里就可以了；作为敏捷实践资深人士来说，也没有必要就纠结“敏捷”这个概念，有用就行了管他是不是敏捷，敏捷只是个说法而已。
那我为什么要写“神马是敏捷？”这个系列文章呢？后续还有多篇文章将会陆续分享，你将会知道我写这系列文章的真正用意，敬请期待！
请看下一文！
下一篇将为你分享：神马是敏捷？（2）——敏捷流程框架及敏捷最佳实践一览
摘要：SCRUM是当前最火的敏捷流派，我们就以她为代表学习一下吧……