敏捷开发

 

      敏捷开发 （agile development ）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件 项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

      敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程 中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式 中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。

      改善，而非创新。敏捷开发可理解为在原有软件开发 方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

      也许是因为时间关系，Fowler只说出了这些优势中的一部分。允许开发过程中的需求 变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验，拥有的众多优势使得敏捷开发看来已经成为解决软件危机 的标准答案。

      问题与思考
      然而，我们不得不面对的现实却是，模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。

      大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目，合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增容”的情况 下，遇到的问题同样成倍增长。人的重要性被提到了更高的高度，而缺乏有效协调手段，减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方 法带来众多便利的同时，也相应引发了几乎同样多的问题。

 

      敏捷开发（agile development）概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了"敏捷方式"组建团队 ：Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导（实际上是业务部门和IT部门之间的"翻译者"）；另 外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训，具备相关的技能。

      每个团队都有自己的敏捷指导（Bailar聘用了20个敏捷指导），他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细 需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次，以评估过程及决定需求变更 是否必要。在Capital One，大的IT项目会被拆分成多个子项目，安排给各"敏捷团队"，这种方式在"敏捷开发"中叫"蜂巢式（swarming）"，所有过程由一名项目经理 控制。

      为了检验这个系统的效果，Bailar将项目拆分，从旧的"瀑布式"开发转变为"并列式"开发，形成了"敏捷开发"所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行"冲刺"--每个冲刺始于一个启动会议，到下个冲刺前结束。

      在Bailar将其与传统的开发方式做了对比后，他感到非常兴奋--"敏捷开发"使开发时间减少了30%～40%，有时甚至接近50%，提高了交付产品的 质量。"不过，有些需求不能用敏捷开发来处理。" Bailar承认，"敏捷开发"也有局限性，比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构 中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅。

      敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为：

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过 合同谈判
• 响应变化 胜过 遵循计划

并提出了以下遵循的原则：

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
• 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
• 工作的软件是首要的进度度量 标准。
• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
• 不断地关注优秀的技能和好的设计会增强敏捷能力。
• 简单是最根本的。
• 最好的构架、需求和设计出于自组织团队。
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

一、敏捷开发方法

（一） 说明
本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法，Agile Software Development是一组软件开发方法的总称，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷开发方法又称为“轻量级”开发方法。

下面这段话摘自Martin Fowler的一篇文章：

从无到繁重再到敏捷
多数软件开发仍然是一个显得混 乱的活动，即典型的“边写边改” （code and fix）。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越 困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生 严重的影响。
我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”（methodology）。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。
这 些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的 要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或Jim HighSmith 所称的“巨型”（monumental)方法。
作为对这些方法的反叛，在过去几年中出现了一类 新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。
敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。
但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：
? 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其 实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心

（二） 方法背后的思想

Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想

人们掌握过程（process）可以分为3个阶段：
1 following 遵循一个定义好的process
2 detaching 知道不同process的适用范围，在不同的场合使用不同的process
3 fluent 不关心是否遵循特定的process，知道在什么情况下采用什么动作

软件开发是一个充满发明和交流的协作性游戏 (cooperative game of invertion and communication)。软件开发的首要目标是生产出软件，遵循特定的过程和模型只是手段，只要传递了足够的信息，手段是次要的。交流的效果要远远 重于交流的形式（Effect of communication is more important than the form of communication）。
一般软件开发有两个目标：1 尽快的生产出软件2 为下一个team 或项目做准备，有时这两个目标是矛盾的，我们要在这两个目标之间寻求平衡

在软件开发中，人的因素要远远大于过程和技术。人是有缺陷的：
1 容易犯错误，因此必须在错误扩散之前找到并改正错误
2 当觉得可能失去较多的时候，不愿意冒险
3 重新构造而不愿意重复使用已有的东西
4 难于坚持一个习惯

针对个人因素的几个建议：
1 具体的模型较抽象的模型更容易理解
2 从一个例子开始是容易的
3 通过观察他人的成果学习
4 要有足够的不受打扰的时间
5 分配的工作要与个人意向，能力匹配
6 不正确的奖励会有坏作用，从长期看个人兴趣比奖励更重要，培养在工作中的自豪感：
1) pride in work参与工作的自豪感，通常参与一个重要的工作会有自豪感
2) pride in accomplishment 完成工作的自豪感，长期未完的工作会使士气低落
3)pride in contribution 为他人贡献的自豪感
7 鼓励关心其他人的工作和整体的工作

