敏捷软件方法的学习辅助管理系统设计 第3页
第2章 敏捷软件开发方法与相关技术综述
2.1敏捷方法的特点
任何软件开发方法都有一个相应的价值系统（Value system），而价值系统的基础是对世界的信仰和对软件开发特点的认识，可以说是核心理念。
 敏捷开发方法的代表人之一Martin Fowler提出的Agile方法的核心理念：适应和以人为本。
1.敏捷方法基于适应而非预测
人们不可能在软件开发之前就能准备了解当时的需求，这点由Peter Wegner用数学的方法给出了严格的证明[27,28] 。所以传统软件开发方法在这方面不能满足需求及时变化的要求。而敏捷软件开发方法正是基于适应性的特点，通过快速、短迭代式的开发，不断产出和演化可运行软件，通过加强有关人员的信息交流等手段来提高反馈的速度、力度和准确型。
2.敏捷方法是以人为导向而非过程导向
软件开发中最重要的因素就是人，但是每个人的工作承受力都是有限的，任何超出人的正常工作承受力都会导致工作的失败，这一点在传统软件开发过程中较被忽视。敏捷方法认为，软件开发过程中应该要充分发挥软件人员的能动性和创造力。软件开发应该首先着眼于有用的可执行的软件，即先考虑商业目标，而不是为过程而过程。
敏捷方法还特别强调软件开发中相关人员间的交流，认为开发人员面对面的交流的成本要远远低于文档交流的成本。
2.2敏捷方法中的价值系统和指导原则
敏捷联盟提出了“四个价值”、“十二个指导原则”[1]
1.敏捷方法的四个价值：
    （1）较之于过程和工具，更注重人及其相互作用的价值。
（2）较之于无所不及的各类文档，更注重可运行的软件的价值。
（3）较之于合同谈判，更注重与客户合作的价值。
（4）较之于按计划行事，更注重响应需求变化的价值。
2.敏捷方法的指导原论文网http://www.lwfree.com/  六维毕业论文http://www.751com.cn/ 求的变化（不管该变化出现在开发早期还是后期）。敏捷过程紧密围绕变化展开并利用变化来实现客户的竞争优势。
（3）以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用。
（4）在项目过程中，业务人员和开发人员最好能一起工作。
（5） 以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作给予充分的信任。
（6）在项目组中，最有用、最有效的信息沟通手段是面对面的交谈。
（7）项目进度度量的首要依据是可运行的软件。
（8）敏捷过程高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。
（9）应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力。
（10）简单化（尽可能减少不必要工作的艺术）是基本原则。
（11）最好的框架结构、需求和设计产生于自组织的项目组。
（12）项目组要定期对其运作方面进行反思，提出改进意见，并相应进行细调。
 此外，敏捷方法实施中一般采用面向对象技术（接口定义良好的其他开发技术也可）。另外还强调在开发中要有足够的工具（如配置管理工具、建模工具等）支持。
2.3敏捷开发具体方法介绍
敏捷方法是一组开发方法的统称，下面介绍几个典型的敏捷开发方法。通过以下几种方法的比较，本人决定采取其中的极限编程即（XP）方法。
2.3.1 XP（Extreme Programming）[3-9]
由Kent Beck 提出，是Agile 方法中最引人注目的一个，名称中Extreme 的含义是将好的开发实践（Practices）运用到极致。XP最初实践于1997年Crysler 公司的C3 项目（人员薪金管理），采用Smalltalk 语言开发，适用于10 人以下项目组、开发地点集中的场合，现已成为小组开发方法的一个典型，被业界广泛用于需求模糊和挥发性强的场合。XP 基于四个价值(values)提出了十二个核心实践（Practices）：
1.XP方法的四个价值
    (l)交流（Communication）:项目相关人员之间充分、多渠道（最好面对面）的沟通。
(2)简化（Simplicity）:在系统可运转的前提下，做最简洁的工作；在开发中不断优化设计，时刻保持代码简洁、无冗余。
(3)反馈（Feedback）:强调各种形式的反馈，如小交付、短迭代和先考虑测试再编码等。
(4)胆识（Courage）:面对压力做正确的判断并敢于付诸行动，比如敢于丢弃设计不良的代码，疲惫时立即休息等。
2.XP方法的十二个核心实践
（l）工作团队（Whole Team）：所有的小组成员应在同一个工作地点工作。成员中必须有一个用户代表（On-site User）,由他/她来提出需求，确定开发优先级，把握开发的动向。通常还设一个“教练”（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。小组每个成员都应围绕用户代表，充分贡献自己的技能。
（2）计划（Planning Game）：包括交付计划和迭代（Iteration）计划两类，前者是在项目开始时对软件交付日期的粗略估计，后者是在每个迭代开始时对本次迭代的工作安排。二者都可在执行时调整，只不过迭代计划要更为具体和准确。
（3）系统比拟（Metaphor）：系统比拟是待开发软件系统的一个形象化比喻，这个比喻必须是每个组员都熟悉的，它相当于一个粗略的软件体系结构（Architecture），使用户和开发人员建立一个一致的框架，从而指导开发的进行。
（4）小交付（Small release）：经常交付可运行的、具有商业价值的小软件，供用户代表评估或最终使用。这里的“小”意味着软件模块能尽快（可在一个迭代内完成）、不断地交付。
（5）测试（testing）：XP要求先开发测试用例(可自动执行)然后进行编码（testing thencoding），而且测试要不断进行，保证代码测试要100%通过。分两种测试：单元测试和验收测试(Acceptance test)。单元测试由开发人员负责，验收测试由用户代表负责。
（6）简洁设计（Simple Design）：有两个含义：一是设计只考虑当前定义的功能而不考虑以后需求的变化，二是指该设计是完成目前功能所需的最简洁的设计，要简单易懂、没有冗余。
（7）结对开发（Pair Programming）：开发人员两人结一对，在一台机

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>