敏捷开发原则

～学点新东西

敏捷开发原则

1.尽早的，经常性的进行交付。努力在项目刚开始的几周内交付一个具有基本功能的系统，然后努力坚持每两周就交付一个功能渐增的系统。

2.团队努力保持软件结构的灵活性。这样能够欢迎需求的变化（变化可以为客户创造竞争优势）。因此要学习面向对象设计的原则和模式，这会帮助我们维持这种灵活行。

3.要经常性交付软件，并且是可以工作的软件。周期越短越好。不赞成交付大量文档。

4.业务人员和开发人员要进行频繁的交互，天天一起工作。

5.围绕被激励起来的个人来构建项目，改变对团队工作的阻碍的过程步骤。

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

7.工作的软件是首要的进度度量标准，而不是那些基础结构或者文档。

8.保持一个长期和恒定的开发速度。尽量不要拖延和加班，要善于调整速度完成高质量的标准。

9.关注好的设计和技能，编写高质量的代码。如果今天制造了混乱，不要拖到明天去清理。

10.简单。不要预测明天的问题。高质量完成今天的工作，深信如果明天发生了问题，也会狠容易的处理。

11.每一个成员都具有项目中所有方面的参与劝。最好的构架、需求和实际来自于自组织的团队。

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

原则

1.

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

2.

我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。

3.

经常交付可以工作的软件

，从几个星期到

几个月，时间间隔越短越好。

4.

在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

5.

围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6.

在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。

7.

可以工作的软件是

进度主要的度量标准。

8.

敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。

9.

对卓越技术和良好设计的不断追求有助于提高敏捷性。

10.

简单——尽量减少工作量的艺术是至关重要的。

11.

最好的架构、需求和设计都源于自我组织的团队。

12.

每隔一定时间，团队都要总结如何更右效率，然后相应地调整自己的行为。

极限编程实践

完整团队

用户故事

短交付周期

验收测试

结对编码

测试驱动开发

集体所有权

持续集成

可持续的开发速度

开放的工作空间

计划游戏

简单设计

重构

隐喻

避免设计的臭味

·

僵化性

（

rigidity

）

——设计难以改变。

·

脆弱性（

fragility

）——设计易于遭到破坏。

·

顽固性（

immobility

）——设计难以重用。

·

粘滞性（

viscosity

）——难以做正确的事情。

·

不必要的复杂性（

needless complexity

）——过分设计。

·

不必要的重复（

needless repetition

）——滥用鼠标进行复制、黏贴。

·

晦涩性（

opacity

）——混乱的表达。

设计原则

·

单一职责原则（

SRP

）：一个类应该只有一个发生变化的原因。

·

开放封闭原则（

OCP

）：软件实体应该对扩展开放，对修改关闭。

·

Liskov

替换原则（

LSP

）：子类型（

subtype

）必须能够替换掉它的基类型（

base type

）。

·

依赖倒置原则（

DIP

）：

a.

高层模块不应该依赖于低层模块。二者都应该依赖于抽象。

b.

抽象不应该依赖于细节。细节应该依赖于抽象。

·

接口隔离原则（

ISP

）：不应该强迫客户程序依赖并未使用的方法。

·

DRY

：

Don’t repeat yourself Principle

。通过抽取公共部分放置在一个地方避免代码重复。

·

封装变化

（

Encapsulate what varies

）。

·

面向接口编程而不是实现（

Code to an interface rather than to an implementation

）。

·

优先使用组合而非继承（

Favour Composition Over Inheritance

）。

包和组件的设计原则

重用-发布等价原则（Reuse-Release Equivalence Principle, REP）：重用的粒度就是发布的粒度。

共同重用原则（Common-Reuse Principle, CRP）：一个组件中的所有类应该是共同重用的。如果重用了组件中的一个类，那么就要重用组件中的所有类。

共同封闭原则（Common-Closure Principle, CCP）：组件中的所有类对于同一种性质的变化应该是共同封闭的。一个变化若对一个封闭的组件产生影响，则对该组件中的 所有类产生影响，二对于其他组件则不造成任何影响。

无环依赖原则（Acycle-Dependencies Principle, ADP）：在组件的依赖关系图中不允许存在环。

稳定依赖原则（Stable-Dependencies Principle, SDP）：朝着稳定的方向进行依赖。

稳定抽象原则（Stable-Abstraction Principle, SAP）：组件的抽象程度应该与其稳定程度一致。