在一个团队之间，交流是最重要的，实践证明面对面的实时的交流是最有效的，对交流的延误会损失信息，白板是最好的交流工具，交流工具的先进并不能提高交流效果。文档的作用是记录和备忘，不能通过文档交流。

敏捷开发方法要避免的过程设计的几个常见错误
1 对所有的项目使用同一种过程
2 没有弹性
3 过于沉重
4 增加不必要的“必须完成”（“should do” is really should？）
5 没有经过实践检验

敏捷开发方法过程设计的几个原理：
1 交互的面对面的交流是代价最小，最迅速的交换信息的方法
2 超过实际需要的过程是浪费的
3 大的团队需要重量级方法
4 处理重大问题的项目需要重量级方法强调
5 增加反馈和交流可以减少中间产品和文档的需求
6 轻量级方法更强调理解（understanding）,自律（discipline）和技能(skill)，重量级方法更强调文档（documentation），过程（process）和正式（formality）
understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分
discipline是指个人主动的完成工作，process指个人根据指令完成工作
skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作

7 确定开发中间的瓶径，提高它的效率
对于瓶径处的工作应该尽量加快，减少重复，（使用更熟练的人，使用更多的人，使用更好的工具，使瓶径处的工作的深入尽量稳定）对于非瓶径处的工作可以多一些重复，在输入还不确定的情况下也可以尽早开始。

这些原理的几个结论：
1 向一个项目增加人员要花费较大代价（constly），因为原有人员和新人员之间的交流要花费大量时间
2 团队的规模经常是跳跃的，例子：需要6个熟练的程序 员，但是只有4个，于是增加不熟练的程序员，结果团队的大量时间花费在培训不熟练的程序员上面，最后增加到了20个不熟练的程序员。
3 应该侧重于提高团队的技能而不是扩充团队
4 对不同的项目使用不同的过程
5 在适用的条件下，轻量级的方法优于重量级的方法
6 对不同的项目要裁减过程

敏捷开发方法的原则是“刚刚好”（Light and Sufficient）

（三） Crystal

Crystal是Alistair Cockburn提出的一组开发方法，分为Crystal Clear,Crystal Yellow, Crystal Orange和Crystal Red分别适用于不同的项目。项目可以按照参加的人员和重要性划分。重要性根据项目中的错误引发的后果分为：
C Loss of comfort （某些不舒适）
D Loss of discretionary money (经济损失)
E Loss of Essential Money (严重经济损失)
L Life Critical (生命危险)
一个项目称为C6说明参加人员在6人以下，重要性是C级，D20说明人员在6-20人，重要性是D级。

Crystal Clear适用于 C6,D6项目
Crystal Yellow适用于 C20,D20,E20项目
Crystal Orange 适用于 C40,D40,E40项目
Crystal Red 适用于 C80,D80,E80项目

Crystal Clear

适用于一个办公室内的一个小组

角色有： sponsor发起人，任务下达者
Senior Designer-Programmer 高级设计开发人员
Designer-Programmer 设计开发人员
User 用户
其中一个人是项目协调者(Project Coordinator)。Senior Designer-Programmer是关键人员

策略：
1 软件的开发采用有规则的周期性递增方法，每2-3个月提交（deliver）一个版本
2 使用里程碑(milestone)跟踪进度（包括delvier和开发期间的重大决定）
3 自动回归测试 （automated regression test）
4 用户直接参与
5 每个release有两个user viewings(用户审核?)
6 在上一个步骤足够稳定（stable enough to review）时立即开始下一个步骤，尽量并行开发
7 在每个周期的开始和中间进行产品和过程调整

过程产品（指整个过程产生的所有产品，包括软件和文档）
1 软件释放顺序（release sequence）
2 用户审核的计划
3 用户案例（usecase）或需求描述
4 设计框架 和必要的说明
5 界面草图
6 基本的对象 模型
7 执行代码
8 migration code
9 测试用例
10 用户手册
11 local matters有项目组决定：
上述product的摸班
编码和用户界面的标准
回归测试的标准和细节
其他文档
需要的工具：
版本控制 工具
白板（最好可打印）

Crystal Orange

角色：sponsor 发起人
business export/usage export 业务专家
technical facilitator 技术专家
business analyst/designer 业务分析和设计人员
project manager 项目管理 员
architect 系统架构人员
Design Mentor 设计指导人员
Lead Designer-Programmer 主要设计编码人员、
Other Designer-Programmer设计编码人员
UI Designer 用户界面设计人员
Writer 文档写作人员
Tester 测试人员

