敏捷软件开发 - Agile Software Development - 原则,模式,实践

敏捷软件开发宣言:

我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法.通过这项工作,我们认为:

个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划

虽然右项也具有价值,但我们认为左项具有更大的价值.


敏捷宣言遵循的原则:

-我们最优先要做的是尽早的、持续的交付有价值的软件来使客户满意。
-即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化莱维客户创造竞争优势。
-经常性的交付可以工作的软件，交付的时隔可以从几个星期到几个月，交付的时间间隔越短越好。
-在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
-围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
-在团队内部，最具效果并且富有效率的传递信息的方式，就是面对面的交谈。
-工作的软件是首要的进度度量标准。
-敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能保持一个长期的，恒定的开发速度。
-不断的关注优秀的技能和好的设计会增强敏捷能力。
-简单--使未完成的工作最大化的艺术--是根本的。
-最好的架构、需求和设计出自于自组织的团队。
-每隔一定时间，团队会在如何才能更有效地方面进行反省，然后相应的对自己的行为进行调整。


面向对象设计的原则:

SRP 单一职责原则 - 就一个类而言,应该仅有一个引起它变化的原因
OCP 开放-封闭原则 - 软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。
LSP Liskov 替换原则 - 子类型必须能够替换掉它们的基类型
DIP 依赖倒置原则 - 抽象不应该依赖于细节.细节应该依赖于抽象.
ISP 接口隔离原则 - 不应该强迫用户依赖于它们不用的方法.接口属于客户,不属于它所的类
    层次结构
REP 重用发布等价原则 - 重用的力度就是发布的粒度.
CCP 共同封闭原则 - 包中的所有类对于同一类性质的变化应该是共同封闭的.一个变化若对一
    个包产生影响,则对该包中的所有类产生影响,而对于其他的包不造成任何影响.
CRP 共同重用原则 - 一个包中的所有类应该是共同重用的.如果重用了包中的一个类,那么就
    要重用包中的所有类.
ADP 无环依赖原则 - 在包的依赖关系图中不允许存在环.
SDP 稳定依赖原则 - 朝着稳定的方向进行依赖.
SAP 稳定抽象原则 - 包的抽象程度应该和其稳定程度一致.


极限编程实践:

完整团队
XP项目的所有参与者(开发人员、业务分析师、测试人员等等)一起工作在一个开放的场所中,他们是同一个团队的成员.这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显式他们进度的东西。

计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

客户测试
作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。

简单设计
团队保持设计较好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

结对编程
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上的构建的。

测试驱动开发
程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

改进设计
随时改进糟糕的代码.保持代码尽可能的干净、具有表达力。

持续集成
团队总是使系统完整的被集成.

集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码.

编码标准
系统中所有的代码看起来就好像是被单独一个--非常值得胜任的--人编写的.

隐喻
团队提出一个程序工作原理的公共景象.

可持续的速度
团队只有持久才有获胜的希望.他们以能够长期维持的速度努力工作.他们保持精力,他们把项目看做是马拉松长跑,而不是全速短跑.