何物谓之敏捷，何物冠之敏捷，何物之为敏捷

说明：本博文最早发布于本人的新浪博客。

前段时间在前公司论坛上发帖，介绍敏捷宣言简体中文版本的最新消息，没想到招来一帮“同事”冷嘲热讽、含沙射影，心中颇为不快。幸好时过境迁，我已不是当时当日那个见着别人不理解、不认同，就会冲上去一定要解释到人家理解的那个傻小子，默默地一笑而过，不再在这些不开窍的人身上浪费时间。但是也依然感到非常沮丧，在诺西杭州这个敏捷很早就生根发芽的肥沃土壤中，依然有这么多人没有真正地理清楚敏捷真正的含义，也分不清楚开发失败或成功与敏捷的关系。当时就想着要写这么一篇博客来诠释我心中的理解，也希望能够同样帮助到其他对敏捷感到困惑、疑虑、怀疑或其他任何感受的朋友们更多地理解敏捷，以及敏捷在国内的现状，和如何帮助敏捷发挥实效的方法。

何物谓之敏捷

敏捷的本源自然是那十七位大牛所写的敏捷宣言，也就是http://agilemanifesto.org/网站上的内容，包括四项价值观和十二条原则。如今它已经被翻译成为（英语之外）二十二种不同的语言，其中就包括繁体中文和简体中文。敏捷宣言的内容非常简单，英文版264个单词，中文492个字。如此简短的文字，自然不可能把实际操作中可能遇到的种种情况一一描述，也不可能给出所有可能的解决方案。

价值观描述的即是思维的顺序，例如，在考虑需要制定的流程或是要开发的辅助工具之前，首先要考虑的是我们的人怎么样，在工作中他们有哪些互动，在这些互动中，他们需要些什么样的帮助，哪些地方是我们通过总结一个标准流程能够规范操作的，哪些地方又是我们提供一个工具的话能够大幅提升工作效率的。也即是说，流程和工具要服务于人，而不是人去满足流程去服务于工具。

而原则描述得则是内心的坚持，是排除万难也要做到的事情，也或者说就是没有任何借口去允许违反原则的行为。例如无法经常地交付可工作的软件，原因也许有很多，但是正确的或者说敏捷的态度应该是“让我们来分析一下无法做到的原因，把困难一个一个的解决，力争到xx月xx日能够开始频繁交付”，而诸如“可是编译很慢”、“一直没有所需硬件”、“测试太慢”、“开发的bug太多”的话语都是借口而不是原因。

比较关注细节的人会发现，虽然网站的名字叫做AgileManifesto.org，但正文的标题却是“Manifesto for Agile Software Development”。我们言必谈“敏捷”，却有许多的人没有注意到我们谈的其实是敏捷软件开发。不管怎么弄，搞“敏捷”的一定不能脱离“软件开发”这个核心。“敏捷”是“软件开发”的一个修饰，是一个形容词。

结合形容词这一特性和敏捷宣言的内容（价值观、原则）可知，“敏捷”并非是一个完整的、全面的、事无巨细的流程，而是一种方式，用于创造新流程、改进老流程的思考的方式。把“敏捷”和CMMI等重型流程进行比较的行为可算是伪命题，“水果”和“香蕉”如何可以进行比较？

何物冠之敏捷

目前国内所言的“敏捷”可谓群魔乱舞，似乎只要有那么一丁点儿的沾亲带故就可以言必称“敏捷”，开口闭口“你这样不敏捷”、“我们一定要敏捷”，却讲不出所以然。人类的本性中肯定有趋炎附势这一条，在软件开发领域也不例外。当“敏捷”越来越火热的时候，“敏捷”就成了一块招牌，可以提升品牌、抬高档次、提高收入等等。同样也成为了许多人借刀杀人的工具，在企业全面转型“敏捷”的大环境下，把自己的提议盖上“敏捷”的帽子，使劲地扣在别人的头上，对该提议的任何意见、反对都被冠以“和企业作对”的头衔予以坚决的打击和灭杀。于是乎，企业里人人自危，“敏捷”迅速转变成人所厌恶的花架子。而最令人心碎的则是，那些被所谓“敏捷”人士搞得很郁闷的人找到突破口后就会大发牢骚，例如公司的论坛，而在此时，会愿意挺身而出，希望能帮助大家看清楚问题，理清楚思路，传达正确的认知，从而能够在未来做好敏捷的，则是真正的敏捷人士，相反那些所谓的“敏捷”人士才不会来到这里献丑呢，也许他们有足够的自知之明吧。而众怒难为，任何一个人的挺身而出，都被看做是一个绝不还手的靶子，盛怒之下没有人在意究竟他们是真正的敏捷人士还是所谓的“敏捷”人士，只管蜂拥而上，理论也好、暗算也好、狡辩也好，把对方欺负得体无完肤。该敏捷人士越是热心地想要解释、帮助大家分析、澄清，越是被抨击得厉害。