策略：
同Crystal Clear (周期可以为3-4个月)
过程产品：
需求文档
计划
状态报告
用户界面设计文档
基本对象模型
外部接口标准
用户手册
源代码
测试用例
migration code
local matters 同Crystal Clear

（四） The Agile Alliance

敏捷联盟是17位不同敏捷开发方法的提倡者共同成立的，目的是推进敏捷开发方法的研究和应用，他们并不要求强制使用某种开发方法，而是提出了敏捷开发的几个核心价值和基本原则：
core value:

Individuals and interactions over processes and tools
个人和交流重于过程和工具
Working software over comprehensive documentation
正在运行的软件本身重于复杂的文档
Customer collaboration over contract negotiation
与客户的沟通和交流重于使用合同约束客户
Responding to change over following a plan
对变化的快速响应重于跟随计划

principles

1 最高目标是通过快速的和经常的发布软件满足客户的需要
2 提交软件的周期为几个星期到几个月
3 产生正确的软件是衡量进度的首要标准
4 主动接受需求的改变而不是拒绝
5 商务人员和开发人员工作在一起
6 个人必须有动力，要创造环境支持他们的要求，信任他们
7 最有效的交流方法是面对面的交流
8 最好的结构，需求和设计来自于自组织的团队（self-organizing team），允许任何人提出想法和建议
9 持续改进设计和编码
10 鼓励正常工作，减少长时间加班
11 保持简单，减少不必要的部分，认识到简单的设计比复杂的设计更难（simple design is harder to produce）
12 定期调整过程，获得更高效率

（五） Extreme Programming

Extreme Programming（XP，极限编程 ） 是一种轻量级的软件开发方法，它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。XP强调用户满意，开发人员可以对需求的 变化作出快速的反应。XP强调team work。项目管理者，用户，开发人员都处于同一个项目中，他们之间的关系不是对立的，而是互相协作的，具有共同的目标：提交正确的软件。XP强调4个因 素：
交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流
简单（simplicity），XP要求设计和实现简单和干净
反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改
勇气（courage）。勇敢的面对需求和技术上的变化

XP特别适用于需求经常改变的领域，客户可能并系统的功能并没有清晰的认识，可能系统的需求经常需要变动。
XP也适用于风险比较高的项目，当开发人员面对一个新的领域或技术时，XP可以帮助减低风险
XP适用于小的项目（人员上），人员在2-12人之间，XP不适用于人员太多的项目，事实上，在需求经常变化或风险比较高的项目中，少量而有效的XP开发人员效率要远远高于大量的开发人员。

下面是XP的开发流程

XP的原则和实践：

1 Planning:

1)user stories。
User stories类似use case ， 描述用户所见的系统功能，但避免使用大量的文档，user stories由用户编写（不仅限于描述用户界面）。User stories使用用户的语言编写，不使用技术性的语言，每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估，也用于产生验收测试 （acceptance test），必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度，user stories并不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，在开发过程中开发人员和用户会不断的交流以讨论细 节问题。User story应该专注于功能，不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成，如果估计超过3周，说明user story太大了，需要细分。

2)release plan.
召开一个 release plan会议，产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story估计开发时间（在不被打断，无其他工作情况下的开发时间，包括测试），用户对user stories给出优先级，release plan会议并不制订每个iteration的计划。Release plan要用户，开发人员和管理者都同意，在完成功能范围（scope），使用资源（resource）,时间（time）和质量(quality)上达 成一致（一般质量是不能改变的）

3) small release
often and small release是XP的一个原则，每个release完成一些用户有意义的功能集合，尽快的提交给用户以获得反馈，及时调整，提交的越晚，调整越困难。
4）project velocity
团队在开发过程中要收集数据，以便于对自己的开发速度进行评估，用于以后的releazse plan

5)iteration
每个small release的周期称为iteration，每个iteration约为1-3周，在一个项目中保持每个iteration的时间相等，不要超前制定计 划，每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要 注重每个iteration的时间限制，当团队觉得不能按时完成iteration时，召开一次iteration plan会议，重新评估，减少一些user stories。

下面是iteration的图示：

 

6）iteration plan
在每个 iteration开始的时候召开会议，从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团 队速度。User stories和失败的测试被分解成programming task，task使用技术语言编写，作为iteration plan的详细描述。程序员主动领取task并估计完成时间，每个task应该在1-3天内完成，超过3天的task应该被细分。如果整个团队需要的时间 多于或少于规定的iteration时间，调整user stories。

