一极限编程XP：
概述：
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
核心价值：
极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：谦逊（Modesty）。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。
XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈、勇气和谦逊”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。
二Scrum：
概述：
Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。
虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.
特性：
Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog）， 产品订单是按照优先级排列的要完成的工作的概要的需求。哪些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。
管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。
敏捷方法之极限编程(XP)和 Scrum区别[1]
区别之一： 迭代长度的不同
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
区别之二: 在迭代中, 是否允许修改需求
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。
三精益软件开发：
精益原则：
尊重一线人员
工作在一线的人最了解实际情况，他们知道现在发生了什么，知道当前情况下的最佳应对方法；
他们熟知每天使用的工具、流程、规则，因而完全具备足够的知识提出改进意见；
要充分尊重一线人员的意见；
消除浪费
消除浪费（或者叫muda,是丰田管理词典中的一种特殊的浪费）原则，最初是由Taiichi Ohno（丰田生产方式之父）的理念所采用的。他将如下行为视为浪费：
储存的等着被使用的汽车零配件生产任何不是马上就需要的产品不必要的配件移动等待其他配件被生产制造过程中多余的处理步骤缺陷（质量差） 换句话说，按照精益思维，任何不能为客户增加价值的行为即是浪费。包括：
不必要的功能和代码软件开发过程的延迟不明确的需求繁文缛节低效的内部沟通 为了消除浪费，首先必须能够识别、认识到浪费。如果某项活动可以被跳过或者没有这些活动也能达成最终的结果，那它就是浪费。在开发过程中作成但最终被废弃的代码是浪费。客户不经常使用的额外的处理和特性是浪费。等待其他活动、团队、处理是浪费。缺陷和低品质是浪费。不产生实际价值的、过度的管理也是浪费。以价值流来区分的方法被用来区分识别浪费。第二步就是指出浪费的根源并消灭它。持续不断的消除浪费直到一些甚至看起来必不可少的过程和步骤被清除。
增强学习
面对开发团队以及最终的产品大小的额外挑战，可以说软件开发是个持续学习的过程。最佳的改善软件开发环境的做法就是增强学习。在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试。用户需求的收集过程可以简单地通过给最终客户演示，并听取他们的反馈来完成。
使用短周期的迭代（每个迭代都应包括重构和集成测试）可以加速学习过程。在决定当前阶段的开发内容并对未来改善的努力方向进行调整时，在客户端帮助下通过简短的反馈会议来增强反馈。通过这些简短的反馈会议，客户代表和开发团队会更多地发现在进一步开发时会遇到的主要问题及可能的解决方案。从而，基于已开发出的原型，客户可以更好地理解自己的需求，开发者也能了解到如何才能更好地满足客户的需求。另一个关于和客户沟通、学习的想法是“基于组的开发”，这种方法聚焦于未来解决方案的约束限定而不是各种可能的解决方案，因此通过和客户的对话加速了解决方案的产生。
尽量延迟决定
因为软件开发通常具有一定的不确定性，基于多种选择的方法能够达成更好的结果，尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。系统越复杂，那么这个系统容纳变化的能力就应该越强，使其能够具备推迟重要以及关键的决定的能力。
嵌入质量
质量是在过程中产生的；
如果在开发流程的每一个阶段，都能保证产出物的质量，最终产品的质量就能以最低的代价实现；
过程中保证质量能大量减少浪费，质量是过程的一部分；
快速交付
快速交付的好处数不胜数，譬如能够使客户更早地得到产品价值，能使产品更快地投入市场；整体优化
局部的优化，若不能带来整体的改善，将是没有价值的；
构造一个完整的产品
四动态系统开发：
动态系统开发方法（Dynamic System Development Method，DSDM）是一种敏捷软件开发方法，该方法提供一种框架，使其“通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护”。
DSDM使用迭代软件过程，每一个迭代都遵循80%原则，即每个增量只完成能够保证顺利进入下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。
DSDM的基本原则 DSDM方法建立在9条原则之上，而且在实施过程中，这9条缺一不可。
原则1：用户必须持续参与
原则2：必须授予DSDM团队制定决策的权利
原则3：注重产品的经常交付
原则4：满足业务用户用途是接受交付品的主要依据
开发人员不必沉溺于完美的解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。
原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的
采用迭代开发的方法，能够使业务流程逐步进化，使系统不断朝着满足业务需求的方向前进。
原则6：开发过程的所有变化可逆
采用迭代和增量式开发过程中，很可能会碰到走错的情况，此时需要回退到一个已知的可靠的点上。
原则7：在高层次上制定需求的基线
在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程中再得到详细的需求。
原则8：测试自始至终贯穿于开发周期之中
开发人员完成一个模块的开发后，自己会进行单元测试。当模块集成到现有系统后，测试人员需要执行集成测试。另外，回归测试在DSDM中占有很重 要的地位。
原则9：所有项目涉众间的通力合作是不可获缺的
五特性驱动开发：
特征驱动开发（FDD-Feature Driven Development）方法是敏捷软件开发过程中的一种，它强调特性驱动，快速迭代，即能保证快速开发，又能保证适当文档和质量，非常适合中小型团队开发管理。它提出的每个功能开发时间不超过两周，为每个用例user case限定了粒度，具有良好可执行性，也可以对项目的开发进程进行精确及时地监控。它抓住了软件开发的核心问题领域，即正确和及时地构造软件。FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来，直接参与到开发人员和用户所从事的系统构造工作中。
FDD过程：
FDD是一个模型驱动( model-driven)、短期迭代(short-iteration)的过程。 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后是周期低于两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容。一个FDD开发过程如附件1图所示。
其由5个活动组成：
1. 开发一个全局的模型 （Develop an Overall Model）
2. 建立特征列表
在此采用下述格式进行描述：
- 针对功能： <action>the<result><by | for | of | to>a(n)<object>
- 针对功能集：<action><-ing>a(n)<object>
- 针对主功能集：<object>management
3. 依据特征规划(Plan by Feature)
4. 依据特征设计(Design By Feature)
5. 依据特征构建(Build By Feature)
六水晶开发：
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
水晶项目开发核心特征:
--经常交付;
--项目主办者根据团队的工作进展获得重要反馈;
--用户有机会发现他们原来的需求是否是他们真正想要的, 有机会将观察结果反馈到开发当中
--团队得以调整开发和配置的过程, 并且可以鼓舞士气
--规定Timing Box确定最终的迭代交付时间点