1.XP 很强调团队合作。团队包括：项目经理，客户，开发者
2.XP 强调四种价值：交流，简易，回馈，勇气。
3.XP 强调通过对软件的不断测试来获得反馈
4.XP 不只是强调测试，而且要求正确的测试
5.测试能保证同一个BUG 不出现两次
6.通过加强客户的反馈来缩短开发的周期
7.代码质量非常重要
8.XP 开发过程包括许多的小卡片，要组合在一起才有意义
9.提倡软件工程设计的简单而优美[@more@]
敏捷型方法适应性（adaptive〕性质 和以人优先的理念敏捷型方法是“适应性”而非“预见性”。
敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法 则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的 工作提供支持。
预设性与适应性
将设计与建造分离开来 传统的软件开发正规方法：建造计划(设计图纸)=>交由建造者做(施工)
设计是难于预见的，并且 需要昂贵的有创造性的人员，建造则要易于预设。
在软件开发中，具体建造费用非常低，几可忽略不计。
软件开发中所有工作是设计，因此需要富有创造性的才智之士。
创造性的过程是不太容易计划的，因此，可预见性是个不可能达到的目标。
我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉，因为它们是不同类型的活动，因此需要不同的过程。
需求的不可预见性需求频繁改变，可以看成：因需求工程（requirements engineering〕 没作好而导致的结果。
问题是
1.要准确获取所有需求是困难的
2.软件的“不可触摸”性，只有当你在实实在在地使用系统时，你才能知道哪些功能是有用的，哪些没什么用
软件开发的一切都取决于系统需求，如果需求不固定，你就不能制订出一个可 预见性的计划。
预见性是不可能的吗？
一般来说，不可能。
通常， 一个正规方法的创造者不是很善于（或乐于〕给出其方法的边界条件，换句话说，当这些边界条件不满足时，则该方法就不适用。所以说，在不可预见性的环境中是不能使用预见性方法的。
你所需要的是另一类过程，它们可以让你对不可预设性进行控制，这就是“适应性” 的作用了。 不可预见过程的控制 － 迭代 如何对付一个不可预测的世界呢？
要随时知道我们在开发中的情形处境，这需要一个诚实的反馈机制来不断准确地告诉我们。
“迭代式”（iterative〕开发方法类似名称是：“递增式” （Incremental〕，“渐进式”（Evolutionary)，“阶段式”（Staged〕， “螺旋式”（Spiral〕等等
迭代式开发的要点是经常不断地生产出最终系统的工作版本，这些版本逐部地实现系统所需的功能。它们虽然功能不全，但已实现的功能必须忠实于最终 系统的要求，它们必须是经过全面整合和测试的产品。
这样做的理由是：没有什么比一个整合了的、测试过的系统更能作为一个项目 扎扎实实的成果。
一个迭代周期需要多长?
XP（极限编程〕建议一到三周，
SCRUM建议一个月，
Crystal（水晶系列〕 更长一些。适应性的客户这种开发方式可以给客户带来很多的益处。
首先，这种开发的“回应性” （responsive）很好的。一个可用的，尽管是很小的系统能够尽早投入使用。 客户可以根据实际使用情况，以及变更了的需求，来及时改变一些系统功能。
这样一种方式能够更真实地反映出项目的实际状态。
可预见性过程的问题是： 项目的质量是根据与计划的一致性来衡量的。
在敏捷型的项目中，每一个周期都对计划进行评审。如果有什么糟糕的事情 的话，它也会早点被发现，因此仍然会有时间来解决。把人放在第一位并非只是适应性过程需要强的团队，多数优秀的开发人员也愿意采用适应性过程。可兼容性程序插件传统正规方法的目标之一是发展出这样一种过程，使得一个项目的参与人员成为可替代的部件。
参与软件开发的人员是可替代的部件吗？敏捷型方法的一个重要特征就是拒绝这种观点。
把人作为资源的思想其根源可追溯到泰勒的“科学管理”方法。当管理一个 工厂时，这种泰勒主义途径是有效的。但对有着高度创造性和专业性的工作，泰勒主义并不适用（事实上现代制造业也在脱离泰勒主义模式〕。 程序员是负责任的专业人员泰勒主义的一个关键的理念是认为干活的人并非是那些知道怎样才能把这件活干的好的人。
程序员是专业人员，最有资格决定如何干好他们的技术工作。泰勒主义让计划部门来决定如 何干好一件工作的作法只有当计划者比实际操作者更能知道怎样作时才有效。 如果你拥有优秀的、自觉自励的员工，那么这点并不成立。 面向人的过程的管理实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程。而接受一个过程需要一种“自愿致力” （commitment），这样大家就能以积极的态度参与进来。
只有开发人员他们自己才能选择并遵循一个适应性过程。这一点在XP中特别明显，因为这需要很强的自律性来运行这个过程。
另一点是开发人员必须有权作技术方面的所有决定。XP非常强调这一点。管理人员仍然扮演着他们的角色，但需认识并尊重开发 人员的专业知识。
测度的困难性要测度软件是非常困难的。如生产率。如果没有一套有效的测度方法，任何外部的控制都会是困难的（doomed）。
不存在一套有效的测度方法而要在管理中引入测度将会导致管理本身出问题。
基于测度的管理是非常适合 简单的、重复性的工作，知识要求低并且易于测度输出。
与基于测度的管理相反，可以选择“委托式” （delegatory）管理（干工作的人决定该怎么干）。
敏捷开发者则认为软件开发的特性会使得基于测度的管理导致非常高度的测度 “失效”（dysfunction）。实际上使用委托式的管理方式要有效得 多，这正是敏捷论者所持观点的中心所在。 业务专家的引领作用（The Role of Business Leadership〕技术人员需要与应用领域的业务专家非常紧密的联系。这种沟通不是由管理层来处理的，而是每个开发人员需要做的事。
这是由适应性过程的特点来决定的。因为敏捷开发的前提是在整个开发过程中， 事情变化很快，你需要经常不断的联系沟通以使每个人都能及时知道这些变化。 开发人员能随时获取准确的高质量的应用系统的业务知识就显得很重要。 自适应过程适应性是指在一个开发项目中如何频繁地修改软件以适 应不断的需求变更。但是，还有另一种适应性，即是过程本身随着时间推移变 化。随着时间的推移，开发团队会发现什么方式对他们的工作最好，然后改变过程以适应之。
自适应的第一步是经常对过程进行总结检讨。一般来说，在每一次迭代结束后， 你可以问自己如下问题 〔 Norm Kerth〕：
XP（Extreme Programming －－ 极限编程〕
在所有的敏捷型方法中，XP是最为引人瞩目的。部分原因是因为XP的领军 人物们的卓越能力，特别是Kent Beck，他能够把人们吸引到这种方法来， 并一直处于领先地位。但是XP热也带来了一个问题，就是它把其他一些方法 和它们非常有价值的思想给挤了出去。
XP根源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在（19）80年代末的 密切合作。90年代初，他们在一系列项目上的实践深化扩展了他们关于软件 开发应是适应性的、应以人为中心思想。
从非正式的、探索性的实践到形成系统化的正规方法的关键一步是在1996年 春。Kent被邀对Chrysler的一个工资管理项目（C3〕的开发进度进行审核。 该项目由一个签约公司用Smalltalk开发，正处于困境之中。由于源码质量 低劣，Kent建议推倒重来。该项目然后在他的领导下从头开始并成了早期 XP的旗舰和培训基地。
C3的第一期系统在1997年初投入运行。项目继续进行了一段时间后，遇到 了麻烦，导致了在1999年开发计划被撤销。（这也证明了XP并不是成功的保证）
XP的四条基本价值原则是：交流，反馈，简洁和勇气。在此基础上建立了 十多条XP项目应遵循的实践准则。其实，许多准则是以前就存在的并经过实 践检验的，而常常被忽略了的。XP重新建立了这些准则，并把它们编织成 了一个和谐的整体，使得每一项准则都能在其他准则里得以强化。
XP有一个最具冲击力的，也是最初吸引我的特点，是它对测试的极端重视。 诚然，所有的过程都提到测试，但一般都不怎么强调。可是XP将测试作为 开发的基础，要求每个程序员写一段源码时都得写相应的测试码。这些测 试片段不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的 建造平台，为进一步开发提供了良好的基础。
在此基础上XP建立了一个渐进型的开发过程，它依赖于每次迭代时对源码 的重整（refactoring〕。所有的设计都是围绕着当前这次迭代，而不管将 来的需求。这种设计过程的结果是“纪律性”与“适应性”的高度统一， 使得XP在适应性方法中成为发展的最好的一种方法。
XP产生了一批领军人物，许多是从C3项目中出来的。关于XP有许多文献可 读。Kent Beck写的 Extreme Programming Explained， 是一篇XP的宣言，它阐述了隐藏在XP后面的理念。此书对有心于XP并致 力于将其发扬光大者提供了充足的说明和解释。过去两年里也出版了一 批“多姿多彩”的XP书籍，但多数都很相似，主要是从一些XP早期的实 践者们的角度上描述了XP的整个过程。
除了书之外，还有不少网上资源。如果你想找到更有结构性的材 料，你最好访问两位C3成员的网站：Ron Jefferies的 xProgramming.com 和Don Wells的 extremeProgramming.org。 许多XP早期的倡导和发展可在Ward Cunningham的 wiki web （合作写作〕中找到。wiki是个令人着迷的地方，尽 管它的漫游性质常令人身不由己地陷入其中。 XP讨论组〔xp discussion egroup〕也很有意思。 还有一篇很有意思的文章从（XP圈）“外面”来审视XP，这就是Mark Paulk所写的 从CMM的角度看XP。Mark Paulk是CMM的领军人物之一。
Cockburn的水晶系列方法
Alistair Cockburn 在90年代初受IBM之约进行正规方法的研究，从那时起他就活跃于这个领域。 但他的研究途径和其他方法学者有所不同。一般的方法 学者是将他们个人的经验升华成理论，而Cockburn除了归纳整理他自己的实 践经验以外，他还积极地造访其他项目，和项目组成员进行广泛的讨论， 考察这些项目是怎样运作的。难能可贵的是，他从不固守自己的观点， 他会根据新的发现而随时修正自己的理论。他的这些特点使得他成为我 最喜欢的方法学者。
他的著作 Surviving Object-Oriented Projects 汇集了很多如何顺利运行软件开发项目的建议，此书也是我推荐的运行迭代 式项目的首选书。最近，Alistair写了一本关于 敏捷型软件开发 的综述性著作，探讨了这些方法的基本原则。
Alistair还更进一步地探索了敏捷型方法，并提出了 水晶（Crystal〕 方法系列。 之所以是个系列，是因为他相信不同类型的项目需要不同的方 法。他认为决定一个方法与两个因素有关：项目参与人数和出错后果。如果用 两个坐标轴来分别表示这两个变量的话，那么在这张图上，每一种方法都 有其相应的坐标位置。例如，有两个项目，一个是有40人参加，如果失败造成 的资金损失可以接受；另一个项目只有6人，其成败生存悠关。那么这两个 项目所用的方法在坐标图上就有不同的位置。
水晶系列与XP一样，都有以人为中心的理念，但在实践上有所不同。Alistair 考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度 纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出 效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产 出效率，但会有更多的人能够接受并遵循它。
Alistair也费了不少笔墨强调每次迭代后的总结回顾，因而鼓励过程本身的 自我完善。他的理由是迭代式开发是用来尽早发现问题并解决之。这样就更 加强调了开发人员要随时观察他们所用的过程，并随着项目的进行而调整。
开放式源码
看到这个标题你可能会有些意外。毕竟，开放式源码（Open Source〕 是软件的一类风格，而非一种过程。这里我是指开放源码界所用的一种 运作方式，这种方式适用于开放源码项目，其实它的许多做法也可为封闭式源 码项目所用。开放式源码项目有一个特别之处，就是程序开发人员在地域上分 布很广。注意到这点相当重要，因为一般适应性过程都强调项目组成员在同一 地点工作。
多数开放源码项目有一个或多个源码维护者（maintainer〕。只有维护者 才能将新的或修改过的源码段并入源码库。其他众人可以修改源码，但需将他们 所做的改动送交给维护者，由维护者对这些改动进行审核并决定是否并入源码库。 通常来说，这些改动是以“补丁”（patch〕文件的形式，这样处理起来容易一些。 维护者负责协调这些改动并保持设计的一致性。
维护者的角色在不同的项目中有不同的产生和处理方式。有些项目只有一个 维护者，有些项目把整个系统分成若干个模块，每个模块有一个维护者。有 些是轮流做维护者，有些是同一个源码部分有多个维护者，有些则是这些方 式的组合。许多开放源码项目的参与者只是部分时间（或业余时间〕干，如 果项目要求是全日制的，那么这有一个问题，就是怎样才能把这些开发人员 有效地协调组织起来。
开放源码的一个突出特点就是查错排故（debug〕的高度并行性，因为许多 人都能同时参与查错排故。如果他们发现了错误，他们可将改正源码的 “补丁”文件发给维护者。这种查错排故角色对非维护者来说合适，对那 些设计能力不是很强的人来说，也是一项挺好的工作。
关于开放源码的方法过程还没有很系统的文献。目前最著名的一篇文章是 Eric Raymond写的 The Cathedral and the Bazaar（教堂与集市〕， 文章虽短，但很精彩。另外，Karl Fogel所著的 关于CVS的书中也有几章 描述了开放源码的方法。即使你不想使用CVS，这几章还是值得一看。
Highsmith的适应性软件开发方法（ASD－－Adaptive Software Development)
Jim Highsmith 多年来一直从事可预见性方法的研究，建立和教学，而最后得出的 结论是这些方法都有着根本性的缺陷，特别是在用来作现代应用系统 的开发时。
他最近的 一本书 集中论述了新方法的适应特性，重点讨论了把一些起源于 复杂适应性系统（通常称之为混沌理论－－chaos theory〕的思想在软件 开发中加以应用。此书没有象XP那样提供详尽的实践准则，但它从根本上 说明了为什么适应性开发方法是重要的，并进一步说明了其对组织结构和 管理层的影响。
ASD的核心是三个非线性的、重迭的开发阶段：猜测、合作与学习。
在一个适应性环境中，因为结果是不可预见的，Highsmith把计划看成是一个 “反论”〔paradox〕。在传统的计划中，偏离计划是错误，应予纠正。 而在一个适应性环境里，偏离计划则是在引导我们向正确的目标迈进。
在不可预见的环境里，你需要大家能以多种多样的方式合作来对付不确定性。 在管理上，其重点不在于告诉大家做什么，而是鼓励大家交流沟通，从而 使他们能自己提出创造性的解决方案。
在可预见性环境里，通常是不大鼓励学习的。设计师已经都设计好了，你跟着走就行了。
在适应性环境中，学习对所有各方，包括开发人员和客户， 都是一个挑战。他们需要学习以检验他们作的假设，需要学 习以便能用每次开发周期的结果去适应下一个周期。
-- [Highsmith]
这样的学习是连续不断的，这已成为这种方法的一个重要特点，因此我们 必须得认识到计划和设计都得随开发的推进而改变。
适应性开发周期的最强力的、不可分割的好处是其对我们自以为是的心理 模式的挑战，它迫使我们更实际地估计自己的能力。
-- [Highsmith]
有了这样的出发点，Highsmith把他的工作集中放在适应性开发的难点上， 特别是如何在一个项目中增强合作和学习。基本上说，他的这本书 是侧重于“软”方法，这样对那些从开发实践中提炼出来的方法如XP，FDD 和水晶系列来说，这本书将是一个很有益的互补。
SCRUM
SCRUM在OO界里已很有些时日了，不过我得承认我对其历史发展并不是 太知其详。象前面所论及的方法一样，该方法强调这样一个事实，即明 确定义了的可重复的（defined and repeatable〕方法过程只限于在明 确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决 明确定义了的可重复的问题。
SCRUM把一个项目分成若干个为期30天的迭代阶段，称之为一“冲” （sprint〕。开“冲”之前，你得明确这一“冲”要实现的功能，然后 交给开发组去完成。但是，在“冲”期间，需求必须是固定的。
管理人员并非在“冲”的时候就撒手不管了。每天，他需召集一个短会 （15分钟左右〕，称之为一个scrum，会上大家讨论决定第二天干什么。 特别是大家会对管理层提出那些阻碍项目进行的因素，并希望管理层能 予以解决。当然，他们也需要报告目前完成了什么，这样管理层每天都能 了然项目的进展情况。
SCRUM文献多集中论述迭代阶段计划与进度跟踪。它与其他敏捷型方法在 许多方面都很相似，特别是它可以与XP的编程准则很好地结合起来。
相当长的一段时间没有关于SCRUM的专门书籍，直到最近 Ken Schwaber和Mike Beedle写了 第一本SCRUM的专著。Ken Schwaber还 主持了一个网站 ControlChaos.com，可能是对SCRUM的最好的综述。Jeff Suthurland有个总是很活跃的网站讨论OO技术，其中有 一部分是专门讨论SCRUM的。另外，在 PLoPD 4书中也有一篇关于SCRUM的很好的综述。 Scrum也有一个 Yahoo讨论组.
功用驱动开发方法（FDD－－Feature Driven Development〕
FDD是由Jeff De Luca和OO大师Peter Coad提出来的。象其他方法一样， 它致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期 一般是两周。
FDD有以下五项任务：
。建立总体模型
。提出功用清单
。针对功用逐项制订计划
。针对功用逐项进行设计
。针对功用逐项开发实现
头三项在项目开始时完成，后两项在每一次迭代周期时都要做。每一项 任务又可进一步分解并制订出相应的检验准则。
在FDD中，编程开发人员分成两类：首席程序员和“类”程序员（class owner〕。首席程序员是最富有经验的开发人员，他们负责开发实现 系统的各项功能。对每一项功能，首席程序员要定出需要哪些类（class〕 来实现这项功能，并召集“类”程序员们组成一个针对这项功能的开发 组。首席程序员作为协调者，设计者和指导者，而“类”程序员则主要 作源码编写。
关于FDD的文档资料比较少。直到最近终于有了一本全面 论述FDD的著作。FDD 的主要提出者Jeff De Luca现已建立了一个 FDD门户网站， 收录了一些文章、笔记和讨论。FDD的最早的论述见于Peter Coad等所著的 UML in Color 。他的公司 TogetherSoft 也从事FDD的咨询和培训工作。
动态系统开发方法〔DSDM－－Dynamic System Development Methods〕
DSDM在1994年始于英国。 英国一些想用RAD和迭代方式进行系统 开发的公司组成了一个社团〔Consortium〕。刚开始有17个组建成员， 到现在成员已超过1000个，遍布英国内外。DSDM由于是由一个社团所 发展，它与其他一些敏捷型方法有些不同。它有专门的组织支持， 有手册，培训课程，认证程序等。因为它 上面的价格标签而限制了我对此方法的进一步调查。不过Jenifer Stapleton已写了 一本书来介绍这种方法。
如果你要用这种方法，你得先作可行性和业务分析。可行性分析要考虑 DSDM是否适合手上这个项目。而业务分析则是开一系列的讨论会， 以期能充分了解应用域，同时也要提出大致的系统结构与项目计划。
余下的工作由三个互相交织的周期组成：功能模型周期产生文档和原型 （实验系统），设计建造周期生成可操作使用的系统，实现周期 处理系统安装部署（deployment〕问题。
DSDM有一些基本的原则包括与用户积极的交流，频繁的交付（delivery）。 有充分职权的项目组，完全的系统测试。象其他敏捷型方法一样， DSDM的一个周期在2－6周之间。它强调高质量的系统以及对需求变更的高 度适应性。
我还没有在英国之外的地方看到有项目使用DSDM。DSDM的基本结构有许多 成熟的传统方法的东西，同时又遵循了敏捷型途径。但这里的确有一点 值得注意，即是这种方法是否有鼓励一种面向过程与繁琐的倾向。
徐景周
在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。
-- Jack Reeves
简介
2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。
极限编程
设计和编程都是人的活动。忘记这一点，将会失去一切。
-- Bjarne Stroustrup
极限编程(XP)是敏捷方法中最箸名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。
下面是极限编程的有效实践：
1、完整团队
XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2、计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
3、客户测试
作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
4、简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5、结对编程
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
6、测试驱动开发
编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
7、改进设计
随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。
8、持续集成
团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。
9、集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
10、编码标准
系统中所有的代码看起来就好像是被单独一人编写的。
11、隐喻
将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
12、可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。
敏捷开发
人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
-- Tom DeMacro和Timothy Lister
敏捷软件开发宣言：
n 个体和交互 胜过 过程和工具
n 可以工作的软件 胜过 面面俱到的文档
n 客户合作 胜过 合同谈判
n 响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
敏捷宣言遵循的原则：
n 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
n 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
n 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
n 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
n 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
n 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
n 工作的软件是首要的进度度量标准。
n 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
n 不断地关注优秀的技能和好的设计会增强敏捷能力。
n 简单是最根本的。
n 最好的构架、需求和设计出于自组织团队。
n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。
n 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
n 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
n 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
n 粘滞性： 做正确的事情比做错误的事情要困难。
n 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
n 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
n 晦涩性： 很难阅读、理解。没有很好地表现出意图。
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：
n 单一职责原则(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
n 开放-封闭原则(OCP)
软件实体应该是可以扩展的，但是不可修改。
n Liskov替换原则(LSP)
子类型必须能够替换掉它们的基类型。
n 依赖倒置原则(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
n 接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
n 重用发布等价原则(REP)
重用的粒度就是发布的粒度。
n 共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
n 共同重用原则(CRP)
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
n 无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
n 稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
n 稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。
下面举一个简单的设计问题方面的模式与原则应用的示例：
问题：
选择设计运行在简易台灯中的软件，台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着，也可以让灯打开或关闭。
解决方案一：
下面图1是一种最简单的解决方案，Switch对象可以轮询真实开关的状态，并且可以发送相应的turnOn和turnOff消息给Light。
解决方案二：
上面这个设计违反了两个设计原则：依赖倒置原则(DIP)和开放封闭原则(OCP)，DIP原则告诉我们要优先依赖于抽象类，而Switch依赖了具体类Light，对OCP的违反是在任何需要Switch的地方都要带上Light，这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案，可以采用ABSTRACT SERVER模式，在Switch和Light之间引入一个接口，这样就使得Switch能够控制任何实现了这个接口的东西，这也就满足了DIP和OCP原则。如下面图2所示：
解决方案三：
上面图2所示解决方案，违返了单一职责原则(SRP)，它把Switch和Light绑定在一起，而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决，适配器从Switchable 派生并委托给Light，问题就被优美的解决了，现在，Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示：
敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。
Martin
敏捷实践12 条原则，它们是敏捷实践区别于重型过程的特征所在。
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
MIT Sloan 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。
该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。在本书的后面部分，我们会学习一些面向对象设计的原则和模式，这些内容会帮助我们维持这种灵活性。
3．经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
我们交付可以工作的软件（working software ），并且尽早地（项目刚开始很少的几周后）、经常性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能够自动导航的武器，必须要对软件项目进行持续不断地引导。
5．围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、管理等等——都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们进行改变。例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤
对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。
团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础设施（ infrastructure）代码的数量来度量开发进度的。
只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。责任人（sponsors）、开发者和用户应该能够保持一个长期的、恒定的开发速度。
敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。跑得过快会导致团队精力耗尽、出现短期行为以致崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能的清洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。
10．简单——使未完成的工作最大化的艺术——是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11．最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些职责，每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断的变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
结论
每一个软件开发人员、每一个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。可是，我们的项目以令人沮丧的速度失败，或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的，但是膨胀的过程方法对于我们的失败至少是应该负一些责任的。敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单的技术。
http://www.cnblogs.com/huqingyu/category/6492.html
。有哪些做的好的部分
。有哪些教训
。有哪些可以改进的部分
。有哪些没搞清楚的部分
建议开发人员专门用一段时间做一次更为正式的回顾总结
你绝不能期待着只用一个过程。相反，每个项目组不仅 能选择他们自己的过程，并且还能随着项目的进行而调整所用的过程。公开 发表的过程和其他项目的经验都可以拿来作为参考和样本。但是开发人员需 根据手中项目的具体情况而对其加以调整，这也是开发人员的专业职责。
这种自适应性在ASD和Crystal（水晶系列〕中都鲜明地提及。XP的严格规则 似乎不允许这样，但这只是表面现象，因为XP是鼓励调整过程的。这一点上 XP和其他方法的主要区别之处在于，XP的倡导者建议在采用XP时，先根据书本 循规蹈矩不走样地做几个迭代之后，再考虑调整。另外，回顾总结这点在XP中 没有被强调，也不是这个过程的组成部分，尽管XP建议经常性的回顾应作为XP 的实践准则之一。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92289/viewspace-907309/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/92289/viewspace-907309/
1500
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
