敏捷开发（整合版）_Phoenix-晶

敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1价值观

敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

2原则

敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。

核心原则

◆主张简单

◆拥抱变化

◆你的第二个目标是可持续性

◆递增的变化

◆令Stakeholder投资最大化

◆有目的的建模

◆多种模型

◆高质量的工作

◆快速反馈

◆软件是你的主要目标

◆轻装前进

宣言原则

l  最重要的是通过尽早和不断交付有价值的软件满足客户需要。

l  我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

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

l  业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

l  围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

l  在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

l  可以工作的软件是进度的主要度量标准。

l  敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

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

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

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

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

补充原则

◆内容比表示更重要

◆三人行必有我师

◆了解你的模型

◆了解你的工具

◆局部调整

◆开放诚实的沟通

◆相信直觉

3实践

敏捷建模（AM）在AM原则的基础上定义了一组核心实践（practice）和补充实践，其中的某些实践已经是极限编程（XP）中采用了的，并在 Extreme Programming Explained一书中有详细的论述，和AM的原则一样，我们在描述这组实践时，将会注重于建模的过程，这样你可以从另外一个角度来观察这些已或XP采用的素材。

核心实践

◆Stakeholder的积极参与 我们对XP的现场客户（On-Site Customer）的概念做了一个扩充：开发人员需要和用户保持现场的接触；现场的用户要有足够的权限和能力，提供建构中的系统相关的信息；及时、中肯的做出和需求相关的决策；并决定它们的优先级。

◆正确使用artifact 每个artifact都有它们各自的适用之处。

◆集体所有制 只要有需要，所有人都可以使用、修改项目中的任何模型、任何artifact。

◆测试性思维 当你在建立模型的时候，你就要不断的问自己，“我该如何测试它？”如果你没办法测试正在开发的软件，你根本就不应该开发它。

◆并行创建模型 由于每种模型都有其长处和短处，没有一个模型能够完全满足建模的需要。

◆创建简单的内容 你应该尽可能的使你的模型（需求、分析、架构、设计）保持简单，但前提是能够满足你的project stakeholder的需要。这就意味着，除非有充分的理由，你不应该随便在模型上画蛇添足－－如果你手头上没有系统认证的功能，你就不应该给你的模型增加这么一个功能。

◆简单地建模 当你考虑所有你能够使用的图表（UML图、用户界面图、数据模型等）时，你很快会发现，大部分时候你只需要这些图表符号的一部分。

◆公开展示模型 你应当公开的展示你的模型，模型的载体被称为“建模之墙”（modeling wall）或“奇迹之墙（wall of wonder）”。

◆切换到另外的Artifact 当你在开发一个artifact（例如用例、CRC卡片、顺序图、甚至源码），你会发现你卡壳了，这时候你应当考虑暂时切换到另一个artifact。每一个artifact都有自己的长处和短处，每一个artifact都适合某一类型的工作。

◆小增量建模 采用增量开发的方式，你可以把大的工作量分成能够发布的小块，每次的增量控制在几个星期或一两个月的时间内，促使你更快的把软件交付给你的用户，增加了你的敏捷性。

◆和他人一起建模 当你有目的建模时你会发现，你建模可能是为了了解某事，可能是为了同他人交流你的想法，或是为了在你的项目中建立起共同的愿景。这是一个团体活动，一个需要大家有效的共同工作才能完成的活动。

◆用代码验证 模型是一种抽象，一种能够正确反映你正在构建的系统的某个方面的抽象。

◆使用最简单的工具 大多数的模型都可以画在白板上，纸上，甚至纸巾的背面。

补充实践

◆使用建模标准 这项实践是从XP的编码标准改名而来，基本的概念是在一个软件项目中开发人员应该同意并遵守一套共同的建模标准。遵守共同的编码惯例能够产生价值：遵守你选择的编码指南能够写出干净的代码，易于理解，这要比不这么做产生出来的代码好得多。

◆逐渐应用模式 高效的建模者会学习通用的架构模式、设计模式和分析模式，并适当的把它们应用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那样，开发人员应当轻松的使用模式，逐渐的应用模式。这反映了简单的价值观。

◆丢弃临时模型 你创建的大部分的模型都是临时使用的模型－－设计草图，低精度原型，索引卡片，可能架构/设计方案等等－－在它们完成了它们的目的之后就再不能提供更多的价值了。

