敏捷开发扫盲

敏捷软件开发是自上世纪90年代Kent Beck提出极限编程【XP】时开始兴起的，这种编程方法用一组价值标准、原则和实践来规划、编码、设计和测试软件；随后很多公司或者是牛人都提出了很多自己所实施敏捷的一些方法、方式；归纳起来有以下一些：XP【eXtreme Programming】、Scrum、Crystal、FDD【Feature Driven Development】、ASD【Adaptive Software Development】、DSDM【Dynamic Systems Development Method】、TDD【Test Driven Development】、LSD【Lean Software Development】等；虽然说各种实施方式方法各不相同，但是所体现的思想是完全相通的，他们的目标基本上都是：减少浪费、提高效率、改进质量；于是在2001年成立了敏捷联盟【Agile Alliance】，并且发布了敏捷软件开发宣言以及相关设计原则；

敏捷软件开发宣言：

• 个人和交流     胜过 过程和工具【Individuals and interactions over processes and tools】
• 可用的软件     胜过 面面俱到的文档【Working software over comprehensive documentation】
• 与客户沟通和交流  胜过 合同谈判【Customer collaboration over contract negotiation】
• 响应变化        胜过 遵循计划【Responding to change over following a plan】

虽然右项也有价值，但是我们认为左项具有更大的价值：

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

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化：

• 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
• 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
• 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
• 粘滞性： 做正确的事情比做错误的事情要困难。
• 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
• 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
• 晦涩性： 很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些设计原则如下：

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

敏捷软件开发实践：

那我们如何来开展敏捷呢，一般来说，有很多的实践是所有敏捷开发都具备的，当然如果你们的团队已经具备了这样的特征，那说明你们已经踏上了敏捷之路，可能你们自己并没有意识到；比如：强调任何的功能都需要有测试用例和测试代码、非常多的短迭代、坚持持续集成、不断的考虑重构、尝试结对编程、开始抛弃瀑布模型转而使用项目墙、每次项目后坚持PPR、每日开展standup meeting……

PS：关于敏捷其实有非常多的理论基础，各种敏捷方法也都有自己所专注的地方，更多的信息可参考：

敏捷开发介绍：http://www.itisedu.com/phrase/200603291800375.html

SOA 和敏捷方法基础：http://www.ibm.com/developerworks/cn/webservices/ws-agile1/

敏捷联盟：http://www.agilealliance.org/

TW首页：http://www.thoughtworks.com.cn

敏捷（agile）开发与极限编程（XP）：http://blog.csdn.net/mood8125/archive/2006/01/21/585354.aspx

敏捷软件开发模型--SCRUM：http://www.cnblogs.com/Ring1981/archive/2006/09/07/496591.html