敏捷开发实践原则

敏捷实践

敏捷原则

捷软件开发宣言
　　我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：
　　＊　个体和交互　　　　胜过　　　过程和文档
　　＊　可以工作的软件　　胜过　　　面面俱到的文档
　　＊　客户合作　　　　　胜过　　　合同谈判
　　＊　响应变化　　　　　胜过　　　遵循计划
　　虽然右项也有价值，但是我们认为左项具有更大的价值。

从上述的价值观引出了下面１２条原则，它们是敏捷实践区别于重型过程的特征所在。

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3. 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5. 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

7. 工作的软件是首要的进度度量标准。

8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9. 不断的关注优秀的技能和好的设计会增强敏捷能力。

10. 简单—使未完成的工作最大化的艺术—是根本的。

11. 最好的架构、需求和设计出自于自组织的团队。

12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

    每一位软件开发人员、每一个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。可是，我们的项目以令人沮丧的速度失败，或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的,但是膨胀的过程方法对于我们的失败至少是应该付一些责任的。敏捷軟件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单的技术。

最重要的敏捷过程—极限编程

极限编程实践

1. 客户作为团队成员

2. 用户素材

3. 短交付周期
   3.1 迭代计划
   3.2 发布计划

4. 验收测试

5. 结对编程

6. 测试驱动的开发方法

7. 集体所有权

8. 持续集成

9. 可持续的开发速度

10. 开放的工作区间

11. 计划游戏

12. 简单的设计
    1） 考虑能够工作的最简单的事情
    2） 你将不需要它。
    3） 一次，并且只有一次。

13. 重构

14. 隐喻
    极限编程是一组简单、具体的实践，这些实践结合在一起形成了一个敏捷开发过程。该过程已经被许多团队使用过，并且取得了好的效果。极限编程是一种优良的、通用的软件开发方法。项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

重构

在不改变代码外在行为的前提下对代码做出修改,以改进代码的内部结构的过程。

可是我们为什么要改进已经能够工作的代码的结构呢？不是还有句古老的谚语：如果它没有坏，就不要去修理它 ！

每一个软件模块都具有三项职责。第一个职责是它运行起来所完成的功能。这也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的，即使能够工作，也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易的阅读并理解它。一个无法进行沟通的模块也是拙劣的。同样需要对它进行修正。