不只是企业内部，敏捷所形成的这个市场也如是。挂着“敏捷”的狗头，卖着不知所云的服务的有之；怀抱传播敏捷的梦想，传到授业解惑的有之；浑水摸鱼，什么热门卖什么的跟屁虫有之；空洞的大道理售卖，无甚具体实践经验的有之。而那些刚刚听说“敏捷”的人们，根本就不具备明辨是非的能力，也更谈不上知道谁才是真正在推广敏捷，谁又是挂羊头卖狗肉。当市场上的某个热点消逝之后，也会有需求创造另外一个热点，从而围绕它来搭建一个产业，提供一大群人的口粮。敏捷恰恰是这个领域的下一个热点。

让一切变得更糟糕的是话语权的沦陷。网络的特性导致所有人的语言都处在同一个平面，对于“专家”的判断更先困难，包装完善、风光、言语间意义深远是最容易判断但也最容易被误导的标准。靠谱的人都知道，这样的混乱局面，只能退缩到那个最核心的敏捷人士圈子，靠彼此面对面的相识和交流甚至合作来判断其知识和能力。而这一批人为了满足自身的学习和提升需求，把时间分配给了最高效的活动，也即是面对面的交流和实战，要让他们来鼓吹或是正本清源，他们不觉得有多少的价值。自己切实地着手改善企业的软件开发能力，优化企业交付的客户价值，远比在言语之中一逞口头之快，却根本不知道网络的另一头是否有理解、是否会去真正操作敏捷软件开发来得有成就感得多。话不在多，投机则行。言不求絮，先行为上。

所以，叫“敏捷”的不一定敏捷，真正敏捷的不一定称呼自己是“敏捷”。要有自己的是非判断能力，方能走上真正敏捷的康庄大道。

何物之为敏捷

究竟什么才是敏捷呢？

从方法论的角度讲，符合敏捷的条件的，或者说谈得上是敏捷软件开发过程的，包括如下一些：Scrum，极限编程（XP），水晶方法论，特征驱动开发等。最出名的就要属Scrum和XP了。

从某种程度上来说，凡是说“我们用的是敏捷开发方式”的都是瞎说、乱说。敏捷根本就不是实物，何来在使用敏捷之说。靠谱的说法是“我们用的是Scrum开发方式”，或者“我们部分采用了XP中的实践”。可如果要更严谨地说，其实“我们用的是Scrum开发方式”也不对，因为Scrum本身是一个框架，不是一个完整的开发方法论，说“我们用的是基于Scrum，以及一些XP实践的开发方式”要更靠谱一些。

使用最广泛的，也是目前最流行的其实是Scrum+XP的方式。Scrum提供了管理的框架，给出了如何组建开发团队、管理产品开发的进度、需求管理等等各方面的指导性原则和基础，例如要用且仅用一个优先级排序的列表来管理需求，团队必须是5到9个人之间，每一个迭代结束时要召开回顾会议反思如何提高，等等。它刻意地把具体的操作方法留给了使用Scrum的人，因为不同的人在不同的时间在不同的环境里使用Scrum来管理不同的产品开发和团队，需要采取的具体措施会很不一样，而遇到的困难也会不一样。但Scrum自身的一切都能够无缝的、完美的放入。不管是什么样的软件开发，都应该有一个优先级排序的PBL（Product BackLog），对吧？不管是什么样的软件开发，都应该（可以）由5~9人的自组织团队堆叠而成，对吧？也正是因为它这样的特点，和特别设计出的灵活性，它的目标市场其实并不只是在软件开发领域，只要是应对Complex范畴问题的团队、组织，都可以使用Scrum来管理他们的工作。

