敏捷开发(Agile development)描述了一套软件开发的原则，通过自组织跨职能团队的协作努力，使客户需求和解决方案得以高效发展。它倡导适应性规划，进化型发展，早期可交付和持续不断改进，并鼓励对变化做出快速灵活的积极反应。这些原则支持许多软件开发方法的定义和持续演进。
敏捷开发核心价值观
- 以人为本，个体和互动高于流程和工具。
- 目标导向，可有效工作的软件高于详尽的文档。
- 客户为先，客户合作高于合同谈判。
- 拥抱变化，响应变化高于遵循计划。
也就是说敏捷开发更重视位于“高于”左边项目的价值。
敏捷开发的团队说：“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。”
敏捷宣言基于十二个原则
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
Scrum
Scrum是一个用于软件产品进行迭代开发和增量管理的敏捷开发框架，它是敏捷开发的一种常见实现方法。它定义了“一个灵活的，整体的产品开发战略，其中开发团队作为一个单元来实现共同的目标”，挑战根据传统的，顺序的方法即从假设需求到产品开发。Scrum团队鼓励所有的团队成员，通过紧密的日常沟通（包括线上线下）来进行高效的合作。
Scrum的一个关键原则是它认识到，在产品开发期间，客户会改变他们的需求（通常称为需求波动性），而且这种不可预测的需求变化带来的挑战并不能以传统的方式来进行预测或计划。因此，Scrum采用基于事实的响应方法，那就是接受这些不被完全理解或定义的需求变化，将精力集中在最大化的提升团队的快速交能力，积极响应新出现的需求，通过不断适应技术的发展和市场条件的变化来完成产品的开发。
对于功能需求可能经常发生变化的项目来说，Scrum是理想的选择。简单的描述一下一个采用Scrum的产品开发流程通常是这样：
1.由产品负责人讲好Story（故事）将所有需要完成的工作列在一个Product Backlog(产品功能列表)中，项目开发过程如果需求发生改变也会被添加进去。
2.在每一次Sprint(迭代)开始之前，要开一个迭代计划会议。在会上，Product Owner(产品负责人)为Product Backlog中的各功能需求确定优先级，随后Scrum开发团队按照优先级，从Product Backlog中挑选出他们认为能在本次迭代中完成的任务目标，并确定工作量预估和迭代周期。
3.本次迭代确定要完成的任务从Product Backlog中挪到Sprint Backlog中来（从kanban即看板的角度来看，即从Backlog栏移动到To Do栏）。在Sprint进行过程中，Scrum团队在Scrum Master（开发团队负责人）的主持下每一天都要举行一个简短的Daily Stand-up Meeting(每日站里会议，控制在15分钟内)，以便团队成员了解开发进度（更新自己的Sprint burn down即燃尽图），尽快解决遇到的各种问题（从kanban的角度来看即Doing、Done栏），每日Scrum团队需要提供一个成功编译可以演示的版本。
4.Sprint结束之后，需要开演示会(Review Meeting)。开发团队在演示会上把这个Sprint的开发成果演示给大家看，这个会议很大程度上也是一个评审会；开这个会议之前，本次Sprint的开发成果应该是经过严格测试的。
5.举行回顾会(Restrospective Meeting)，团队成员们会回顾过去的这个Sprint，从中总结经验和教训。完成回顾的产品可以发布作为一个潜在的可交付产品提交给用户，根据新的反馈和需求变化进行快速响应和新的迭代。
这其中有三个角色简单说明一下他们的作用：
- 产品负责人（Product Owner），主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
- 团队负责人（Scrum Master），主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
- 开发团队（Scrum Team），主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
Scrum中的一些关键的点：
- 看板（kanban）
看板是Product Backlog和Sprint Backlog的可视化展示，由开发团队来维护。通常情况下是这样的：
实际工作中是这样的:
看板任务栏的设置根据团队的情况进行设置，一般是Backlog、Todo、Doing、Done。每个团队使用不同颜色的贴纸。现在市场上也有很多Scrum软件很强大，也可以用选择使用软件来实现Scrum管理。
- 燃尽图（Burn Down Chart）
燃尽图是跟踪团队进度的主要工具，燃尽图的横轴可以是整个Sprint的总时间，纵轴可以是 Sprint中所有的任务，其单位可以是小时，人天等。一般来说，燃尽图会使用”Sprint燃尽图”或者”Release燃尽图”，团队每天都需要更新燃尽图。
- 扑克牌估算（Planning Poker）
扑克牌估算的目的是防止项目在开发过程中，估算时间出现问题，导致项目被一些人拖延。
例如一个任务如果A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，完成后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时。
极限编程
极限编程（eXtreme Programming），是敏捷开发的一种软件工程学方法。它秉承敏捷开发的原则强调程序设计团队与业务专家之间的紧密协作、面对面的沟通（比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，更注重软件开发中人的作用。
XP强调的核心价值观是：
- 沟通（Communication），问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。XP认为项目成员之间的沟通是项目成功的关键，并把沟通看作项目中间协调与合作的主要推动因素。因此，项目相关人员之间进行充分、多渠道（最好面对面）的沟通是很有必要的。
- 简单（Simplicity），XP假定未来不能可靠地预测，在现在考虑它从经济上是不明智的，所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急。 在系统可运转的前提下，做最简洁的工作，坚定的专注于最小化解决方案；在开发中不断的优化设计，时刻保持代码简洁、无冗余。需求尽量的简单，设计尽量的简单，代码尽量的简单，文档尽量的简单。
- 反馈（Feedback），尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。强调各种形式的反馈：小交付、短迭代、测试先行等。XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。
- 勇气（Courage），这是最重要的核心价值。因为XP强调要“拥抱变化”，因此对于用户的反馈，提倡积极面对现实和修改问题的勇气，如放弃已有代码，改进系统设计等；勇敢的重构；所有人拥有代码；敢于极限（把好的方法做到极致）。XP认为，软件开发中，人是最重要的一个方面。在一个软件产品的开发中，人的参与贯穿其整个生命周期，是人的勇气来排除困境，让团队把局部的最优抛之脑后，达到更重大的目标。
极限编程的一些实践原则：
- 1.可调整的计划（Adaptive Planning），以业务优先级和技术估计为基础，决定下一版本发布的范围。
- 2.结对编程（Pair Programming），结对编程是一种编程模式。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起整合测试(Integration Test)，一起写文档等。基本上所有的开发环节都一齐肩并肩地，平等地，互补地进行开发工作。结对编程是让两个人共同设计和开发代码的实践。结对者是全职合作者，轮流执行键入和监视；这提供了持续的设计和代码评审。不是两个人做一个人的事情。
- 3.测试驱动开发（Test Driven Development），是指在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。即所谓的先测试，再编码；代码未动，测试先行。 通常包括，Unit Test、Acceptance Test( Functional Test )、Nightly Test、Stress Test等。
- 4.重构（Refactoring），重构是XP的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码做出的修改，以改进代码的内部结构。重构是一种有纪律的、经过训练的、有条不紊的代码整理方法，可以将整理过程中不小心引入错误的可能性降到最低。改进软件的设计，Refactoring帮助重新组织代码，重新清晰地体现结构和进一步改进设计。
- 5.代码集体所有权（Collaborative Focus），代码集体所有权强调的是整个团队，而非个人，即“我们”的代码，而不是“我”的代码。 团队中的任何人都可以改动任何一段代码，但改动后的代码必须通过所有相关的测试。
- 6.持续集成（Continuous Integration），持续集成的思想是任何时候只有一项任务完成，就集成新代码，构造系统并测试。持续集成是每日构建\每晚构建的一种极限形式，是XP的重要基础。测试先行是持续集成的一个重要前提。持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。每次只有一个PAIR在整合，而且必须运行功能测试。需注意，持续集成需要良好的软件配置变更管理工具的有效支持。
- 7.现场客户（Customer Engagement），客户是Team成员和开发人员一起工作，并进行测试。
- 8.小型发布（Frequent Releases），发布过程应该尽可能地自动化、规范化。不断地发布可用的系统以便告诉客户你在做正确的事情。客户使用发布的系统，可以保证频繁地反馈和交流。保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。降低开发风险。所有的发布都要经过功能测试。
- 9.较少的文档（Minimal Documentation），XP强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。
- 10.可持续的速度，XP团队成员以能够长期维持的速度努力工作，保存精力，把项目看做是马拉松长跑，而不是全速短跑。
- 11.站立会议（Stand Up），每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。
- 12.Automated Testing ，自动化测试。为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本。
- 13.简单设计（Simple Design），系统应设计得尽可能简单。
- 14.每周40小时工作制（40-Hour Work）也会被列入极限编程的要求中。“不加班，不熬夜”。XP要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率。
