敏捷软件开发？什么是敏捷？
敏捷软件开发？什么是敏捷？
————从敏捷一词出发，探讨敏捷开发与传统开发的不同
敏捷开发（Agile development）是如今软件工程项目中一个大热的词汇，很多大大小小的开发团队都喜欢高举敏捷开发的旗号，搞出一套显得大大不同于传统的运行模式来区分自己的团队博取眼球，他们手头所做的事情，只是套用一套流行的敏捷开发模板，如Scrum，Crystal，XP到自己的开发流程中，就认为自己的整个开发体系会有一个质的飞越。然而他们是否能真正驾驭所谓的敏捷开发？他们是否理解了敏捷开发的核心理念？这都是要划一个大大的问号。
笔者我在刚刚接触这个词的时候，下意识想当然的把他和快速开发划上了等号，但深入了解后发现根本不是这么一回事，关键点出在了敏捷（Agile）词上。通过聊一聊敏捷这个词以及剖析敏捷软件工程与传统软件工程的区别，我试图探寻敏捷这个词背后蕴含的意义。
图1 敏捷开发大致模板
敏捷之于生活
敏捷这个词，在我们的生活中，其实是很少接触的一个词，“他的身手敏捷”这类评论看似常见，但其实细细回忆起来，大部分可能都是你在小说阅读中见到的词，其实我们见到敏捷最多的地方，追溯起来可能各类游戏之中，力量，敏捷，智力三大亘古不变的基础天赋大概是我们接触敏捷这个词汇最多的地方。我们口头上很少去说一个人如何如何敏捷，或许因为这个词蕴含的意思是在是多，比起模糊的形容词，我们更愿意在日常生活中用更简单更暴力更直观的词形容我们眼前正在发生的一切。
即便是在游戏中，又有多少人在不知道敏捷真正意味着什么的情况下，把天赋点都点在了敏捷上？更快的移动速度——更为快速？更高的闪避——更为灵活？亦或是更加犀利的攻击——敏锐？相比于力量和智力，你不知道敏捷的天赋点能给你多大的收益，那么你的角色是培养失败的。软件工程开发也是如此，传统开发点了敏捷的的天赋点后，到底其特性发生了什么变化？没有掌握一切之前，贸然的选择“敏捷”，都是不理智的。
曾经在IBM developerWorks看到过这样一个comment：[1]大家都对敏捷开发到底是何都不是很清楚，这只能说明敏捷一词的含义非常混乱。软件行业中的人们有一个习惯，就是喜欢制造他们想要表达意思的词语，特别是在新技术领域。为了让这个新技术更易理解：我们的技术变化的太快，很多新的术语和简称几乎天天都会出现，我们很难跟上这个速度，因此我们试图对这些新术语产生麻痹的态度，并且希望我们更加的正确。虽然敏捷一词已经出现很久了，但是仍然存在很多术语的滥用问题。
敏捷之于工程开发
敏捷开发的核心理念到底是什么，是更快（quick）的完成一个软件开发工程？抑或是更灵活的（flexible）的去掌握一个软件开发工程？我们要去追溯到敏捷开发的起源去一探究竟。
自2001年起，敏捷对于程序员来说，就不在是一个只存活在游戏主属性中的词汇了。在当年由17人组成的一组自称无政府组织的团体出现，他们齐聚Snowbird Utah来探讨敏捷开发这个过程，探讨他们心中的高质量软件开发过程。
图2 敏捷宣言
这个会议的精华大概可以用他们在会议中定义的有名敏捷软件开发宣言去阐释：[2]
我们一直在实践中探寻更好的软件开发方法，身体力行的同事也帮助他人，由此我们建立了如下价值观：
个体和互动高于流程和工具
工作的软件高于相近的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项目有其价值 我们更重视左项的价值
另外敏捷开发还有其12条准则，在这里引出就不具体进行阐述。
那这么说来，上述的“价值观”中所传递的敏捷到底是什么呢？我认为，那是一种软件开发从业者新定义的意义，他类似而不同于传统的敏捷的定义快速亦或是灵敏，要理解这个敏捷，就必须站立在传统软件项目开发者的角度，朝着突破的角度去重新认识整个软件开发体系，就像参加Snowbird的17人一样。
宣言比对
个体互动 vs 流程和工具
这点直击第一段我所描述的小团体中存在的套用敏捷模板现象，如果你把Scrum，XP等敏捷开发方法看成一个用来执行的模板，那么你从根本上就把敏捷开发本身看成了一个要去执行的流程和工具，要知道，Scrum等敏捷开发方法，是思路绝对不是模板，完整理解了敏捷，他们才显得有意义。
传统的软件工程中，日程（schedule）是铁律，严格按照项目计划去完成开发，是软件工程能够顺利运行的关键。但久而久之，我们发现一个项目的push都是由这么一张流程决定的，在工程的伊始，他的结局就已经决定了，完全取决于那一张流程表（前提还给是能完成）。
然而在注重个体交互的软件开发思想更加的flexible，项目开发的过程中，优秀的团队个体的交互可以碰撞出更多更好的思路，日程表在这之下，随着个体交互的进行而进行不断地修改，所谓1+1>2的效应从一个优秀的个体交互中不断涌出。
但需要知道，这里的敏捷不进蕴含在交互带来的灵活之上，优秀的开发团队本身也是一种敏捷的体现，个体交互这种叠加效应的机制，会让优秀的团队开发出更优秀的东西，但对于一个普通的团队，如果每个人处理自己的手头工作都十分困难，那么不断地交互只会让自己的工作进度更加混乱，观点不在多，在好，繁多的观点只会使得项目变得更加混乱。
正如software management的编辑谈到敏捷开发的人员因素的时候说到得一句话：Agile development focuses on the talents and skills of individuals, molding the process to specific people and teams. Agile processes are designed to capitalize on each individual and each team’s unique strengths.(敏捷开发面向有技术有天赋的个体，铸造特殊的组织的团队，敏捷开发过程是为了适应一个团队里每个人的独特强项。)[4]
工作软件 vs 相近的文档
这点站在了一个相当实际的角度来探讨软件工程究竟为何而生，很显然，传统的软件工程相关的文档，从设计，需求，到开发测试都一应俱全，缜密全面，但事实上最后交付客户的时候他们会很在意文档么？并不会的，他们着眼于一个可用的好用的交付结果，也就是一个可以工作的软件本身，而纷繁复杂的设计文档的缩减在传统软件工程看来，是不规范不严谨的行为，在敏捷开发中变成了一种敏捷的方式。不注重文档不代表没有文档，不代表没有设计需求开发测试规范，一切敏捷，绝不是偷工减料的代名词。
客户合作 vs 合同谈判
敏捷开发方法常常强调一个重点：短期迭代，其意义在于适应当代客户对于需求的不断变化。更短的迭代意味着更多的讨论和修改计划的机会，所有的计划并不是在一开始开发合同中就定死了，随着每一次的迭代，软件的问题和软件的需求在不断地更新，尽早的提供基础软件和客户沟通以及灵活的再次基础上进行调整是敏捷方法实现敏捷的途径。
[5]对于传统的软件工程开发，改变需求是不被提倡的，一切的需求都提前在客户和开发者的合同中被定义好，中途的需求改变都会认为是一种延误工时的不良行为。而敏捷开发不同，对于敏捷开发，改变是被接受的，其改变上限是要和特定的开发环境积极配合的。如果一个开发团队有很多的idea，而客户的需求改变正好能满足这些idea，那么活跃的改变能使这个团队的工作更加完善。
相应变化 vs 遵循计划
敏捷开发承认各种变化，这个思想在前面三组比对中其实就可以看出来，通常敏捷变化的开发过程中，变化是时常需要迎接的机遇与挑战，每一次迭代周期中，团队成员之间的讨论，团队与客户的讨论都有可能是引起新一轮变化的契机。相比于传统软件工程的按部就班，用计划书写效率，敏捷开发则是用灵活诠释敏捷一词。
但还是要注意到一点，敏捷宣言的四条之后，有一句话经常被我们所忽略：“也就是说，尽管右项目有其价值 我们更重视左项的价值”。盲目追求左侧的方法，而全盘否定右侧传统软件开发的意义，盲目信服敏捷带来的一切，这是不可取的。
从上面逐条剖析敏捷宣言中，可以看出敏捷一词的内涵不仅仅局限于我们所熟知的敏捷意义上。确实，敏捷的各个特性都能在其中找到踪影，引用Gray Police[1]说过的一句话：敏捷这个词，对于程序员来说，从那一刻开始，已经拥有了一个新的意义。他不单单是流于形式的快捷，也不仅仅是增加迭代周期的灵活，更多的，我觉得敏捷这个字眼还是落脚于“更快的开发更好对的软件。”如果仅仅将目光拘泥于敏捷开发的模式之上，对于敏捷开发的内涵一无所知，那么及时能从网上找到天花乱坠的开发模板，依然，软件开发中体现不出任何“敏捷”的意义。
参考文献：
[1] Rational Edge: 敏捷软件开发：关于它的起源以及创始人的传记
http://www.ibm.com/developerworks/cn/rational/rationaledge/content/apr07/pollice/#notes
[2] http://agilemanifesto.org/
[3] 敏捷开发之 4句敏捷宣言
http://www.zhoujingen.cn/blog/2591.html
[4] Agile Software Development: The Person Factor, Cutter Consortium, Alistair Cockburn, Humans and Technology
[5] Agile Software Development: The Business of Innovation Jim Highsmith, Cutter Consortium, Alistair Cockburn, Humans and Technology