7）move people around
不要使每个开发人员局限于一项工作，不要使某项工作依赖于一个开发人员，增加知识共享，减少信息孤岛，多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的，鼓励开发人员在不同iteration中开发不同的模块。

8) stand-up meeting
每天工作 开始之前，开5-10分钟的stand-up会议（站立会议），站立的目的是为了强迫节省时间，会议的目的是交流，提出存在的问题，但不要在会议上解决问 题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决，这个少数人参加的会议如果涉及到代码，可以在计算机 前讨论。

9) fix XP when it breaks
XP并不是一成不变的，当团队觉得需要修改的时候，可以根据自己的情况进行修改，任何修改都要经过整个团队的讨论和达成一致

2 Designing

1) Simplicity
保持简单的设计，在完成同样的功能的情况下，选择简单的设计，不要急于设计没有计划的功能，应该认识到：keeping a design simple is hard work

2）system metaphor
使用统一的术语描述系统，在用户，管理者和开发人员之间使用统一的术语。这将使交流清晰。

3）CRC card
使用CRC(Class , Responsibilities, and Collaboration) card进行系统设计，鼓励更多的人参加设计。每个CRC卡片表示系统中一个对象，写上对象的名字，责任和每个责任需要交互的其他对象。可以模拟对象之间 的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文档，要将卡片转换为相应的文档。

4) spike solution
使用spike solution减低风险，当遇到技术难题或设计问题时，使用简单的程序进行测试，找出问题，在不同的解决方法之间进行评估。在早期进行实验可以有效的降低风险。

5）never add function early
不要过早的设计没有计划的功能，在一个需求经常变化的环境中，过早的设计经常是没有用的。

6）refactoringwhenever and wherever
XP鼓励对设计和代码经常进行重构 （Refactoring ），目的是去除冗余，提高质量，保持设计简单。重构必须以完全测试为检验条件

3 Coding

1) customer is alaways available
用户是项目组的成员之一，用户的参加贯穿整个开发过程，用户与开发人员之间的交流是重要的

2) coding standard
使用统一的编码标准，这是保持代码整洁和共享代码的基础

3）coding unit test first
test first是XP的一个特点，在编写代码之前先编写单元测试 代码，单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的理解需求，避免直接编码造成的理解偏差，对需求的不清晰，可以在编写测试代码时就发现。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环：
1 编写测试代码
2 运行测试程序，确认失败
3 编写实现这个测试程序要求功能的代码，不需要实现其他的功能，只需要实现刚刚满足测试程序的功能
4 运行测试程序，确认成功
实践证明，test first方式需要的编码实践少于先编码，后写测试代码

4) Pair Programming
Pair programming是XP的特色，它要求两个程序员在一台计算机上同时进行编程工作。共用鼠标和键盘，通常一个人进行战略上的思考，程序架构和函数， 类之间的关系，一个人进行输入和战术上的思考，完成函数和类。两个人可以经常交换角色。Pair programming需要一段时间学习和适应，实践证明pair programming并不消耗更多的时间(人*小时)，但是代码的质量得到很大的提高。（避免将两个新手放在一个pair中）

5）sequential integration
要保证源代码库的状态是可标识的，同一时间，只允许一个pair的程序进行整和和测试，这样可以缩小问题产生的范围。不同的pair可以在自己的机器上随时进行整和和测试.

6) integrate often
只要有可能 就进行代码整合，周期可以在几个小时，最好不要超过一天。经常的整合可以避免错误的积累，可以增加可重用的代码。在一个pair认为适当的时候并通过了所 有的unit test，就可以进行整合，整合后的代码必须通过测试。同一时间，只允许一个pair进行整合。(整合失败是不是要退回原有状态，供其他pair整 合？？)

7) 共同拥有代码
鼓励每个人对项目中的任何人提 出新的想法，任何开发人员对项目中的任何代码都可以进行增加功能，改正错误和重构。没有代码或开发人员成为瓶颈。（我的想法：这确实很难理解，但是这确实 是我梦想的目标）。为了达到这个目标，任何的代码都必须有相应的测试代码，任何代码的修改必须100%通过测试。必须加强开发人员的交流和知识共享，必须 坚持统一编码标准。Pair programming可以经常交换伙伴。

