2010年，在Agile@IBM敏捷社区的讨论热点因为集中在“软件全生命周期敏捷”、“分布式敏捷面临的挑战”这两个话题而使得我对敏捷的价值和敏捷宣言又有了新的理解，也促使我从一开始对“核心敏捷”的纠缠不休，到终于放下，用开放的心态去研究IBM内部的诸多相同有不同的敏捷开发过程，这对于我的研究产生了很大的正面影响。
请跟随，我需要大家再次回顾下敏捷宣言的四条要义：
个人与交互 重于 开发过程和工具
可用的软件 重于 复杂的文档
寻求客户的合作 重于 对合同的谈判
对变化的相应 重于 遵循固定的计划
我们将敏捷宣言四条要义来诠释SCRUM方法，且用SCRUM方法中的实践、策略来反射敏捷的这四句从“语法”上不为完整的宣言，我们新的理解得到了12条“敏捷原则”：
1. 我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。
2. 拥抱需求变更，甚至在开发后期。敏捷过程利用变化来为客户提供竞争优势。
3. 经常交付可以工作的软件，从几个星期到几个月，如果可以优先短的周期。
4. 业务人员和开发人员必须每天一起工作。
5. 以人为本，激励个人，同时给予他们所需要的环境和支持，并且信任他们能够完成工作。
6. 团队内部最有效的沟通方法是面对面的交谈。
7. “可工作的软件交付”是首要的项目成功度量方式。
8. 敏捷项目必须注重团队的“可持续性”。投资人，开发者和用户应该能够理解和支撑团队保持一个可持续发展的工作强度。
9. 团队持续地关注技能的卓越，和致力于优秀的设计会增强团队敏捷能力。
10. 简约 – 最大化生产力的秘密。
11. 最好的构架，需求和设计出自于“自组织团队”。
12. 每隔一定时间，团队将坐在一起反思如何才能更有效的协作，然后相应地调整其行为。
实践证明，我们的12条原则不但可以诠释敏捷宣言的价值观，又提供了对SCRUM坚实的支撑。有效的软件工程理论的发展离不开精确的定义。而我们领导团队也的确认为IBM需要一个精确的定义。事实上，业界对于敏捷软件开发一直没有正式的定义，有可能永远不会。但IBM的敏捷领导团队给出了一个可能有用的工作定义（来自前IBM首席方法论学大师 Scott Ambler）：
敏捷软件开发是通过一个价值驱动的、有规律地生产高品质的软件的、以具成本效益和有时间观念的方式，也是一种进化性（迭代和增量型）的方法。它是一个高度协作的，有规则有纪律的，自我组织的，其软件利益相关者积极参与的方法。通过利益相关者的参与，因此得以确保团队了解并重视解决其利益相关者的、会变化的需求。使用此方法的团队，即敏捷软件开发团队，将基于其面临的独特环境，而采用适量的敏捷仪式持续的交付。
让我们来展开这个定义一些关键概念：
1. 价值驱动的 —— 将每个迭代目标均设定在建设一个潜在可交付的产品、解决方案时，敏捷团队就持续的为产品注入真正的价值和每次均已可用软件的形式体现出来......
2. 进化 —— 敏捷的共性都是迭代和增量型的。 “迭代”的意思是您正在使用的功能代码版本通过一系列的过程重复，在原有的基础之上增加构建内容，完成每个构建、每个版本直至项目完成的活动。但是，这并不意味着工作本身是重复的......
3. 有规律的生产高品质的软件 —— 据说敏捷主义者必注重质量。他们更喜欢早期进入、且反复测试，以及更为严格的敏捷从业者甚至会采取一个测试驱动的开发方法，这意味着编写一个测试代码和并用刚刚足够的生产代码来实现通过这个测试的方式实现每个功能、每个构建（然后他们迭代）......
4. 成本效益和时间观念的方式 —— 敏捷团队希望实现的功能在优先顺序上，按照他们的利益相关者（或能够代表客户的人）的期望被定义。因此，团队以最大限度的提高投入产出比（ROI）为回报，也正是如此，他们更关注工作的高价值功能，通过利益相关者的定义，从而提高成本效益。敏捷团队也更愿意在每一次迭代中产出可交付的软件（迭代是一个时间框，通常2-4周的长度），以致使得他们的利益相关者根据已交付的成果来决定何时可以有一个正式版本的交付，从而提高了时效性。短迭代周期也缩短了反馈的周期，提高了让敏捷团队及早发现问题的机会（无论成功、失败都是快速的），从而使他们能够勇于正面解决问题，即使当时他们还显得缺乏足够能力和经验。
5. 高度协作的 —— 人们在构建系统，所关系乎开发项目成功的主要决定因素是“个人和他们的协同工作方式”。敏捷团队致力于尽可能的有效的、紧密的合作，这种特质必须是每个人都具备，即使是领导团队也都不能例外。
6. 有规则有纪律的 —— 敏捷软件开发事实上需要从业者、团队拥有更为严格的纪律性，这点胜过传统研发方式下对团队的要求。
7. 自我组织的—— 自我组织的团队意味着这些从事工作的人，自己做计划，自己估算工作量。
8. 利益相关者的积极参与 —— 敏捷团队与他们的利益相关者密切合作，这其中包括最终用户，最终付费的人，企业架构师，支付技术工程师，运营业务人员还有其他许多相关的人。
9. 利益相关者的、会变化的需求 —— 随着项目的进行，当他们面前阶段性地呈现了可以工作的产品的部分功能、即使不足够完整，利益相关者将更好地了解自己想要什么。因此，他们很可能在评审过程中改变初衷、需求。而这个可能的变化源自商业环境的不断的变化，或者源自组织的任务的优先级调整......
10. 适量的敏捷仪式 ——“仪式”是指在项目中使用的流程、规范（方法）。例如，结对编程、文档的审阅、对代码质量和方方面面的讨论......
11. 持续的交付—— 利益相关者显然不关心你如何实现，如何解决问题; 他们只关心你阶段性交付了什么。特别是......