敏捷开发 101
基于个人对敏捷的学习和理解，我认为要了解敏捷或敏捷开发，需要从敏捷宣言和原则入手，然后再看具体的实践和工具，忽略了宣言和原则去谈一些繁杂或者花里胡哨的东西，容易偏离敏捷是为了“在实践中探寻更好的软件开发方法”这一初衷，甚至陷入为了敏捷而敏捷的误区。要尝试和实践敏捷，应以此为核心，选用合适个人或团队的工具和实践方式，并根据实际情况，不断改进。
敏捷基本和核心要素
什么是敏捷（Agile）
-
敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则
-
敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法
-
敏捷具体实践通常采用 Scrum 和 XP（极限编程 eXtreme Programming）
敏捷开发金字塔
从价值观引出原则，围绕原则提出各种方法（或者称之为方法论或框架），不同的方法包括一些具体的实践，再到具体的实践中，会使用各种各样的工具。
敏捷开发宣言内容和原则
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
-
个体和互动 高于 流程和工具
-
工作的软件 高于 详尽的文档
-
客户合作 高于 合同谈判
-
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷宣言遵循的原则
我们遵循以下十二条原则：
-
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
-
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
-
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
-
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
-
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
-
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
-
可工作的软件是进度的首要度量标准。
-
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
-
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
-
以简洁为本，它是极力减少不必要工作量的艺术。
-
最好的架构、需求和设计出自自组织团队。
-
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷与精益等关系示意图
极限编程概述 eXtreme Programming
极限编程是一组简单、具体的实践，包括如下十四条：
-
客户作为团队成员
-
用户素材（user stories）
-
短交付周期
-
验收测试
-
结对编程
-
测试驱动的开发方法
-
集体所有权
-
持续集成
-
可持续的开发速度
-
开放的工作空间
-
计划游戏
-
简单的设计
-
重构（时刻在发生）
-
隐喻（metaphor）
不同资料可能有1-2条的细微差别，这里是出自《敏捷软件开发 原则、模式与实践》一书。
极限编程的主要目标在于降低因需求变更而带来的成本 … 成功既需要技术又需要好的合作关系，极限编程致力于同时解决这两个问题。
XP 也是一种软件开发的哲学，基于沟通、反馈、简单、勇气和尊重的价值观
极限编程始于 Kent Beck 的一个实验，他的想法是把编程实践做到极致，看看会发生什么。例如，代码审查代替代码检查。后来，随着越来越多的公司开始采用这种方法，例如日常集成测试等，某些严格的规则开始被忽略。
不同实践框架的对比
摘自 敏捷框架比较：Scrum vs Kanban vs Lean vs XP
-
Scrum 完全可以被称为敏捷软件开发的框架，一个用于开发和维持复杂产品的框架。首先，Scrum 是一个管理框架，一种流程，而敏捷是一种理念，Scrum 非常突出团队自组织能力。
-
Kanban 和Scrum 的关键区别在于：Kanban 是连续的，而 Scrum 是迭代的。Kanban 更适合在 Sprint 期间有大量计划外工作(如支持问题/紧急修复或功能请求)的团队。通过 Kanban 方式，团队可以随时重新排序任务，不需要等待 Sprint 结束。
-
就像 Kanban 一样，Lean 尽量避免浪费，最大限度地为客户带来价值。与 Kanban 不同的是，Lean 有一些关于工程实践的规定（例如 TDD ）。与此同时，Lean 对交付时间的要求不那么严格，团队可能随时准备部署。
-
XP 注重严格的工程实践约束。需要注意的另一点是，理想情况下，所有的 XP 操作都应该一起使用，否则他们将无法正常工作。
参考资料
-
《敏捷软件开发 原则、模式与实践》 Robert C. Martin