8）优化工作放在最后
先使系统能够正常工作，不要猜测系统的瓶颈，要实际测量

9）NO overtime
不要长时间的加班，大多数加班并不能挽回已有的延迟，连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。

 

4Testing

1)所有的代码都有单元测试
单元测试是XP的基 石，XP中的单元测试应该是可以自动进行的，所以可以很快的进行所有的单元测试，单元测试应该在编码之前创建。单元测试的代码和代码一起release， 没有单元测试的代码不能够release。使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间。单元测试越完善，节省的时间越多。对面向对象 的编程来说，应该对每个类都有单元测试。完善的单元测试也是共同拥有代码的保证。单元测试也是可以经常重构的保证，每次重构后的代码都要重新进行测试
（这里的unit test好象不只限于测试某个模块的功能？？？，应该可以测试整合起来的整个系统，这样才能保证整合的正确性。）

2）代码在release前必须通过所有的单元测试

3) 发现bug后，首先增加测试
在实际运行中发现bug,首先增加acceptance test，然后增加unit test，在增加完测试后在查找和修改代码，增加的测试保证同样的错误不会再出现

4) acceptance test
acceptance test根据user stories在iteration plan会议上创建，它也应该可以自动运行以便可以经常运行。User stories是否完成是以是否通过acceptance test为检验标准。

XP中的角色：

1 customer 用户
在XP中，用户是项目组的一部分，用户负责编写use stories，确定优先级，和开发人员讨论需求，编写accept test，运行accept test，用户驱动iteration(release plan, iteration plan)

2 开发人员
与用户讨论user stories，估计开发时间，将user stories细化成programming task
编写unit test
编码
进行重构
整合及测试，保证100通过

3 manager
负责对外联系，组织团队，获取必要的资源，管理团队

4 tracker
跟踪release plan/iteration plan/acceptance test

5 coach
起顾问指导作用，mentor, monitor and help
A Coach is respected, but also respectful. They’re willing to talk, but also willing to listen. They let the team explore, but provide a guard-rail in case of danger.
监督进展，确保过程和规则，必要时改变过程，帮助解决问题，也可以参加pair programming。

二、敏捷开发的设计原则

关于敏捷开发的设计原则：
单一职责原则SRP：Single Responsibility Principle
开放封闭原则OCP：Open－Close Principle
Liskov替换原则LSP：Liskov Substitution Principle
依赖倒置原则DIP：Dependency Invertion Principle
接口隔离原则ISP：Interface Separate Principle
关于包的设计原则：
重用发布等价原则REP：Reuse Equivalence Principle
共同重用原则CRP：Common Resue Principle
共同封闭原则CCP：Common Close Principle
无环依赖原则ADP：Acyclic Dependency Principle
稳定依赖原则SDP：Stabilization Dependency Principle
稳定性度量公式：I＝Ce/(Ca+Ce) (I:不稳定度，Ce:输入耦合度，Ca：输出耦合度)
I取值范围在【0，1】，I＝0表示具有最大稳定度；iI＝1标识具有最大不稳定度
稳定抽象原则SAP ：Stabilization Abstract Principle

 

GOF 说－－基于对象组合的设计会有更多的对象（而有较少的类）。
如果单纯的看这里，你会明白似乎类较少符合面向对象的逻辑。
但是且慢，我们知道面向对象有一条原则叫单一职责原则－－SRP。
这样好像类多又是面向对象思想的体现。
其实最重要的是GOF中的这句话－－且系统的行为将依赖对象间的关系而不是被定义在某个类中。
所以类的多少并不是问题的关键，是否职责单一也不是大问题，
最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。
在BOB大叔那里定义职责是变化的原因，因此就可以认为这些变化的原因应该是不可代替的，
也可以说你不能由这个原因推导出别的原因。
只要这个原因间可以做到相互关联，那么你就可以把由于这些变化而引起变化的类组合起来，
而不是把他们规定在新的类中。

开放封闭原则OCP：Open－Close Principle

一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。

因此在进行面向对象设计 时要尽量考虑接口封装机制、抽象机制和多态技术。

该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。

我们以收音机的例子为例，讲述面向对象的开闭原则。

我们收听节目时需要打开收音机电源，对准电台频率和进行音量调节。

但是对于不同的收音机，实现这三个步骤的细节往往有所不同。

比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。

因此，我们不太可能针对每种不同类型 的收音机通过一个收音机类来实现（通过重载）这些不同的操作方式。

但是我们可以定义一个收音机接口，提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。

