敏捷软件开发

快速软件开发（敏捷开发、敏捷方法）的共同特性：1、描述、设计和实现过程是交织在一起的。2、系统通过一系列增量进行开发。3、使用广泛的工具来支持开发过程，如配置和集成工具。

敏捷方法：是一种增量开发方法，快速完成、快速交付；客户参与，以便获得关于需求变化的快速反馈；将设计和实现作为中心活动，其它活动融入其中。尽量减少文档化；

敏捷方法的目的是减少开发过程中的繁琐多余的部分，快速产出有用的软件。

计划驱动方法和敏捷方法的区别：

敏捷宣言：个体和互动高于流程和工具，可工作的软件高于详尽的文档，客户合作高于合局谈判，响应变化高于遵循计划。

敏捷方法的原则：基本原则客户参与（客户在开发工程中始终参与其中。他们的作用是提供新的系统需求及优先级，并对系统的迭代进行评价。），拥抱变化（预料系统需求的变更，并设计系统使之适应这些变更。），增量交付（软件以增量形式开发，客户描述每个增量中将要包含的需求。），保持简洁（致力于保持软件和软件开发过程的简单性，只要有可能，都要积极地排除系统中的复杂性。），人而不是过程（开发团队的技能应当被充分认识和利用。应当让团队成员在没有规定的过程限制下发展他们自己的工作方式。）

敏捷方法的用武之地：1、软件企业开发的用于市场销售的中小规模产品。2、组织内部的定制系统开发, 其中客户承诺会参与开发过程，且外部利益相关者和法规不多。

敏捷开发技术：敏捷方法的基本思想来源于90年代的极限编程(Extreme Programming,XP)。“极限”水平：一个系统的多个版本由不同的成员在一天内完成开发、集成和测试。对大多数企业而言，XP方法难以作为一种实用的敏捷方法，但是它的凸出贡献是引入了一组敏捷开发实践。

1、极限编程实践：

2、用户故事：敏捷方法没有独立的需求工程活动，而是将需求抽取和开发集成到一起，为了使之更容易，提出了“用户故事”的思想，其中每个用户故事是一个系统用户可能经历的使用场景。用户故事可以用于规划系统迭代，把卡片当成任务分解并估算工作量和资源。用户故事的思想很强大，比传统的需求文档和用例容易的多。主要问题在于其完整性。

3、重构：传统软件工程的一个基本原则是开发者应该在设计中考虑未来的变更。极限编程认为不值得花时间在程序中增加通用型以应对变化，它认为面向变化的设计经常是冗余而无用的。重构(Refactoring):改进软件的结构和可读性，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。举例：对一个类的继承层次进行重新组织，以便去除重复的代码' 对属性和方法进行整理和重命名、调用程序库中的方法替换代码等。

4、测试先行的开发：区别于计划驱动的测试方法，没有正规的测试文档。极限编程的解决方案测试驱动的。

极限编程中测试的关键特性：一、测试先行的开发1、测试先，开发后；2、隐式地定义了接口和归约。二、基于场景的增量测试开发1、故事卡片作为分解任务；2、任务的实现者透彻理解规格说明才能编写测试。三、用户参与测试开发和确认。角色是对用户故事的验收测试。四、使用自动化测试框架。1、先编写可运行的构件；2、自动化测试框架可以提高效率，如Junit。

5、结对编程的优缺点：好处：1、支持"系统的共同所有权和共同责任"的思想;2、扮演了非正式的评审过程的角色；3、鼓励通过重构改进软件的结构。|||问题：结对编程在生产率的损失很显著

敏捷项目管理：计划驱动的方法都有项目管理计划，如交付什么、什么时候交付、谁负责开发等，都有一个稳定的视图。敏捷方法没有正式的计划，于是：

Scrum敏捷方法：被提出以提供一个组织敏捷项目的框架，在一定程度上提供项目进展状况的外不可见性。几个重要的术语：产品待办事项：可以是特征定义、软件需求、用户故事，或者补充任务。每日站立会议：例行会议。Scrum主管:对应于项目经理；冲刺：一种开发迭代，通常2~4周；

Scrum的优点：产品被分解成一组、可理解、利益相关者可以对应上的条块。V不稳定的需求不会影响进度。V整个团队都对所有的一切保持可见。V客户按时看到增量的交付，并获得及时反馈。V客户和团队建立了信任，每个人都期望项目成功。

敏捷方法的实践问题：一、大公司、复杂系统时：1、非正式的特性与大公司的合同定义不相符。2、敏捷开发是应用开发而不是软件维护，大公司大部分的软件成本来自软件维护3、敏捷方法适用于小的、同处一地的团队，现实中大系统开发团队都是遍布世界各地。二、维护阶段：1、缺少产品文档；2、保持客户参与；3、开发团队的延续性。

因为敏捷方法的原则有时很难在现实中实现，所以需要敏捷开发和计划驱动开发的平衡：计划驱动：识别软件过程中的每个阶段和相关输出。前一个阶段的输出作为下一个阶段的的基础。计划驱动迭代方法发生在各个活动之中，用正式文档沟通。计划驱动不一定是瀑布模型，它可以支持增量式开发和交付。敏捷开发：规范、设计、实现和测试是交错的, 设计和实现是核心。迭代发生在所有活动之间，需求与设计同步进行。开发过程要产生的结果通过和用户的沟通决定。敏捷也可以产生文档。

面向大型系统的敏捷方法：

大型系统的特点：系统之系统、棕地软件开发、多样化的利益相关者、漫长的采购过程、系统配置、监管约束、系统之系统

面向大型系统的敏捷方法的特点：1在最初的软件需求上进行一些早期的工作。2持续地进行交流和协商。3、开发人员需要进行更多的前期设计和系统文档化。4、必须设计和实施整个团队的沟通机制。5、保持频繁的系统构建和常规的系统发布。

Scrum团队模型关键特性：1、角色重复2、产品架构师3、发布同步4、Scrum团队的每日站立会议。

面向整个组织的敏捷方法：

想在大公司引入敏捷方法有困难的原因:1、没有敏捷方法的项目经理担心新方法会带来风险。2、大型组织有要遵循的质量规程和标准。3、大型组织中人员技术和能力参差不齐，技能较差的人不能成为有效的团队成员。4、文化上的抵制。例子：一、变更管理：a）传统：所有的变更都必须在实施之前得到批准b）敏捷：任何开发者都可以在不需要外部批准的情况下改进任何代码。二、测试过程：a）传统：系统的构建版本会交给外部测试团队b）敏捷：测试先行。