敏捷软件开发方法要点分析

　　下面的文字来自于《敏捷软件开发 原则、模式和实践》一书，作者是Robert C. Martin。我把这些文字发布在这里，希望对敏捷软件开发还不是很了解的朋友所有帮助。我推崇这本书，是因为它提出了许多有价值的软件项目管理的理念，以及软件设计思想和方法，其中，很多可以直接用在我们的工作中，或用来指导我们的工作----敏捷软件开发是务实的。

　　一、敏捷软件开发宣言

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

　　个体和交互 胜过 过程和工具

　　可以工作的软件 胜过 面面俱到的文档

　　客户合作 胜过 合同谈判

　　响应变化 胜过 遵循计划

　　虽然右项也有价值，

　　但我们认为左项具有更大的价值。

　　二、敏捷宣言遵循的原则

　　我们遵循以下原则：

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

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

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

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

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

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

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

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

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

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

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

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

　　三、面向对象设计的原则

　　SRP 单一职责原则

　　就一个类而言，应该仅有一个引起它变化的原因。

　　OCP 开放-闭合原则

　　软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。

　　LSP Liskov替换原则

　　子类型必须能够替换掉它们的基类型。

　　DIP 依赖倒置原则

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

　　ISP 接口隔离原则

　　不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

　　REP 重用发布等价原则

　　重用的粒度就是发布的粒度

　　CCP 共同封闭原则

　　包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对其他的包不造成任何影响。

　　CRP 共同重用原则

　　一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

　　ADP 无环依赖原则

　　有包的依赖关系图中不允许存在环。

　　SDP 稳定依赖原则

　　朝着稳定的方向进行依赖。

　　SAP 稳定抽像原则

　　包的抽象程序应该和其稳定程序一致。

　　四、极限编程实践

　　1、完整团队

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

　　2、计划游戏

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

　　3、客户测试

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

　　4、简单设计

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

　　5、结对编程

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

　　6、测试驱动开发

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

　　7、改进设计

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

　　8、持续集成

　　团队总是使系统完整地被集成。

　　9、集体代码所有权

　　任何结对的程序员都可以在任何时候改进任何代码

　　10、编码标准

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

　　11、隐喻

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

　　12、可持续速度

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

原文转自：http://www.kuqin.com/shuoit/20130916/335244.html