◆合同模型要正式 在你的系统需要的信息资源为外部组织所控制的时候，例如数据库，旧有系统和信息服务，你就需要合同模型。

◆为交流建模 建模的次要原因是为了和团队之外的人交流或建立合同模型。因为有些模型是给团队之外的客户的，你需要投入时间，使用诸如文字处理器，画图工具包，甚至是那些“被广告吹得天花乱坠”的CASE工具来美化模型。

◆为理解建模 建模的最重要的应用就是探索问题空间，以识别和分析系统的需求，或是比较和对照可能的设计选择方法，以识别可能满足需求的、最简单的解决方案。根据这项实践，你通产需要针对软件的某个方面建立小的、简单的图表，例如类的生命周期图，或屏幕顺序，这些图表通常在你完成目的（理解）之后就被丢弃。

◆重用现有的资源 这是敏捷建模者能够利用的信息财富。

◆非到万不得已不更新 你应当在你确实需要时才更新模型，就是说，当不更新模型造成的代价超出了更新模型所付出的代价的时候。

确实不错的主意

以下的实践虽然没有包括在AM中，但是可以做为AM的一份补充：

◆重构 这是一项编码实践。重构，就是通过小的变化，使你的代码支持新的功能，或使你的设计尽可能的简单。从AM的观点来看，这项实践可以保证你在编码时，你的设计干净、清楚。重构是XP的一个重要部分。

◆测试优先设计 这是一项开发实践。在你开始编写你的业务代码之前，你要先考虑、编写你的测试案例。

4名词详解

AM是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。AM可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图，你可以看看在建模Artifacts中列出的许多建模书籍，我特别推荐我的书The Object Primer 2/e(尽管这有失公允）。

5建模者

敏捷建模者的个性

Alistair Cockburn指出：很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义各个角色执行的任务，尽管入席，这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能，但人们必须要慢慢的熟悉这些技术。我的经验告诉我，要成为一个成功的敏捷建模者，下面的列出的个性是必要的：

l  团队竞赛

l  畅所欲言

l  脚踏实地

l  好奇

l  实事求是

l  根据实验

l  有纪律

6建模误区

误区一

建模就等于是写文档

这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。

事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在餐巾纸的背面，或写在一块白板上，或在Class Responsibility Collaboration(CRC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。

建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身；价值体现在建模的活动中，而非模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。

误区二

从开始阶段你可以考虑到所有的一切

这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确，试图在编码开始前就“冻结”所有的需求（见误区四），以致于患上“分析期麻痹症” – 要等到模型非常完美之后才敢向前进。基于这个观点，项目组开发了大量的文档，而不是他们真正想要得到的—开发满足需要的软件。

事实分析：怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节。第二，认识到编码员可能会对建模者的工作不以为然（这是可能的，事实上建模者所作的工作在实际价值中只占很少的部分），他们或许会说模型没有反应出真实的情况。第三，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保持一致。第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP）的基本原理。

误区三

建模意味着需要一个重量级的软件开发过程

走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，因为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。

事实分析：你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM）。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。

误区四

必须“冻结”需求，这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上所需要的。

事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。

误区五

设计是不可更改的

如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确的态度是：只要你的代码还在改动，设计就没完。

误区六

必须使用CASE工具

建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。

事实分析：是的，建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息，而不是将一些无关紧要的细节包括进来。

比如，我经常使用UML建立模型来表示类、它们的属性及一些关键的业务操作，但并不画出属性的存取操作（get和set），以及维护与其它类关系的框架代码，或者其他一些琐碎的实现细节。我通过建模寻找解决问题的方法，让我和我的同事能继续前进去实现这个模型。以这样灵活的方式，大多数情况下我并不需要一个CASE工具来支持建模工作，一块白板，或者一台数字相机足以。这样，我就不用花时间去评估CASE工具，不用去和工具供应商讨论许可证的问题，也免去了人员培训开销。CASE工具只有当它能体现最佳性价比时（相对你自己的情况而言），才值得购买。大多数情况下，我都能不用它而达到目的（完成建模）。我经常使用的工具有Together/J/) – 因为它能产生数目可观的Java框架代码；还有ERWin（） -- 因为它能规划数据库。这两个工具真正地帮助我实现了软件开发的目的 – 制造满足用户要求的软件。但我绝大多数得建模工作仍然使用的是简单的工具，而不是CASE工具。

误区七

建模是在浪费时间

许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。

事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该项目中的每个成员也可得到对该项目有一个充分的了解。

误区八

数据模型（Data Model）就是一切

许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规定，控制着你的开发项目；或者你以前的数据库是一团糟，别无选择。

事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。（参见“Extreme Modeling”，Thinking Objectively，Nov.2000）。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的（在数据模型中没有表示出来），这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例（use cases），业务规则（business rules），activity diagrams，类图（class diagrams），component diagrams，用户界面流程图（user interface flow diagrams）和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。

误区九

所有的开发人员都知道如何建模

面临这样一个严重的问题：许多不是开发人员的人，不知道软件是如何建成的。其结果，他们不能够区分开熟练的开发者和一般的程序员（当然也分不清高级程序员和一般程序员），他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。

事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人，包括我自己，都是新手。

7开发宣言

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

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

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

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

8遵循原则

单一职责原则（SRP)

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