不同的收音机继承并实现这六个抽象方法。

这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为方便。

此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。
图1是一个应用OCP生成的收音机类图 的例子：

Liskov替换原则LSP：Liskov Substitution Principle

子类应当可以替换父类并出现在父类能够出现的任何地方。

我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。

这个例子有些牵强，

一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。

因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。

　　运用替换原则时，我们尽量把类B设计为抽象类或者接口，

让C类继承类B（接口B）并实现操作A和操作B，

运行时，类C实例替换B，这样我们即可进行新类的扩展（继承类B或接口B），

同时无须对类A进行修改。

依赖倒置原则DIP：Dependency Invertion Principle

在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。

具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。

在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），

这说明，抽象的模块要依赖具体实现相关的模块，

底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法 的一个"硬伤"。

　　面向对象方法 的依赖关系刚好相反，具体实现类依赖于抽象类和接口

　　为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，

并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用

接口隔离原则ISP：Interface Separate Principle

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。

　　ISP原则是另外一个支持诸如COM等组件 化的使能技术。

缺少ISP，组件、类的可用性和移植性将大打折扣。

这个原则的本质相当简单。如果你拥有一个针对多个客户的类，

为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

以下展示了一个拥有多个客户的类。

它通过一个巨大的接口来服务所有的客户。

只要针对客户A的方法发生改变，客户B和客户C就会受到影响。

因此可能需要进行重新编译和发布。这是一种不幸的做法。

所展示的技术。每个特定客户所需的方法被置于特定的接口中，这些接口被Service类所继承并实现。

如果针对客户A的方法发生改变，客户B和客户C并不会受到任何影响，也不需要进行再次编译和重新发布。

三、 敏捷开发技术在电子商务 软件中的应用
 
　　第一章 背景介绍

　　1.1 电子商务背景

　　随着企业 信息化的不断进步，电子商务在中国也越来越得到更多的认可，电子商务的应用也越来越多，但是很多企业对电子商务的概念和应用还不是很清楚，行业内对电子商 务的研究模式和实施方法也存在很多问题。因此很多企业在实施电子商务系统的过程中都处在探索和摸索当中，对于项目开发方来说也有着极大的风险性和挑战性。

　　1.2 电子商务软件开发存在的问题

　　由于电子 商务软件开发存在很大的风险性，而且电子商务的应用也出在不断摸索当中，没有很多成熟的模式可以参考，所以没有实践的指导可能会导致的项目噩梦。缺乏有效 的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。更长时间的工作却生产出更加低劣的 软件产品，也使得开发人员感到沮丧。我们希望这些方法这次还会有效，从而消除我们的恐惧。然而，项目并没有简单到使用一些约束和人为制品就能够可靠地防止 错误的地步。当连续地犯错误时，我们会对错误进行诊断，并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。一个大而笨重的过程会产生它本来企 图去解决的问题。它降低了团队的开发效率，使得进度延期，预算超支。它降低了团队的响应能力，使得团队经常创建错误的产品。

　　1.3 敏捷开发技术概述

　　敏捷式开发采用适应性方法，而传统的软件工程学采用的是预测性方法。敏捷式开发是以人为主的，而传统的工程学是以过程为主的。

　　1.4 敏捷开发的现实意义

　　适应性和 预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学里，核心的概念就是把设计和构建这两个过程分开进行。在软件开发的过程中，我们很难 想象，如何真正把设计和编程完全区分过来。软件工程学领域，所有在这里从事工作的人员，都把设计的过程想象成用图表、图象的方式来描述结果的过程。还有一 个更重要的问题就是说，软件本身的需求是在变化的。一个项目在开发过程中需求会出现变化，需求的变化从根本上推翻了工程学方法所建立的一个基础。当工程学 的人尽量减少或者控制系统将来发生变化的可能，他越这样做问题就越容易出现。既然我们没办法避免变化的发生，那么我们就想找到一种新的方法能够更有效地适 应这种变化现象。这也就是敏捷式开发方法所要达到的效果。

　　第二章 敏捷开发技术的应用

　　2.1 敏捷开发技术的几种主要类型

1.XP（Extreme Programming －－ 极限编程

2.Cockburn的水晶系列方法

3.开放式源码

4.Highsmith的适应性软件开发方法〔ASD〕

　　　2.2 敏捷开发技术的特点和优势

　　1．个体和交互胜过过程和工具

　　人是获得 成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如 果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望 团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。