Agile敏捷方法

敏捷型方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要的特征。
敏捷型方法是“适应性”(adaptive)而非“预设(predictive)的。重型方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
敏捷型方法是，“面向人的”(people-oriented)而非“面向过程的”(process-oriented)。它们试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。它们强调软件开发应当是一项愉快的活动。

下面是对上面两点的详细解释：

1）适应性和预设性传统的软件开发方法的基本思路一般是从其他工程领域借鉴而来的，比如土木工程等。在这类工程实践中，通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

但是，软件开发与上面的土木工程有着显著的不同。软件的设计是难以实现的，并且需要昂贵的有创造性的人员。土木工程师在设计时所使用的模型是基于多年的工程实践的，而且一些设计上的关键部分都是建立于坚实的数学分析之上。而在软件设计中，完全没有类似的基础。我们对开发计划所能做的只是请专家审阅。这就使得我们无法将设计和实施分离开来，一些设计错误只能在编码和测试时才能发现。根本无法做出一个交给程序员就能直接编码的软件设计。所以，软件过程不可能照搬其他工程领域原有的方法，需要有适应其特点的新的开发方法。

软件的设计之所以难以实现，问题在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目的模式都是针对可预测的环境的，在不可预测的环境下，就无法使用这些方法。但是我们必须对这样的过程进行监控，以使得整个过程能向我们期望的目标前进。于是Agile方法引入“适应性”方法，该方法使用反馈机制对不可预测过程进行控制。

2）面向人而非面向过程传统正规方法的目标之一是发展出这样一种过程，使得一个项目的参与人员成为可替代的部件。这样的一种过程将人看成是一种资源，他们具有不同的角色，如分析员、程序员、测试员及管理人员。个体是不重要的，只有角色才是重要的。这样考虑的一个重要的出发点就是：尽量减少人的因素对开发过程的影响。

但是敏捷型方法则正好相反。传统方法是让开发人员“服从”一个过程而非“接受”一个过程。但是一个常见的情况是：软件的开发过程是由管理人员决定的，而管理人员已经脱离实际开发活动相当长的时间了，如此设计出来的开发过程是难以为开发人员所接受的。敏捷型过程还要求开发人员必须有权作技术方面的所有决定。IT行业和其他行业不同，其技术变化速度非常之快。今天的新技术可能几年后就过时了。只有在第一线的开发人员才能真正掌握和理解开发过程中的技术细节。所以技术方面的决定必须由他们来做出。这样一来，就使得开发人员和管理人员在一个软件项目的领导方面有同等的地位，他们共同对整个开发过程负责。

在开发过程中，项目的需求是在不断变化的，管理人员之间、开发人员之间以及管理人员和开发人员之间，都必须不断地了解这些变化，对这些变化做出反应，并实施在随后的开发过程中。敏捷方法还特别提倡直接的面对面交流。Alistair Cockburn认为面对面交流的成本要远远低于文档交流的成本，因此，敏捷方法一般都按照高内聚、松耦合的原则将项目划分为若干小组，以增加沟通，提高敏捷性及应变能力。

敏捷方法的核心思想主要有下面三点：

（1）敏捷方法是适应型，而非可预测型。与传统方法不同，敏捷方法拥抱变化，也可以说它的初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。

（2）敏捷方法是以人为本，而非以过程为本。传统方法以过程为本，强调充分发挥人的特性，不去限制它。并且软件开发在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。

（3）迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。它根据客户需求的优先级和开发风险，制定版本发行计划，每一发行版都是在前一成功发行版的基础上进行功能需求扩充，最后满足客户的所有功能需求。

敏捷方法比较适合需求变化比较大或者开发前期对需求不是很清晰的项目，以它的灵活性来适应需求的变化，有效地控制项目进度和成本。另外，敏捷方法对设计者、开发者和客户之间的有效沟通和及时反馈要求比较高，所以不易在开发团队比较庞大的项目中实施，当然这也不是绝对的。

敏捷方法的主要内容包括4个核心价值观和12条过程实践规则。4个核心价值观分别为沟通、简单、反馈和勇气。沟通，它强调设计者、开发者和客户三者之间的有效交流是开发成功的关键；简单是设计和编码的指导原则，它强调只满足当前功能需求，不做假想设计，尽量使代码简单化；反馈，强调设计者、开发者和客户之间及时和详尽的意见反馈是开发成功的保证；勇气，是开发适应变化的前提，要求设计者和开发者在必需做出取舍或重构时，勇于抉择，勇于实践。

依据敏捷方法的4个核心价值观，提出12条过程实践规则，分别为简单设计、测试驱动、代码重构、结对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制。

XP（Extreme Programming，极限编程）

它由价值观、原则、实践和行为 4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

4 大价值观：沟通、简单性、反馈和勇气。

5 个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

12 个最佳实践：

计划游戏(快速制定计划、随着细节的不断变化而完善)、
小型发布(系统的设计要能够尽可能早地交付)、
隐喻(找到合适的比喻传达信息)、
简单设计(只处理当前的需求，使设计保持简单)、
测试先行(先写测试代码，然后再编写程序)、
重构(重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求)、
结对编程、（两人一起写代码）
集体代码所有制、
持续集成(可以按日甚至按小时为客户提供可运行的版本)、
每周工作 40 个小时、
现场客户和编码标准。

水晶法Crystal

水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。

并列争求法Scrum

并列争求法使用迭代的方法，其中，把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。

角色：PO即Product Owner 字面意思是产品或业务负责人，SM即Scrum Master，字面意思是敏捷教练、敏捷专家或者敏捷大师:DT即Development Team,字面意思是开发团队，角色可以互相支援。

Sprint(冲刺)
Product Backlog(产品待办事项列表)
Sprint Planning Meetings(冲刺规划会议)Sprint Backlog(中刺待办事项列表)
Sprint Execution (中刺执行)一般是2至4周时间
Daily Stand-up Meeting(每日站会)
Sprint Review Meeting(冲刺审查会)
Sprint Retrospective Meeting(回顾会议)

Scrum 管理五大事件Events
1、Sprint(冲刺):一个时间盒选代，一股是2周sprint，不超过30天的sprint也很常见。
2、冲刺规划会议:30天sprint时间盒是8小时，2周sprint时间盒是4小时。
3. 每日站立会仪:一股在早上开15分钟左右。
4、冲刺审查会议:一股30天sprint时间盒是4小时:
5.   冲刺回顾会议:一股30天sprint时间盒是3小时。回顾会议时间盒到期，这个sprint就结束:

自适应软件开发ASD Adaptive Software Development

• 有一个使命作为指导；
• 特征被视为客户价值的关键点；
• 过程中的等待是很重要的，因此“重做”与“做”同样关键；
• 变化不被视为改正，而是被视为对软件开发实际情况的调整；
• 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；
• 风险也包含其中。