开放-封闭原则（OCP)

软件实体应该是可以扩展的，但是不可修改。

 Liskov替换原则（LSP)

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

依赖倒置原则（DIP)

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

接口隔离原则（ISP)

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

重用发布等价原则（REP)

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

共同封闭原则（CCP)

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

共同重用原则(CRP)

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

无环依赖原则（ADP)

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

稳定依赖原则（SDP)

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

稳定抽象原则（SAP)

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

上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

 

个人对敏捷的理解

第一，与用户紧密沟通需求，快速响应并实现用户的需求，保证做出来的每一个模块就是需求想要的；

第二，测试与研发同步进行，保证写完一个模块就对一个模块进行单元测试，对各个接口进行自动化测试；

第三，迭代开发，快速上新，先把部分功能做出来，然后逐步上线；

第四，在软件工程模型中属于敏捷开发模型，以人为本；

第五，每日重构自动化测试用例，每日持续集成；

第六，不鼓励加班

 

什么是极限编程（XP）？？

基于敏捷的核心思想和价值目标，XP要求项目团队遵循13个核心实践

1. 团队协作(Whole Team)

2. 规划策略(The Planning Game)；

3. 结对编程(Pair programming)

4. 测试驱动开发(Testing-Driven Development)

5. 重构(Refactoring)

6. 简单设计(Simple Design)

7. 代码集体所有权(Collective Code Ownership)

8. 持续集成(Continuous Integration)

9. 客户测试(Customer Tests)

10. 小型发布（Small Release）

11. 每周40小时工作制（40-hourWeek）

12. 编码规范（Code Standards）

13. 系统隐喻（System Metaphor）

极限编程中有四个核心价值：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：谦逊（Modesty）。 　XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈、勇气和谦逊”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

底层用单元测试   功能是探索式测试

1.  XP方法

敏捷方法是近几年兴起的一种轻量级的开发方法，它强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、Just Enough、并行并基于构件的软件过程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一种轻型开发方法。它规定了一组核心价值和方法，消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。它把软件生命周期划分为用户故事、体系结构、发布计划、交互、接受测试和小型发布6个阶段，采用这种开发模型的软件过程如图1-15所示。

 

图1-15  采用XP方法的软件过程

XP模型通过对传统软件开发的标准方法进行重新审视，提出了由一组规则组成的一些简便易行的过程。由于这些规则是通过在实践中观察使软件高效或缓慢的因素而得出的，因此它既考虑了保持开发人员的活力和创造性，又考虑了开发过程的有组织、有重点和持续性。XP模型是面向客户的开发模型，重点强调用户的满意程度。开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。

XP开发模型与传统模型相比具有很大的不同，其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）。XP开发小组不仅包括开发人员，还包括管理人员和客户。该模型强调小组内成员之间要经常进行交流，在尽量保证质量可以运行的前提下力求过程和代码的简单化；来自客户、开发人员和最终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正确的开发方向；进取则包含于上述3个原则中。

XP开发方法中有许多新思路，如采用“用户故事”代替传统模型中的需求分析，“用户故事”由用户用自己领域中的词汇并且不考虑任何技术细节准确地表达自己的需求。XP模型的优点如下。

① 采用简单计划策略，不需要长期计划和复杂模型，开发周期短。

② 在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证。

③ 能够适应用户经常变化的需求，提供用户满意的高质量软件。