Agile 与太极 -敏捷: 到底啥是敏捷
初探什么是敏捷？
过程重要，但结果更重要，因此敏捷仍然要看结果，是否在实施敏捷方法后能够使项目按时按质的完成。敏捷就是又好又块，再精确点就是多快好省。提出这个的一个重要原型还在对于软件开发中的需求不确定性，很难真正做到一开始就把需求全搞清楚，因此敏捷要做到多快好省就必须能够拥抱变化，适应变化。
敏捷仅仅是个词语，企业要解决的是实际在需求经常变化的情况下如何更好的按时按质的完成任务，如果真正能够解决这个问题，这种方法论就是能够为企业创造效益的方法论，敏捷方法论提供了一些最佳实践，给出了一种可以参考和借鉴的方法，也可能还有其它更好的方法。
真正的问题不是要不要敏捷，而是如何做到敏捷？
敏捷开发宣言
1.较之于过程和工具，应更注重人及其交互的价值
2.较之面面俱到文档，应更注重可运行软件的价值
3.较之合同谈判，应更注重跟客户合作的价值
4.较之遵循计划，应更注重响应需求变化的价值
2001 年，十多位软件专家、大师聚集在一起，成立敏捷联盟，发表《敏捷宣言》，开启了软件工程领域的一场敏捷运动，这无疑是世界软件工程史上的一次里程碑事件，它的意义非同凡响。
我们知道，在《敏捷宣言》面世的 10 年之前，有 CMU SEI 过程成熟度模型 CMM 的发表，4 年之前，有 Rational 统一过程 RUP 的发布，2 年之前，有 ISO 9001 的更新。CMM 体系、ISO 体系以及 RUP 框架，都是对软件工程、软件过程改进领域产生了重要影响的宝贵成果。那么，它们（及其他知名的过程标准、参考模型等）是否囊括了所有先进、成熟的软件过程方法、技术和思想，是否是软件过程改进的终极模版？
答案显然是否定的。熟悉 CMM、ISO 和 RUP 体系的人知道，这些成熟模型和成果的获得，其实都植根于不同的软件开发细分领域，代表了这些细分领域专家、大师们的观点和主张，符合他们的经验与认知。而西方《敏捷宣言》、敏捷联盟和诸多新型敏捷方法的出现，可谓生逢其时，很好地反映了世界软件工程界另一些细分领域，另一部份专家和大师们的不同观点与主张。
通过发出不同的声音，解放思想，扬弃传统，积极变革创新，从而推动软件开发方法、技术和工艺的发展，我想，这正是这场敏捷运动的根本价值和意义所在。
西式敏捷Agile解读
作为一名中国程序员，东方软件人，我们应该如何解读这份西式的《敏捷宣言》？
首先，我们看到，敏捷绝不是教条，敏捷同样是一种平衡或权衡（balance or tradeoff）。事实上，张恂和许多朋友一样持有这样一个观点：软件工程（还包括其他行业的所有工程）本质上就是一门有关权衡的科学和艺术。《敏捷宣言》里说的很清楚，右边的东西同样有价值（there is value in the items on the right），《敏捷宣言》并非要彻底抛弃过程与工具、周详的文档、合同协商和遵守计划，只不过西方的敏捷大师们更看重天平的左边，往天平的左边多加了一点砝码罢了（we value the items on the left more）。那么，这个 more 到底是多少呢？
Agile 是多样化的,敏捷联盟中的十几位专家，根据每个人不同的技术特点和主张，大致可以分为这样几个流派（类别）：
Scrum：Jeff Sutherland、Ken Schwaber、Mike Beedle
XP：Kent Beck、Ward Cunningham、Ron Jeffries、Martin Fowler、Robert C. Martin、James Grenning
Crystal：Alistair Cockburn
ASD/APM：Jim Highsmith
Pragmatic Programming：Andrew Hunt、Dave Thomas
DSDM：Arie van Bennekum
Agile MDA/UML：Jon Kern、Steve Mellor
Agile Testing：Brian Marick
此外，我推荐大家及我本人关注的，未加入敏捷联盟的主要敏捷专家还有：
Mary & Tom Poppendick（Lean Software Development）
Craig Larman（Scrum, AID, AUP 和 AM 等）
Scott Ambler（Agile Modeling, AUP, Agile Database 等）
Peter Coad 和 Jeff De Luca（FDD）
Mike Cohn（User Stories and Agile Planning）
从以上的大致分类中，我们可以看到，当前敏捷方法体现出多样化，流派纷呈，各显特色的局面。敏捷，不是一种方法，而是多种方法的集合。您是否想过，为什么这么多流派、风格迥异的软件开发专家、大师们能够走到一起，共同宣传和推广一种新的软件开发思想和理念，推动软件开发工艺的变革？
《敏捷宣言》所反映的价值观和原则，正是能够整合这么多位专家的共同基础与核心。此外，这么多种敏捷方法，是否有什么共性的东西呢？如果我们能抓住它们之间的共性，那么就很可能抓住了理解敏捷，掌握敏捷的关键。
西式 Agile 不是敏捷的全部,我们发现，现有公开发表的敏捷文献中，未涉及或鲜有涉及的关键点包括：
1.如何与软件客户签订一份敏捷的合同，建立切实可行的敏捷契约关系；
2.如何对内部员工进行有效的敏捷考核，而不实行大锅饭体制。
我们认为本质上是敏捷的元素，而未被西方敏捷大师或敏捷联盟列入其中，或重点强调：
1.适度的 OOAD，适度的 UML 建模，适度的前构设计，是敏捷的；
2.有效的模型驱动开发，框架代码自动生成，是非常敏捷的；
3.敏捷的软件重用与管理；
4.敏捷的风险管理。
太级敏捷
张恂认为，中式敏捷的真正源头应该到两千年前的老庄那里去找。
按照中式敏捷理论的推断，XP 大概是所有西式敏捷方法中最不敏捷的一种，因为它具有最好的可操作性，定义得很具体、很细，在规范性、严格性方面恐怕不亚于 CMM 系统中的 PSP/TSP。XP1 中许多做法（practices）的设计是环环相扣、互为支援的，某个环节做不到就可能导致失败，或者给项目带来严重的风险。一个软件开发过程工艺模型刚性很强，必然会失去一定的灵活性和适应性。
我发现，Cockburn 的 Crystal 系列和 Highsmith 的 ASD 大概是最具有灵活性、柔性和适应性的敏捷方法。可惜，因为它们的特点是比较抽象，定义的内容似乎离开发人员的实际操作还有点远，所以普及面、获得的关注程度还不够，今后需要更多地关注如何“着陆”。当然，二者的软件开发哲学思想还是非常值得研究和借鉴的。您是否记得 Cockburn 博士还是一位诗人，他对古老东方的《道德经》也颇有心得？
能不能在最不敏捷的 Agile 方法，与最敏捷的 Agile 的方法之间，找到一个中间地带呢？我想，这是中式敏捷可以施展的地方之一。
那么，中国式的敏捷会是什么样的？
我们提出的中式敏捷，一定是太极的，符合中国传统的阴阳调和哲学思想和现代的辩证唯物主义、历史唯物主义观点。
张氏太极敏捷的基本理论和观点
极限法则：越极限、极端的东西，灵活性越小，其适应面也就越窄。
抽象法则：越抽象的东西，越灵活，可重用度也就越高。
中式敏捷的价值观
1）反对封建主义，教条主义，官僚主义，形式主义和本本主义。
2）软件开发中，一定要坚持定性分析与定量分析相结合的原则。
敏捷做法知多少
Ambler 列举的具体敏捷做法包括（按有效性从高到低排列）：
1 迭代式开发
2 可用软件的经常性交付（* 似乎与“迭代式开发”重复）
3 配置管理
4 白板建模
5 客户测试
6 TDD
7 每日站会
8 积极的干系人参与
9 代码标准
10 代码重构
11 尽早验证架构
12 简化设计
13 灵活的架构
14 演进式设计
15 自我管理的团队
16 初始敏捷架构建模
17 初始敏捷需求建模
18 经常性的现状汇报
19 独立测试
20 架构穿刺（Spikes）
21 书面建模
22 代码审核（Inspections）
23 结对编程
24 数据库测试
25 数据库重构
26 模型评审
27 CASE 建模
这项调查反映了不少有意思的信息，有以下一些特点。
首先，我们看到，“迭代式开发”名列第一，排在了所有有效敏捷做法的最前面，它的重要性是不言而喻的。
第二，敏捷团队不排斥采用传统和有效的做法。
第三，促进反馈与沟通的敏捷做法更受到欢迎（排名靠前），其次是与架构、设计有关的敏捷做法。
第四，比较重型，或操作不便、不太容易掌握的做法（如结对编程、模型评审、数据库重构等）排名靠后。
那么，是否 Ambler 的调查已经囊括了所有敏捷团队可能采用的敏捷做法呢？我觉得可能没有，应该还有其他更加创新的敏捷做法。
转载地址：http://www.zhangxun.com/showdoc.aspx?sname=WhatIsAgile
