敏捷开发（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．个体和交互胜过过程和工具
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。
2．可以工作的软件胜过面面俱到的文档
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
3．客户合作胜过合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。
4．响应变化胜过遵循计划
响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。
2.3 敏捷开发技术的12个原则
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2．即使到了开发的后期，也欢迎改变需求。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5．围绕被激励起来的个人来构建项目。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7．工作的软件是首要的进度度量标准。
8．敏捷过程提倡可持续的开发速度。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
10．简单使未完成的工作最大化。
11．最好的构架、需求和设计出自于自组织的团队。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
2.4 敏捷开发技术的适用范围
1.项目团队的人数不能太多
2.项目经常发生变更
3.高风险的项目实施
4.开发人员可以参与决策
第三章 敏捷开发技术在电子商务软件的实际应用案例
3.1 案例说明：钢铁贸易企业的网上期货订货系统开发实施
项目背景：国内某大型国有钢铁贸易企业，其业务形式大部分采用期货订货，客户群也比较广泛，订货时间相对比较稳定，一般集中在月底的10天左右。该企业原来开发了一套适合自己企业运作的贸易企业ERP系统，但是仅仅是在公司内部使用，功能也很有限，不能够很好的和客户进行信息交流，往往客户在集中订货的时候，因为订货量巨大，而且时间集中，所以造成该企业的业务人员忙的团团转，而且经常会发生排队订货的现象，同时由于是期货订货，所以该企业还得向上游供应商订货，这样一来一去，给工作带来极大的不便，也容易造成混乱和漏洞。
因此，介于用户这样的情况，需要开发一套网上期货订货系统，将订货的整个环节都打通，真正实现24小时订货。减少人工干预，通过和几个系统之间的集成，做到实时的信息流通。但是这样一个系统对于该企业来说，毕竟是第一回，国内也没有相关成熟的案例和模型，所以实施存在极大的风险性。而且其他同行业的竞争对手也在着手打造这样的一个系统，所以尽早建立网上订货系统，对于提高顾客的忠诚度和满意度都是大有裨益的，所以对工期的要求也非常严格。
根据以上情况，决定采用敏捷开发技术来实施这个项目。
3.2 项目组织机构
建立联合实施团队，由电子商务公司的项目实施人员和客户方的关键用户一起构成，统一受客户方的常务副总指挥。
工作方式：在客户现场办公，在调研的同时做需求，根据系统架构和功能划分，边做设计边做开发。
沟通方式：每天下班前半个小时，所有项目组成员必须座在一起沟通交流，对每天的工作进行总结和经验交流。每周召开一次推进和培训会议，在不断的开发过程中进行对用户的业务知识，系统知识，和操作的培训，为将来系统的运行维护打下更好的基础。
3.3 项目实施过程
第一轮循环实施周期两个月，不但搭建了整个应用的整体框架，还实现了两大品种的单向期货订货流程。
第二轮循环实施周期两个月，打通了向供应商的期货订货环节，并且实现了另外两个品种的订货。同时逐步将前期做好的系统向用户做推广使用，在不断完善的过程中，对本阶段的项目开发实施做修正。
第三轮循环实施周期三个月。由开发人员和客户方的关键用户对期货订货系统进行完善和优化。
3.4 项目实施效果
1. 客户方由于实施了该项目，给订货用户和公司业务员带来很大的便利，效率大大提高，再也没有排队订货的状况，再也没有业务员通宵达旦的处理订货需求，再也不会和供应商之间发生信息失真的现象。系统的快速实施和推进，使得客户对该系统也越来越依赖，同时该公司的销售业绩也率攀新高。
2.由于采用了敏捷开发技术，极大的降低了开发成本，大大提高了开发的效率。尽管在整个项目实施过程中存在大量的变更和修正，但是这样的开发方式可以很有效的避免带来更多负面的扯皮现象。
3.因为项目成员由高水平的开发人员参加，所以对客户的业务理解非常深入，在实际的项目开发当中，不但承担了具体开发的工作，还向客户方提出很多很好的建议改进措施，以便业务更加优化，操作更加顺畅。一方面，客户方从中收益，另外一方面，开发人员的能力也得到了极大的提高。
第四章 敏捷开发技术在电子商务软件的推广
1. 电子商务软件实施的高风险性
软件开发行业目前同时存在两种情况，它既是一个非常成功的又是具有很多问题的行业。
2. 在跨平台系统的移植上的应用
电子商务系统经常会出现跨平台的移植。重要的一点就是从功能角度讲，移植前后是否一致。一些敏捷开发中的最佳实践也是可以使用的，比如你可以把所有的需求以测试的方式提炼出来。很多项目都是使用这种方式而且非常成功。而且使用这种叠盖式方式，也能够从项目进程的角度看移植进程有多快。
3. 在电子商务软件外包公司的应用
软件外包是非常普遍的。在实践中发现敏捷式开发对外包也是非常有效的方法。实践中敏捷式开发比一般的开发方式估算的方法更快，而且用的人要少一些。
希望中国更多的软件公司可以采用敏捷开发技术，使我们的软件产业能够得到更加快速的提高和发展！（作者： 徐祎 就职于东方钢铁电子商务有限公司，职务为首席项目经理。目前就读上海交通大学MBA班 ）
四、敏捷开发常用工具
工欲擅其事，必先利其器，能利用工具是人与动物的最大区别。然而，大多数商业化工具价格不菲，已经加入WTO好几年了，再用盗版会给企业带来很大的不确定性，并且盗版用多了，往往会失去一种程序员的自豪感，丢掉一种文化。经过几个月的摸索，本着以下原则，偶选择了一些适合中小企业开发的工具，当作自己的工具箱：
（1）适用于中小型企业，中小型项目（<500万），功能适度
（2）易用性好，具备必要的文档
（3）免费或低价
基于这些工具，慢慢形成了一套敏捷开发过程。
（一）、工具简介
下面简单介绍这些工具，这些工具有些偶已经有相当的使用经验，有些正在使用，有些只是刚选定。除直接用于.net开发的工具中外，还包括一些开发相关的软件设计、项目管理工具。偶的主要开发经验是Web开发，桌面开发和原型开发，对Mobile开发不熟悉，也就没这方面的推荐了。
1，运行平台
常用的也就.net framework 1.1, 2.0, 和mono了，都是免费的。从功能、性能及安装基础来讲，自然.net framework要优于mono了。mono是开源的，.net framework类库可以反编译，从透明的角度讲两者都差不多。如果你想在非windows平台上开发，或者想研究运行时的实现，可以研究mono，否则还是用.net framework吧。
2，服务器
我用过的也就IIS5.0，IIS6.0，Apache加一个mod，还有mono的xsp，这也没啥好比较的，自然首选IIS6.0了。不过IIS虽然免费，但是至少得windows server版本才运行得爽，至少得花几千元。XP上的IIS很不爽，据说也能装全版IIS6.0，不过还是得折腾。开发用的话，用Apache加一个.net的mod，或者mono的xsp，还是挺好用的。Apache的缺点是对新版.net framework的支持较IIS6.0滞后。
3，IDE
tnnd，这个选择空间也很小。首选自然是VS 2003或2005，如果VS 2005速成版将来免费的话，偶就选定这个了，或者选价格并不算高的VS 2005 专业版。可恶速成版、专业版中没单元测试，在这里BS微软10000遍。坚决抵制VSTS版！
其它可选的有SharpDevelop和mono develop。对于不开发Web程序的初学者来说，用SharpDevelop其实也挺不错的，集成的Nant，NDoc，NUnit都是很有用的工具。SharpDevelop没断点调试功能，但熟用NUnit的话可以弥补这一不足。如果对类库理解得比较深入的话，采用SharpDevelop，生产力其实也挺高的――即使是进行Web开发。SharpDevelop的缺点之一是暂时没重构功能，在下一个版本里会有。缺点之二是内存占用比较大，还有性能比VS低得多，大项目，大程序可能不爽。我测试过，用SharpDevelop打开一个大于3M的C#源文件（嘿嘿！是csgl还是tao的，忘了），挂了；用VS 2003打开大概要花几十秒。
btw，我个人认为其实就用记事本写中小型（<3000行）的C#程序，效率其实也挺高的，这时候会更加注意类的设计，思路会更清晰一些，当然，速度会慢一些。
4，类库和文档
类库是.net平台的资产。目前.net下成熟的类库比较少，和java比，最大的不足就是这里了。最常用的类库当然是.net framework了，其它各方面的类库在网上都能搜索到一些。类库的关键资产要素是dll和文档。看文档要看一手资料，第一手资料就是源代码或反编译过来的代码，然后就是各类的原始文档，一般是chm格式的。如果看源代码习惯的话，效率会很高，并且，建议用反编译工具看代码，不建议直接看源文件，原因其一是反编译工具提供了很多有用的附加功能，其二是反编译的代码比源文件更真实。常用的反编译工具是Reflector。
.net下的文档是爽死了，比javadoc的pp多了。因此在写代码的时候应该注意，多写///注释，然后用Ndoc自动生成chm文档，多爽呀。
很多开源项目提供源代码和少量的文档，但它的源代码中有大量的///注释，可用NDoc自动生成chm文档。即使没有///注释，采用NDoc生成文档也是很值的。
5，数据库
MS SQL Server Express版应该是免费的，但标准版和企业版价格还是不低的，还是用开源的好。对功能有要求就用PostgreSql，没要求就用MySql。偶现在是GIS项目用PostgreSql，一般项目用MySql。数据库管理用EMS MySQL Manager Lite和EMS PostgreSql Manager Lite，免费，好用，界面很豪华，性能还行。
6，设计与建模
偶选定的UML建模工具是JUDE，2M大，免费但不开源，比ArgoUML功能多、好用。比Visio 的UML功能不知道强大多少倍，比Together也好用。缺点就是只是建模工具，和代码不同步。另一个缺点就是不能自动生成文档。不过偶喜欢这样的工具，强大，体积小，灵活，方便。并且偶觉得它在设计时用就行了，具体的类的文档用NDoc生成。JUDE是基于java的，得安装java虚拟机。好像它跨平台也不怎么样，我在linux下没运行成功过。
开源或免费的数据库建模工具试过很多，感觉都不成熟不好用，最后选择了一个商业软件――CASE Studio 2，价格100-300美元，功能很实用，支持很多数据库，生成的文档也很pp。
7，敏捷开发工具
NUnit――单元测试。
NAnt――build工具。前面已经提及。
NDoc――文档生成。前面已经提及。
CruiseControl.Net ――持续集成，暂时还没用过。
NUnit，NAnt，NDoc用的好的话，感觉非常爽，写程序会有艺术家的感觉。
8，团队协作工具
版本管理：CVS和SVN，推荐SVN。客户端推荐用TortoiseSVN――非常可爱的小乌龟。
Bug管理：偶选用的是BugTracker.NET，简单，用ASP.Net写的，小项目够用了。
需求管理、项目管理、日程、经费计算与管理：还是在用Word、Outlook、Excel。要免费的话可用永中Office试用版，一样好用。
（二）、优势
1，性价比高。对于10人规模的团队，看看软件成本：
运行平台：.net framework 1.1或2.0，免费
服务器：1套windows 2003 server版，数千元
IDE：1套VS 标准版或专业版，数千元，其它用express版就行了
类库和文档：免费
数据库：免费。用商业数据库，让客户掏钱。
设计与建模：1套CASE Studio 2就行了，数千元
敏捷开发工具：免费
团队协作工具：1套MS Office（带Visio的）就行了，数千元，其它人用永中。
整个下来，不足20000元。
2，易用性好
反正我的感觉是和商业软件差不多或者稍差
3，易扩展
上面工具大部分是开源的，并且很多工具之间协作性比较好，这样可以用来定制适合自己的生产线。老外的那一套生产线，比如RUP，MSF及其相关工具，除价格贵外，其灵活性也不高，别人的生产线不一定适合自己用。这时上面工具的优势就出来了。
（三）、搭建软件生产线
流程1：项目管理流程
用Office管理需求。用SVN进行源代码管理和文档管理，BugTracker.NET进行 Bug管理和事务管理。尽量将程序、文件、文档的维护自动化。
流程2：开发管理流程
开发过程中所维护的文件越少越好。偶觉得应该尽量少用UML图写文档，只写最关键的部分。类的文档最好由NDoc直接生成。偶用UML工具的时间很少。写代码的过程就是类设计过程。不妨比较这两个流程：（1）用例分析－>采用UML工具设计类－>由UML工具生成代码或撰写代码－>重构代码，自动更新UML文档。（2）用例分析－>撰写代码－>重构代码。第一个流程只有一个优势，就是人对图形的理解比对代码的理解更加直观，但是多了很对累赘工作。第二个流程少了很多步骤，并且可以随时根据代码逆向工程出类图出来，
我还是喜欢以代码为基础的流程。撰写代码也可分为2个过程，第一个过程是写出一个代码框架，所有的方法都是UNDO，写出属性，接口，写出///文档。这应该是设计过程。这个过程基本上只产生、维护源文件。类图可以通过visio逆向工程，类设计文档可以通过NDoc自动生成，并且提供了一个测试基础，可以根据这个测试基础写测试代码了。测试代码最好也只写个框架，但是要写好///注释，然后生成测试文档。这应该是设计过程。第二个过程是实现过程，把类文档和代码框架提交给相关人，实现、测试、重构......一切都自动进行......整个过程中只有一份东西，就是源代码，开发过程中的交付件应该都从源代码中自动生成。
数据库脚本和文档用CASE Studio 2维护。最后提交、上线、验收都很好办，所要的东西biaji一下子都出来了。要申报著作权直接从源代码和chm文档中弄一部分出来就够了。
开发的核心是源代码，所有文档应该体现在源代码的结构、关系和注释中。控制整个开发流程的核心工具是Nant。要是能把用例分析过程体现在源代码中就好了！
敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。
改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”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．个体和交互胜过过程和工具
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。
2．可以工作的软件胜过面面俱到的文档
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
3．客户合作胜过合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。
4．响应变化胜过遵循计划
响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。
2.3 敏捷开发技术的12个原则
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2．即使到了开发的后期，也欢迎改变需求。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5．围绕被激励起来的个人来构建项目。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7．工作的软件是首要的进度度量标准。
8．敏捷过程提倡可持续的开发速度。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
10．简单使未完成的工作最大化。
11．最好的构架、需求和设计出自于自组织的团队。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
2.4 敏捷开发技术的适用范围
1.项目团队的人数不能太多
2.项目经常发生变更
3.高风险的项目实施
4.开发人员可以参与决策
第三章 敏捷开发技术在电子商务软件的实际应用案例
3.1 案例说明：钢铁贸易企业的网上期货订货系统开发实施
项目背景：国内某大型国有钢铁贸易企业，其业务形式大部分采用期货订货，客户群也比较广泛，订货时间相对比较稳定，一般集中在月底的10天左右。该企业原来开发了一套适合自己企业运作的贸易企业ERP系统，但是仅仅是在公司内部使用，功能也很有限，不能够很好的和客户进行信息交流，往往客户在集中订货的时候，因为订货量巨大，而且时间集中，所以造成该企业的业务人员忙的团团转，而且经常会发生排队订货的现象，同时由于是期货订货，所以该企业还得向上游供应商订货，这样一来一去，给工作带来极大的不便，也容易造成混乱和漏洞。
因此，介于用户这样的情况，需要开发一套网上期货订货系统，将订货的整个环节都打通，真正实现24小时订货。减少人工干预，通过和几个系统之间的集成，做到实时的信息流通。但是这样一个系统对于该企业来说，毕竟是第一回，国内也没有相关成熟的案例和模型，所以实施存在极大的风险性。而且其他同行业的竞争对手也在着手打造这样的一个系统，所以尽早建立网上订货系统，对于提高顾客的忠诚度和满意度都是大有裨益的，所以对工期的要求也非常严格。
根据以上情况，决定采用敏捷开发技术来实施这个项目。
3.2 项目组织机构
建立联合实施团队，由电子商务公司的项目实施人员和客户方的关键用户一起构成，统一受客户方的常务副总指挥。
工作方式：在客户现场办公，在调研的同时做需求，根据系统架构和功能划分，边做设计边做开发。
沟通方式：每天下班前半个小时，所有项目组成员必须座在一起沟通交流，对每天的工作进行总结和经验交流。每周召开一次推进和培训会议，在不断的开发过程中进行对用户的业务知识，系统知识，和操作的培训，为将来系统的运行维护打下更好的基础。
3.3 项目实施过程
第一轮循环实施周期两个月，不但搭建了整个应用的整体框架，还实现了两大品种的单向期货订货流程。
第二轮循环实施周期两个月，打通了向供应商的期货订货环节，并且实现了另外两个品种的订货。同时逐步将前期做好的系统向用户做推广使用，在不断完善的过程中，对本阶段的项目开发实施做修正。
第三轮循环实施周期三个月。由开发人员和客户方的关键用户对期货订货系统进行完善和优化。
3.4 项目实施效果
1. 客户方由于实施了该项目，给订货用户和公司业务员带来很大的便利，效率大大提高，再也没有排队订货的状况，再也没有业务员通宵达旦的处理订货需求，再也不会和供应商之间发生信息失真的现象。系统的快速实施和推进，使得客户对该系统也越来越依赖，同时该公司的销售业绩也率攀新高。
2.由于采用了敏捷开发技术，极大的降低了开发成本，大大提高了开发的效率。尽管在整个项目实施过程中存在大量的变更和修正，但是这样的开发方式可以很有效的避免带来更多负面的扯皮现象。
3.因为项目成员由高水平的开发人员参加，所以对客户的业务理解非常深入，在实际的项目开发当中，不但承担了具体开发的工作，还向客户方提出很多很好的建议改进措施，以便业务更加优化，操作更加顺畅。一方面，客户方从中收益，另外一方面，开发人员的能力也得到了极大的提高。
第四章 敏捷开发技术在电子商务软件的推广
1. 电子商务软件实施的高风险性
软件开发行业目前同时存在两种情况，它既是一个非常成功的又是具有很多问题的行业。
2. 在跨平台系统的移植上的应用
电子商务系统经常会出现跨平台的移植。重要的一点就是从功能角度讲，移植前后是否一致。一些敏捷开发中的最佳实践也是可以使用的，比如你可以把所有的需求以测试的方式提炼出来。很多项目都是使用这种方式而且非常成功。而且使用这种叠盖式方式，也能够从项目进程的角度看移植进程有多快。
3. 在电子商务软件外包公司的应用
软件外包是非常普遍的。在实践中发现敏捷式开发对外包也是非常有效的方法。实践中敏捷式开发比一般的开发方式估算的方法更快，而且用的人要少一些。
希望中国更多的软件公司可以采用敏捷开发技术，使我们的软件产业能够得到更加快速的提高和发展！（作者： 徐祎 就职于东方钢铁电子商务有限公司，职务为首席项目经理。目前就读上海交通大学MBA班 ）
四、敏捷开发常用工具
工欲擅其事，必先利其器，能利用工具是人与动物的最大区别。然而，大多数商业化工具价格不菲，已经加入WTO好几年了，再用盗版会给企业带来很大的不确定性，并且盗版用多了，往往会失去一种程序员的自豪感，丢掉一种文化。经过几个月的摸索，本着以下原则，偶选择了一些适合中小企业开发的工具，当作自己的工具箱：
（1）适用于中小型企业，中小型项目（<500万），功能适度
（2）易用性好，具备必要的文档
（3）免费或低价
基于这些工具，慢慢形成了一套敏捷开发过程。
（一）、工具简介
下面简单介绍这些工具，这些工具有些偶已经有相当的使用经验，有些正在使用，有些只是刚选定。除直接用于.net开发的工具中外，还包括一些开发相关的软件设计、项目管理工具。偶的主要开发经验是Web开发，桌面开发和原型开发，对Mobile开发不熟悉，也就没这方面的推荐了。
1，运行平台
常用的也就.net framework 1.1, 2.0, 和mono了，都是免费的。从功能、性能及安装基础来讲，自然.net framework要优于mono了。mono是开源的，.net framework类库可以反编译，从透明的角度讲两者都差不多。如果你想在非windows平台上开发，或者想研究运行时的实现，可以研究mono，否则还是用.net framework吧。
2，服务器
我用过的也就IIS5.0，IIS6.0，Apache加一个mod，还有mono的xsp，这也没啥好比较的，自然首选IIS6.0了。不过IIS虽然免费，但是至少得windows server版本才运行得爽，至少得花几千元。XP上的IIS很不爽，据说也能装全版IIS6.0，不过还是得折腾。开发用的话，用Apache加一个.net的mod，或者mono的xsp，还是挺好用的。Apache的缺点是对新版.net framework的支持较IIS6.0滞后。
3，IDE
tnnd，这个选择空间也很小。首选自然是VS 2003或2005，如果VS 2005速成版将来免费的话，偶就选定这个了，或者选价格并不算高的VS 2005 专业版。可恶速成版、专业版中没单元测试，在这里BS微软10000遍。坚决抵制VSTS版！
其它可选的有SharpDevelop和mono develop。对于不开发Web程序的初学者来说，用SharpDevelop其实也挺不错的，集成的Nant，NDoc，NUnit都是很有用的工具。SharpDevelop没断点调试功能，但熟用NUnit的话可以弥补这一不足。如果对类库理解得比较深入的话，采用SharpDevelop，生产力其实也挺高的――即使是进行Web开发。SharpDevelop的缺点之一是暂时没重构功能，在下一个版本里会有。缺点之二是内存占用比较大，还有性能比VS低得多，大项目，大程序可能不爽。我测试过，用SharpDevelop打开一个大于3M的C#源文件（嘿嘿！是csgl还是tao的，忘了），挂了；用VS 2003打开大概要花几十秒。
btw，我个人认为其实就用记事本写中小型（<3000行）的C#程序，效率其实也挺高的，这时候会更加注意类的设计，思路会更清晰一些，当然，速度会慢一些。
4，类库和文档
类库是.net平台的资产。目前.net下成熟的类库比较少，和java比，最大的不足就是这里了。最常用的类库当然是.net framework了，其它各方面的类库在网上都能搜索到一些。类库的关键资产要素是dll和文档。看文档要看一手资料，第一手资料就是源代码或反编译过来的代码，然后就是各类的原始文档，一般是chm格式的。如果看源代码习惯的话，效率会很高，并且，建议用反编译工具看代码，不建议直接看源文件，原因其一是反编译工具提供了很多有用的附加功能，其二是反编译的代码比源文件更真实。常用的反编译工具是Reflector。
.net下的文档是爽死了，比javadoc的pp多了。因此在写代码的时候应该注意，多写///注释，然后用Ndoc自动生成chm文档，多爽呀。
很多开源项目提供源代码和少量的文档，但它的源代码中有大量的///注释，可用NDoc自动生成chm文档。即使没有///注释，采用NDoc生成文档也是很值的。
5，数据库
MS SQL Server Express版应该是免费的，但标准版和企业版价格还是不低的，还是用开源的好。对功能有要求就用PostgreSql，没要求就用MySql。偶现在是GIS项目用PostgreSql，一般项目用MySql。数据库管理用EMS MySQL Manager Lite和EMS PostgreSql Manager Lite，免费，好用，界面很豪华，性能还行。
6，设计与建模
偶选定的UML建模工具是JUDE，2M大，免费但不开源，比ArgoUML功能多、好用。比Visio 的UML功能不知道强大多少倍，比Together也好用。缺点就是只是建模工具，和代码不同步。另一个缺点就是不能自动生成文档。不过偶喜欢这样的工具，强大，体积小，灵活，方便。并且偶觉得它在设计时用就行了，具体的类的文档用NDoc生成。JUDE是基于java的，得安装java虚拟机。好像它跨平台也不怎么样，我在linux下没运行成功过。
开源或免费的数据库建模工具试过很多，感觉都不成熟不好用，最后选择了一个商业软件――CASE Studio 2，价格100-300美元，功能很实用，支持很多数据库，生成的文档也很pp。
7，敏捷开发工具
NUnit――单元测试。
NAnt――build工具。前面已经提及。
NDoc――文档生成。前面已经提及。
CruiseControl.Net ――持续集成，暂时还没用过。
NUnit，NAnt，NDoc用的好的话，感觉非常爽，写程序会有艺术家的感觉。
8，团队协作工具
版本管理：CVS和SVN，推荐SVN。客户端推荐用TortoiseSVN――非常可爱的小乌龟。
Bug管理：偶选用的是BugTracker.NET，简单，用ASP.Net写的，小项目够用了。
需求管理、项目管理、日程、经费计算与管理：还是在用Word、Outlook、Excel。要免费的话可用永中Office试用版，一样好用。
（二）、优势
1，性价比高。对于10人规模的团队，看看软件成本：
运行平台：.net framework 1.1或2.0，免费
服务器：1套windows 2003 server版，数千元
IDE：1套VS 标准版或专业版，数千元，其它用express版就行了
类库和文档：免费
数据库：免费。用商业数据库，让客户掏钱。
设计与建模：1套CASE Studio 2就行了，数千元
敏捷开发工具：免费
团队协作工具：1套MS Office（带Visio的）就行了，数千元，其它人用永中。
整个下来，不足20000元。
2，易用性好
反正我的感觉是和商业软件差不多或者稍差
3，易扩展
上面工具大部分是开源的，并且很多工具之间协作性比较好，这样可以用来定制适合自己的生产线。老外的那一套生产线，比如RUP，MSF及其相关工具，除价格贵外，其灵活性也不高，别人的生产线不一定适合自己用。这时上面工具的优势就出来了。
（三）、搭建软件生产线
流程1：项目管理流程
用Office管理需求。用SVN进行源代码管理和文档管理，BugTracker.NET进行 Bug管理和事务管理。尽量将程序、文件、文档的维护自动化。
流程2：开发管理流程
开发过程中所维护的文件越少越好。偶觉得应该尽量少用UML图写文档，只写最关键的部分。类的文档最好由NDoc直接生成。偶用UML工具的时间很少。写代码的过程就是类设计过程。不妨比较这两个流程：（1）用例分析－>采用UML工具设计类－>由UML工具生成代码或撰写代码－>重构代码，自动更新UML文档。（2）用例分析－>撰写代码－>重构代码。第一个流程只有一个优势，就是人对图形的理解比对代码的理解更加直观，但是多了很对累赘工作。第二个流程少了很多步骤，并且可以随时根据代码逆向工程出类图出来，
我还是喜欢以代码为基础的流程。撰写代码也可分为2个过程，第一个过程是写出一个代码框架，所有的方法都是UNDO，写出属性，接口，写出///文档。这应该是设计过程。这个过程基本上只产生、维护源文件。类图可以通过visio逆向工程，类设计文档可以通过NDoc自动生成，并且提供了一个测试基础，可以根据这个测试基础写测试代码了。测试代码最好也只写个框架，但是要写好///注释，然后生成测试文档。这应该是设计过程。第二个过程是实现过程，把类文档和代码框架提交给相关人，实现、测试、重构......一切都自动进行......整个过程中只有一份东西，就是源代码，开发过程中的交付件应该都从源代码中自动生成。
数据库脚本和文档用CASE Studio 2维护。最后提交、上线、验收都很好办，所要的东西biaji一下子都出来了。要申报著作权直接从源代码和chm文档中弄一部分出来就够了。
开发的核心是源代码，所有文档应该体现在源代码的结构、关系和注释中。控制整个开发流程的核心工具是Nant。要是能把用例分析过程体现在源代码中就好了！
扫一扫
555
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
