敏捷开发(XP, SCRUM)

敏捷方法的核心思想

敏捷方法是适应型（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。