敏捷方法的核心思想
-
敏捷方法是适应型（Adaptive），而非可预测型（Predictive）。与传统方法不同，敏捷方法拥抱变化，利用变化来发展，甚至改变自己，最后完善自己。也就是要用重构（Refactoring）
- 敏捷方法是以人为本（people-oriented)，而非过程为本(process-oriented)。传统方法把开发者看作一个生产要素（分析员，测试员，程序员），拥有大量的中间产品（需求规约，设计模型等），而忽视了作为决定因素的人的特殊性。敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
- 迭代增量式的开发过程。敏捷方法以原型开发思想为基础。迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
关于Scrum和XP(Extreme Programming)
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的.
XP的12条实践规则
XP是偏重于实践的，这些实践中有些已大量运用于现代软件开发中。无论你的开发过程是SCRUM还是CMMI，CMMI？是的，这些优秀的软件工程实践并不是敏捷的专享，即使你的开发过程是CMMI，也不影响你使用这些实践。例如TDD，CI(Continues Integration)，Agile 和 CMMI 并不是水火不容的对立关系，而是在某种程度上可以有机的结合。XP的核心价值观是沟通、简单、反馈和勇气。
12条实践规则：
细粒度反馈（Fine Scale Feedback)
- 1. 结对编程（Pair Programming)，即任何代码都有两个人合作完成，一个人coding，一个人review code然后提供反馈。现实中一般不会采用此实践，一种替代方式是定期开code review meeting。
- 2. 规划工作（Planning Game），每个迭代周期开一次计划会议，对此工作周期进行回顾和总结，以及对下个迭代（通常2星期）的开发和发布进行规划。
- 3.测试驱动（Test Driver Development)，程序员在实现功能前应该写好单元测试代码，因为功能代码还没有实现，运行测试的结果可想而知，肯定会失败，程序员的工作就是恰当的代码能使此测试用例通过。这个功能实现的过程也是循序渐进、迭代的，每次实现功能的一小部分，然后运行测试，这样在出现问题时，我们可以很快的定位到问题所在，并很快的解决问题。因为如果你和我一样不是足够聪明的人，我们大脑通常只能记住刚刚发生此的事情。概念同样适用于CI里，对每次Checkin的Regression Test，因为如果你的Checkin造成了对现有功能的破坏，因为问题时你刚刚修改代码造成的，你也能比较容易的定位问题，修复它。
- 4.完整团队（Whole Team），有时也叫客户现场，即客户并不是需求分析后，就万事大吉了，应该驻扎在开发现场，这样开发团队可以获取最新，最准确的客服反馈，确保开发没有偏离客户需求。
可持续发展（Continues Process）
- 5.可持续集成（Continues Integration），项目应该有一套自动编译，自动化测试，自动部署的工具（hudson），程序员应该在最新的代码版本上工作，对于多人并行开发，应该及时的checkin你对代码修改，并保证编译、测试通过。若有问题可以尽早的被暴露，修复。对于减少bug，降低软件风险都有积极作用。
- 6.代码重构（Refactoring),软件随着需求的变化和技术的革新是不断演化的，容易产生代码堆砌，代码冗余等代码中的“坏味道”，用代码重构技术的代码进行及时的清理、调整、重组。有助于提高软件质量和可维护性。
- 7.小版本发布（Small Release），怎样吃掉大象？将一个大的问题域分解成小的，可操作的问题，是解决复杂问题的自然之道。将软件需求分解成小的功能模块，在每个迭代周期中完成预定的部分模块，并形成一个可发布的版本，在Demo此版本时，可以快速都获得来自stakeholders的反馈，而不用将风险延迟到项目的最后。
- 8. 40小时工作制（Sustainable Pace)，可持续发展，不要加班，该打篮球打球。
共识（Shared Understanding）
- 9.代码规范（Coding Standard），统一的代码风格和格式
- 10.集体所有制(Collective Code Ownership), 每个人对所有代码负责
- 11.简单设计（Simple Design），简单是王道，不要over-design
- 12.系统隐喻（System metaphor）,系统隐喻是每个人（客户，程序员，经理）都能理解系统是如何工作的，涉及到如何对Class/Method进行命名，使得团队成员仅从名称上就能想到起功能，例如一个产品过期，那么在Catalog（Class）上有makeOverdue的Method。
如何运用Scrum作为开发过程： http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html