软件工程之敏捷过程

第五章 敏捷开发

敏捷的概念：

敏捷软件工程是哲学理念和一系列开发指南的综合。这种哲学理念推崇:让客户满意且尽早的增量发布;小而高度自主的项目团队;非正式的方法;最小化软件工程工作产品以及整体精简开发。开发的指导方针强调超越分析和设计(尽管并不排斥这类活动)的发布，以及开发人员和客户之间主动和持续的沟通。

敏捷的步骤：

步骤:对敏捷开发的恰当称呼应当是“软件工程精简版”，它保留了基本的框架活动:客户沟通、策划、建模、构建和部署，但将其缩减到一个推动项目组朝着构建和交付发展的最小任务集（有人认为这种方法是以牺牲问题分析和方案设计为代价而实现的)。

敏捷的质量保证措施:

如果敏捷团队认为过程可行，并且开发出的可交付软件增量能使客户满意，则软件质量就是没有问题的。

1. 什么是敏捷？

敏捷已经成为当今描述现代软件过程的时髦用词。每个人都是敏捷的。敏捷团队是能够适当响应变更的灵活团队。

变更就是软件开发本身，软件构建有变更、团队成员在变更、使用新技术会带来变更，各种变更都会对开发的软件产品以及项目本身造成影响。我们必须接受“支持变更”的思想，它应当根植于软件开发中的每一件事中，因为它是软件的心脏与灵魂。敏捷团队意识到软件是团队中所有人共同开发完成的，这些人的个人技能和合作能力是项目成功的关键所在。

但是，敏捷不仅仅是有效地响应变更，它还包含着对本章开头的宣言中提及哲学观念的信奉。它鼓励能够使沟通（团队成员之间、技术和商务人员之间、软件工程师和经理之间)更便利的团队结构和协作态度。它强调可运行软件的快速交付而不那么看重中间产品(这并不总是好事情);它将客户作为开发团队的一部分开展工作，以消除持续、普遍存在于多数软件项目中的“区分我们和他们”的态度;它意识到在不确定的世界里计划是有局限性的,项目计划必须是可以灵活调整的。

敏捷可以应用于任何软件过程。但是，为了实现这一目标，非常重要的一点是:过程的设计应使项目团队适应于任务，并且使任务流水线化，在了解敏捷开发方法的流动性的前提下进行计划的制定，保留最重要的工作产品并使其保持简洁，强调这样一个增量交付策略─—根据具体的产品类型和运行环境，尽可能快地将可工作的软件交付给客户。

2. 敏捷变更

变更成本是开发时间的函数

 

3.什么是敏捷过程？

任何敏捷软件过程的特征都是以某种方式提出若干关键假设，这些假设可适用于大多数软件项目。

3.1 提前预测哪些需求是稳定的以及哪些需求会变更是非常困难的。同样,预测项目进行中客户优先级的变更也很困难。

3.2 对很多软件来说，设计和构建是交错进行的。也就是两种活动应当顺序开展以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。

3.3 分析、设计、构建和测试并不像我们所设想的那么容易预测（从制定计划的角度来看)。

4. 12条敏捷原则

4.1 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。

4.2 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。

4.3 经常交付可运行软件,交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4.4 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

4.5 围绕有积极性的个人构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

4.6 在团队内部,最富有效果和效率的信息传递方法是面对面交谈。

4.7 可运行软件是进度的首要度量标准。

4.8 敏捷过程提倡可持续的开发速度。责任人( sponsor)、开发者和用户应该能够长期保持稳定的开发速度。

4.9 不断地关注优秀的技能和好的设计会增强敏捷能力。

4.10 简单——使不必做的工作最大化的艺术——是必要的。

4.11 最好的架构、需求和设计出自于自组织团队。

4.12 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

5. 极限编程（extreme Programming XP）过程

如图：

6.工业极限编程

工业极限编程（IXP)是XP的一种有机进化。它由XP的最低限要求、以客户为中心和测试驱动精神组成。IXP与原来XP的主要差别在于其管理具有更大的包容性，它扩大了用户角色，升级了技术实践。IXP合并了六个新实践，这些新实践的设计是为了有助于确保在大型组织内的—些重要项目中，XP工作能够成功地实施。

六个新实践分别是：准备评估、项目社区、项目特许、测试驱动管理、回顾、持续学习。其中回顾是指IXP团队在一个软件增量交付之后要实施特定的技术评审。这种评审称为回顾,评审通过软件增量或者全部软件的发布过程复查“问题、事件以及经验教训。

7. 其他敏捷过程模型

四种常见的敏捷方法:Scrum、DSSD、敏捷建模（AM)以及敏捷统一过程

7.1 Scrum

Scrum原则与敏捷宣言是一致的，应用Scrum原则指导过程中的开发活动，过程由“需求、分析、设计、演化和交付”等框架性活动组成。Scrum强调使用一组“软件过程模式”，这些过程模式被证实在时间紧张的需求变更的和业务关键的项目中是有效的。每一个过程模式定义一系列开发活动。如图：

7.2 动态系统开发方法(Dynamic System Development Method，DSDM)

动态系统开发方法是一种敏捷软件开发方法，该方法提供一种框架，使其“通过在可控项目环境中使用增量原型开发模式以完全满足对时间有约束的系统的构建和维护。这种情况下，如果交付整个应用系统需用100%时间，那么80%的应用系统可以用20%的时间交付。

DSDM使用迭代软件过程，每一个迭代都遵循80%原则，即每个增量只完成能够保证顺利进入下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。

DSDM定义了以下三个不同的迭代周期

7.2.1 功能模型迭代功：客户开发一系列可证明其功能的增量原型（注意:所有DSDM原型都倾向于逐渐演化为可交付的应用系统)。这一迭代周期的意图是在用户使用原型系统时引导出反馈信息以获取补充的需求。

7.2.2 设计和构建迭代：功能模型迭代中，重新构建原型以确保每一个原型都以工程化方式实现，并能为最终用户提供可操作的业务价值。有些情况下，功能模型迭代、设计和构建迭代可同步进行。

7.2.3 实现：最终软件增量(一个可操作的原型）置于运行环境中。应当注意:(1）增量不见得100%完成;(2）增量置于运行环境以后可能需要变更。在这两种情况下，DSDM开发转向功能模型迭代活动继续进行。

7.3 敏捷建模（agile modeling）

AM是一种基于实践的方法学，用于对基于软件的系统实施有效建模和文档编制。在软件开发项目中，AM是可以有效并以轻量级方式用于软件建模的标准、原则和实践。由于敏捷模型只是大致完善，而不要求完美，因此敏捷模型比传统的模型更有效。

AM采纳了与敏捷宣言一致的全部标准。敏捷建模的指导思想认为，敏捷团队必须有做出决定的勇气，哪怕这些决定可能否决当前的设计并导致重新构建。

AM的建模原则：有目的的模型、使用多个模型、轻装上阵、内容重于表述形式、理解模型及工具、适应本地需要。

7.4 敏捷统一过程（Agile Unified Process，AUP）

敏捷统一过程(（Agile Unified Process，AUP)采用了一个“在大型上连续”以及“在小细化构建和转换——AUP提供了一系列活动(例如软件工程活动的一个线性序列)，能够使团队为软件项目构想出一个全面的过程流。每个AUP执行以下活动：

建模、实现、测试、部署、配置及项目管理、环境管理。其中实现就是编译源代码。