而XP则是绝对纯粹的软件开发领域方法，他们关注的就是如何又快又好地写出优质的代码并转化成有价值的软件。所以它最为人知的也就是那些非常具体的工程实践，例如测试驱动开发（TDD）、持续集成（CI）、可接受性测试（Acceptance Testing）等等。不过比较遗憾的是，正因为它关注的是实践，其生效的重点也就在“实践”，而不是描述和理解，就是俗语讲的没啥好说的只管做就好了。真正做XP的估摸着也都忙头埋头干活，没啥精力去鼓吹、宣传和推广它。正好被广泛传颂和使用的 Scrum自身并不提及如何开发代码、分析需求，XP的各个实践就是最好的补充，这也间接地造成它的实践反而享有比XP自身更高的知名度和名声。国内随处可见只知TDD却不知XP的人。

其他的一些方法论，则显得略为冷门，不介绍也罢。当然对于志在未来从事伟大的敏捷推广事业的人，多了解了解敏捷的历史，和其他敏捷方法论是有好处的。至于Agile Modeling等在维基百科上同样被列为敏捷方法论的一类，由于它们可以比较好地融入基于Scrum的开发过程，也不描述了。

总而言之，在国内，我们通常所说的敏捷都是在说Scrum+XP的方式。尤其要考虑到在国内敏捷相关大会中分享最多或者被谈论最多的是类似诺基亚西门子网络这样的大型企业敏捷转型的故事和方式，而它们所采取的正是Scrum+XP的方法，更不要提在国内很活跃的Bas Vodde，他和Craig Larman所撰写的转型两部曲主要描述的也是这个方法。

至于所谓的“敏捷”，其定义也就无穷无尽，我有限的脑容量和脑细胞经不起这样的折腾，各位看官若是有闲可以自愿去了解。

敏捷与项目成功的关系

也正是在前公司论坛上的讨论让我感到很心痛，其中有人抨击“敏捷”，有人提到某产品开发就是采用敏捷算是个好例子，有人就说谁要是把那产品开发成功的原因归功给敏捷他就和谁急，马上又有人出来添油加醋地说“敏捷”啥也不是没有员工们的加班和辛苦劳动项目不可能成功，让“敏捷”这种东西滚一边去。

实在是想要让他们好好地想一想，难道以前大家工作得就不努力吗？可为什么项目还是失败呢？现在某个产品开发成功的原因就只有勤奋工作的员工吗？难道所使用的持续集成系统和单元测试以及测试驱动开发的实践，不是敏捷吗？难道敏捷就在提倡不要勤奋工作吗？

项目的成功也就那么几个关键因素：人、方法、工具。

• 人不好，说什么也没用。敏捷就是在呼喊着让大家把目光回归到人，关注他们的发展，他们工作所需，想尽一切办法帮助他们发挥最大的效率。曾经听到过一个非常可笑的观点“敏捷就是加班”，而这个观点的来源是因为在他的前一家公司老板举着“敏捷”的幌子逼大家加班，可这和真正的敏捷有一毛线的关系啊？敏捷都直接点明了“个人和互动高于 流程和工具”，以及要“激发个体的斗志，以他们为核心搭建项目。”
• 方法不对，事倍功半。同样的时间，先写代码再测试而后修复bug，和使用TDD的方式，除去学习曲线带来的开销，后者远比前者高效。罔顾更好方法的存在，就好比抓着铁锹的根部挖土，汗流浃背没什么产出，还不肯听从别人的劝告“握住木把柄的头更省力”。敏捷宣言里也赫然可见“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。”
• 工具有点像催化剂。人和动物的区别就在于会使用工具，找准切入点，选择合适的工具，就能帮助团队提高生产效率，节约时间投入其他有价值的活动中去。但始终还是应该在先考虑前两者都满足的情况下才寻找工具这个解决方案，不应迷信工具。敏捷宣言里有说“个人和互动高于 流程和工具”，以及“提供所需的环境和支援，辅以信任，从而达成目标。”

其实，敏捷更像是一种运动，一种呼吁大家回归软件开发本质的运动。把人们的注意力从那些繁重、描述极其详尽、似乎万无一失的流程，和似乎无所不能的工具上挪开，回归到软件开发最重要的产物——可工作的软件。不能忘记的是软件开发是创造性的活动，不可能预知遥远的未来，从而需要摸索着前进。为了不至于前进得太过缓慢，所以要依赖团队的力量，集思广益、群策群力，协同作战，弥补短板，形成高效的战斗小队。

这也正是为什么Mike Cohn会在敏捷十年的回顾中说到“我们不再讨论敏捷。不再说“敏捷软件开发”，我们仅仅说“软件开发”，当然一定是敏捷的”。因为它只是一场运动，而不是一个实物。