课堂上老师让我写一下关于敏捷开发的概述。以下是从网上找的资料进行整理的。
敏捷开发的路线：
Test-Driven Development，测试驱动开发。
它是敏捷开发的最重要的部分。在ThoughtWorks，我们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。
Continuous Integration，持续集成。
在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl。
Refactoring，重构。
相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。
Pair-Programming，结对编程。
在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。
Stand up，站立会议。
每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。
Frequent Releases，小版本发布。
在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。
Minimal Documentation，较少的文档。
其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。
Collaborative Focus，以合作为中心，表现为代码共享。
在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。
Customer Engagement ，现场客户。
敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。
Automated Testing ，自动化测试。
为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作，包括Selenium开源项目。
Adaptive Planning，可调整计划。
敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。
敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。
项目的敏捷开发方法
敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，这些方法本质实际上是一样的，敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 关注业务优先级； 检查与调整。
精益开发是从丰田的生产以及开发方式发展出来的一种过程管理方法，从90年代开始被很广泛的研究，其目标是了解客户的价值观，然后充分利用聪明的、具有创造力的员工的时间和精力，以较少的努力提供更多的价值，即尽量避免复杂的东西。
精益软件开发有七个原则：
- 消灭浪费（Eliminate Waste）：软件开发中最大的浪费就是多余的功能，该原则是Lean最基本的一个原则。
- 品质为先（Build Quality In）：从一开始就注重品质，而不是最后依靠测试。测试驱动开发（TDD）就是一个很好的实践。
- 创建知识（Create Knowledge）：软件开发是个创建知识的过程，应该有一个鼓励大家系统学习的开发流程，而且不断的改进这个流程。
- 推迟决定（Defer Commitment）：软件开发通常具有一定的不确定性，基于多种选择的方法能够达成更好的结果，尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。
- 快速交付（Deliver Fast）：尽快的交付软件能使客户满意，还可以削除大量的浪费。
- 尊重员工（Respect People）：软件开发以人为本，人是软件开发团队中最重要的资源。
- 全局优化（Optimize the Whole）：一个Lean的团队应该优化整个价值流（value stream）。
从这些原则看出，精益开发和敏捷开发在很多方面都是相通的，它是软件开发的一种指导思想。我们不能期待精益开发可以解决所有的问题。“精益软件虽然可以很好地管理复杂性，但是不能完全消除复杂性。它只是引领开发人员，而我们也需要证明它是一个可行的办法。”
动态系统开发
动态系统开发方法（DSDM）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发 方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。本书主要讲述这样几方面内容：DSDM如何加快产品的 交付，为什么像DSDM这样的敏捷开发方法能够快速体现所开发系统给业务带来的好处，如何组织用户参与项目以开发出可用的系统，如何将不同知识背景的人组 成一个团队，如何应对常规的业务约束以进行项目管理。
DSDM的基本原则 DSDM方法建立在9条原则之上，而且在实施过程中，这9条缺一不可。
原则1：用户必须持续参与
DSDM过程中，用户持续参与的概念是：在整个DSDM生命周期中，有一些专业用户会一直对开发组提供支持和参与。能够随时解决开发组对业务流 程的各种问题，使工作进展顺畅，同时用户也会对原型进行验收，提出各种建议和想法。
原则2：必须授予DSDM团队制定决策的权利
DSDM鼓励管理层将权利下放，团队成员都应该得到授权。为了使项目快速进行，团队成员必须能够对他们的工作迅速做出决定，以保证项目能够如期 交付。当出现问题时团队成员应该能做出决定，如下是一些常见的决定：
需求的实际含义。
从功能、可用性考虑开发中产生的中间产品是否可接受。
工作进程中需求的优先级制定。
修改技术细节。
尽管DSDM不鼓励团队在出现问题时，逐层向上级反馈，但是也提供了这种问题的处理途径。
可以看出，同为敏捷方法，DSDM方法与SCRUM方法的项目管理思路，特别是对团队授权和对项目过程问题的处理机制还是存在很大差别 的，SCRUM方法强调团队成员反馈问题，并且对于开发组不能解决的问题，必须逐层反馈，获取高层的指导，并且支持高层领导参与项目的SCRUM Meeting，强调迅速向上级反馈，上级迅速做出决定。而DSDM方法中，团队成员已经被授权直接做出决定了。
原则3：注重产品的经常交付
经常交付产品，能够让外部人员检查团队内部所做出的决定是否可以接受。这样，项目就能够得到控制。这里说的产品是不仅仅是软件，还包括数据模 型。产品的经常交付能够反映项目当前的进度，也能够衡量项目是否沿着正确的方向在进行。
原则4：满足业务用户用途是接受交付品的主要依据
开发人员不必沉溺于完美的 解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。
原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的
采用迭代开发的方法，能够使业务流程逐步进化，使系统不断朝着满足业务需求的方向前进。
原则6：开发过程的所有变化可逆
采用迭代和增量式开发过程中，很可能会碰到走错的情况，此时需要回退到一个已知的可靠的点上。
原则7：在高层次上制定需求的基线
在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程中再得到详细的需求。
原则8：测试自始至终贯穿于开发周期之中
开发人员完成一个模块的开发后，自己会进行单元测试。当模块集成到现有系统后，测试人员需要执行集成测试。另外，回归测试在DSDM中占有很重 要的地位。
原则9：所有项目涉众间的通力合作是不可获缺的
何时使用DSDM？
对于具有以下特性的应用，DSDM特别适合：
1、交互式、功能通过用户界面体现。
2、有清晰的用户群。
3、没有复杂计算。
4、如果是大型应用，可以分解成小的功能部件。
5、有时间限制。
6、需求不清楚或不确定
1. 开发一个全局的模型
在一个有经验的组件/对象建模专家（首席架构师）指导下，业务领域需求人员与开发人员一起协调工作，业务领域人员提供一个初始的、具有一定高度的、可以覆盖整个系统和业务场景的介绍，领域人员和开发人员会依此产生初始的模型，然后再结成单独小组，进入详细继续讨论阶段，将模型轮廓描绘出来，然后丰富之前产生的初始模型。
2. 建立特征列表（Feature List）
当初始模型产生以后，有一个单独小组成员将开始构建复杂的特征(feature)功能列表.
3. 依据特征规划(Plan By Feature)
下一步工作就是将主要的特征功能集合进行排序和计划，然后分配给主要程序员组长，这时，程序员也会跟着他们在全局对象模型中所负责的类进入相应的程序员小组。例如张三开始是参与Message这个Model构建和规划，那么与Message这个对象模型相关的特征功能列表被分类出来并分配到特定程序员小组时，张三也就是跟着进入这个程序员小组。
4.依据特征设计/依据特征构建(Design By Feature / Build By Feature)
当每个程序员小组领到自己的特征功能集合后，召集4-5个程序员开会，组长挑选一小组适合2周内完成的特征功能集合，然后执行 'Design By Feature (DBF)' 和 'Build By Feature (BBF)'. 组长将相应的一些类和特征功能分配给小组Team，特征Team进行详细的顺序图设计， 然后写出类和方法逻辑。
下面是进入依据特征构建阶段，也就是代码的编译调试测试阶段，在进入BBF阶段之前，Team小组要进行设计代码复核，在进入后，类的作者进行类的整合、测试和复核，一旦程序员组长满意，完整的特征功能实现将被提交到主要的Build过程，也就是进入集成测试阶段。
每个程序员组长可以并行负责带领2-3特征小组Team运转，特征小组中任何人任何时候都可以成为类的作者（编写类的具体实现代码）。
宣言原则
最重要的是通过尽早和不断交付有价值的软件满足客户需要。
我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
可以工作的软件是进度的主要度量标准。
敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
对卓越技术与良好设计的不断追求将有助于提高敏捷性。
简单——尽可能减少工作量的艺术至关重要。
最好的架构、需求和设计都源自自我组织的团队。
每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
开发宣言
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
透明水晶方法的七大体系特征：
体系特征一：经常交付
体系特征二：反思改进
体系特征三：渗透式交流
体系特征四：个人安全
体系特征五：焦点
体系特征六：与专家用户建立方便的联系
体系特征七：配有自动测试、配置管理和经常集成功能的技术环境
1、敏捷小组作为一个整体工作
项目取得成功的关键在于，所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给测试人员，一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然，尽管强调一个整体，小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不同，但愿则基本上是一样的。第一个角色是产品所有者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；确定功能的优先等级，以便总是处理最有价值的功能；作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师，也可能是为项目提供资金的人。
2、敏捷小组按短迭代周期工作
在敏捷项目中，总体上并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会做同样的工作（分析、设计、编码、测试。等等）。迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。时间框一般很短，大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。迭代的时间长度一般是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。
3、敏捷小组每次迭代交付一些成果
比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户，但目标是可以交付，这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全部工作，因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了MTBF测试，其它都达到了发布状态。
4、敏捷小组关注业务优先级
敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级，并且把它组织到产品发布中去。要达到这个目的，需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划。在编写功能的时候，需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的。
5、敏捷小组检查与调整
任何项目开始的时候所建立的计划，仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫使我们做出不同的反应，等等。对此，敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性，也可能更改计划。比如发现某项工作比预计的更耗费时间，可能就会调整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能，或者减少某些低价值功能，就可以增加产品的价值。迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身，对于项目投资最大化是有益处的。从这个观点来看，迭代周期的长度选择就比较重要了，因为两次迭代之间是提供变更的机会，周期太长，变更机会就可能失去；周期太短，会发生频繁变更，而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑，对于一个复杂项目，迭代周期选择4周还是有道理的。
MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。其它的因素是：
1、至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。
2、开发团队具备运作多个产品的工作经验。
3、很早就致力于构建和提供内聚的架构。