敏捷开发方式有哪些
敏捷开发包括一系列的方法，主流的有如下七种：
XP
XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
SCRUM
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
Crystal Methods
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
FDD
FDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
ASD
ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDM
DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUP
RUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。
敏捷方法的敏捷开发
敏捷开发（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 遵循一个定义好的process2 detaching 知道不同process的适用范围，在不同的场合使用不同的process3 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）
什么是敏捷开发模式
问题一：什么是敏捷开发 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行
的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
问题二：常用的敏捷开发模式有哪些 是的，设计模式可以极大的减轻代码的工作量，增加代码的可维护性、可复用性、灵活性、可扩展性
问题三：敏捷开发和瀑布式开发模式有何区别 瀑布开发模式
定义
由W.W.Royce在1970年最初提出的软件开发模型， 瀑布式开发是一种老旧的计算机软件开发方法。
阶段
需求分析：对于需求进行详细的分析和评估，形成需求分析文档；
设计：技术评估，规划时间节点，形成技术文档以及时间规划；
开发：按照时间规划，进行开发，每个阶段完成一定的内容；
测试：开发完成后，进行测试，有问题就修改，直到可以用为止；
特点
最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
敏捷开发
定义
一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
特点
强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
工作方式
作为一个整体工作；
按短迭代周期工作；
每次迭代交付一些成果； 关注业务优先级；
检查与调整；
瀑布开发模式优点：
1、步骤清晰明确；
2、文档完整，开发过程中可以作为参考；
缺点：
1、瀑布开发是从工业发展过来的，不适合计算机软件的开发；
2、开发周期长，花大量时间去编写文档，耗费时间、人力；
3、客户只有在整个项目完成时才可以看到成果，会导致信任问题；
4、风险大，在开发过程中并不能明白最后的结果，同时不能适应变化；
敏捷开发模式优点：
1、迭代快，开发周期短；
2、不再耗费大量的时间来写文档，而是人与人面对面交流，只写一些必要的文档；
3、分工详细，每天都输出成果，客户能够看得到，会信任项目团队；
4、沟通多，容易发现问题，同时能够激起团队的协作、奋斗；
缺点：
1、人与人之间的信任是非常重要的环节，但是这个比较难完成，技术团队的成员可能技术能力差别大，同时也有互相竞争，又或者是项目团队的成员有所保留，不愿意这样的沟通；
2、团队在开发期间的任务多、压力大，需要时刻保持“兴奋”，一般很难做到。
问题四：敏捷开发模式用的测试是什么模型 【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。
既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。
那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离
建立单元测试覆盖率等度量指标
共享质量目标意味着质量责任由所有工程师共同承担
开发测试应......
问题五：瀑布开发和敏捷开发的区别是什么 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
系统开发方式众多，项目管理者只需决定何时采取何种开发模式即可。瀑布开发模式就是一种最常用的开发模型，因为这种开发方式不但简单直观而且大大便利了项目管理的运做。
瀑布开发模式可以令项目管理人员非常方便地把整个项目置于自己的掌握之下。瀑布开发模式限制了开发期间团队间的交互，评估起来相当方便，由于开发计划稳定而且几乎不会发生经常性的变化从而有效地简化了项目开发的管理工作。
瀑布开发也有一些缺点，但是，在你初履新职，刚刚接手管理一个新的团队，同时获得了一种支持瀑布开发模式的解决方案的情况下，这种开发模式可以令你很快进入角色把工作开展起来，从而为将来采用更高级的开发方式做好了准备。
瀑布开发过程在 *** 项目中特别受到欢迎，在这样的软件开发项目中，其规划阶段超出了大多数企业部署阶段的时间和力度。采用这种方式的其他用户包括那些理解比较全面和深入的软件项目，相关的解决方案对团队而言非常熟悉，或者只需要小小的改动。
问题六：敏捷开发中的sprint是什么意思 敏捷开发模式中的四种会议,Sprint Planning敏捷迭代计划会议,Daily Stand-up Meeting每日站会,Sprint Retrospective敏捷迭代回顾会议,Sprint Review敏捷迭代评审会议
问题七：敏捷开发模式的适用性 在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要。最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的阶段。另外的问题是项目初期的大量设想或快速的需求收集可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常会把不恰当的方案授予客户，而直到最后出问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。
问题八：什么是敏捷软件开发 首先什么是敏捷开发呢？敏捷开发指的是一种面临迅速变化的需求快速开发软件的能力！什么是敏捷设计 “在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的唯一软件文档，就是原代码清单。”――Jack Reeves敏捷开发人员如何知道要做什么简而言之，敏捷开发人员知道要做什么，是因为：他们遵循敏捷实践去发现问题。 他们应用设计原则去诊断问题。 他们应用适当的设计模式去解决问题。软件开发的这三个方面间的相互作用就是设计。
结论敏捷设计就是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净及富有表现力。请记住，敏捷开发人员不会对一个庞大的预先设计应用那些原则和模式。相反，这些原则和模式被应用在一次次的迭代中，力图使代码以及代码所表达的设计保持干净。
这是网上别让你的回答，直接拿来用了，望采纳。
问题九：敏捷开发模式的对比其它方法 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化. 两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行。
问题十：敏捷开发的敏捷开发的原则 1. 快速迭代相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。2. 让测试人员和开发者参与需求讨论需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。3. 编写可测试的需求文档开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。4. 多沟通，尽量减少文档任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强得多。5. 做好产品原型建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。6. 及早考虑测试及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。
关于敏捷开发的含义、原则、目标和机制
理解敏捷开发，我们可以先了解一下瀑布式开发。
瀑布开发模式把开发分成一系列阶段，如需求、设计、开发、测试，就像下图它画出来的，看起来很像瀑布，所以叫瀑布开发。
问题是需求的交付难道不都是要经历这些阶段吗？
瀑布开发的本质问题并不是阶段，而是批量。需求批量地在一起进行设计，然后是批量地开发，批量地测试、交付等等。
批量有什么问题? 首先，批量让价值交付延迟，所有需求在最后的阶段才能交付，价值交付比较晚。Google执行董事长施密特提出过反摩尔定律，表述为：
“如果18个月之后我们只能卖出跟今天一样的东西，我们就只能得到一半的收入。”价值的交付时间将直接影响收入。
敏捷的目标
敏捷开发有第一个目标就是更快的交付价值，这里的快指的不是绝对速度，而是更早的交付。
在项目结束的时候，一定是对产品和项目的知识理解最充分的时候。这显而易见，我们在项目进程中积累了知识特别是当向用户交付产品后，用户反馈：
“我要的不是这个啊，我说的明明是……”，这时候你瞬间狂涨知识，并感叹道“你怎么不早说呢？”。
这中间可能有沟通问题，但更多可能的是，用户这时才清楚或能够描述他们要的是啥，更有甚者，我们可能一开始连用户是谁也未必能准确地定义。产品和业务开发本来就是一个探索的过程，开始时一定是最无知的时刻。
项目中的大部分决策也一定是在项目开始的时刻做出的，这将有一个重大的悖论，在最无知的时刻，做出了最重要而且是绝大部分的决策，并把它作为随后执行的依据。面对不确定的技术、市场环境，传统开发模式已无法适应要求，悖论越发突出。
敏捷开发将通过迭代应对这一问题，只做初始决策，定大致的方向。通过市场反馈不断修正对产品的认知，增量的决策和调整。
产品开发过程中，技术环境、市场环境、竞品策略、团队认知都会发生变化。面对变化的环境，我们必须承认自己的无知，在开发过程主动有效地学习，不断地汲取反馈，灵活地调整。
这也是敏捷的第二个业务目标，有效学习和灵活响应变化。
敏捷开发工具
敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。
在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。
在2001年年初，一些业界专家成立了敏捷联盟，起草了敏捷软件开发宣言。该宣言针对一些企业的现状，提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则，其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则 。
敏捷开发的价值观
1.个人和交互胜过过程和工具。
2.可以运行的软件胜过面面俱到的文档。
3.客户合作胜过合同谈判。
4.响应变化胜过遵循计划。
敏捷开发应遵循的12条原则
1.通过尽早的、不断地提交有价值的软件来使客户满意。
2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3.以从几个星期到几个月为周期，尽快、不断地提交可运行的软件。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5.以积极向上的员工为中心，建立项目组，给他们提供所需的环境和支持，并对他们的工作予以充分的信任。
6.在团队内部，最有效、效率最高的传递信息的方法，就是面对面的交流。
7.测量项目进展的首要依据是可运行软件。
8.敏捷过程提倡可持续的开发，责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
9.时刻关注技术上的精益求精和好的设计，以增强敏捷能力。
10.简单是最根本的。
11.最好的构架、需求和设计出于自组织的团队。
12.每隔一定时间，团队要反省如何才能更有效地工作，然后相应地调整自己的行为。
敏捷组织提出的敏捷开发模型的整体框架主要有三个：
Scrum、XP（eXtreme Programming）、OpenUP 这3个敏捷实践。
敏捷开发的原则
1.凝聚人的力量，紧密协（合）作。包括业务负责人、开发团队、客户、管理者之间的关系，所有这些关系在以前都是造成项目危机的原因之一，那么，在敏捷时代，我们需要这些角色 紧密合作，最大限度的发挥各个角色的力量.
2.聚焦客户价值，消除浪费（如何聚焦用户价值，即频繁的交付用户可工作的软件，快速收到用户反馈）
敏捷团队运作机制
1.一个团队有自己的代办事项，对代办事项进行拆小。
2.按客户价值进行优先级排序，产品经理负责价值排序。
3.小而稳定，跨职能团队。
4.多个团队松耦合（依赖性比较低），对齐迭代时间和战略目标。
关键的团队角色
产品负责人
Scrum主管（流程主管）
开发团队
产品负责人（Product Owner）
负责管理产品backlog（代办事项）的唯一负责人
代表客户/项目如责任人
定义产品的所有特性
负责产品的投入产出
负责最大化产品和开发团队工作的价值
Scrum Master（流程主管）
起到教练的职责，领导团队完成Scrum的实践以及体现其价值。
排除团队遇到的困难，使得团队紧密合作，使得团队个人具有多方面职能的工作能力。
确保团队能胜任其工作，并保持高效的生产率。
保护团队不受到外来无端影响
关键的团队活动
每日例会：每日5分钟左右的一个简单例会，尽可能多的开发人员参与进来对紧要问题的讨论。
评审会：需要在迭代周期的最后一天召开，1个小时左右就可以了，需要客户出席，如果客户不能出席，则需要产品经理出席
迭代回顾会：迭代回顾会是在每个迭代结束时进行，总结工作中的经验和教训，时间维持在30-60分钟内，整个团队都需要参加（Scrum Master、Product Owner、开发团队以及客户）。
迭代回顾会包括两部分，第一部分是定量分析，第二部分是定性分析。
其中定量分析又包含团队是否完成了迭代目标，收集并评审迭代度量指标（包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等）。
定性分析包含哪些工作良好（应该继续保持），哪些做的不好（应该停止）；哪些可以改进（团队选出1－2条在下一个迭代实现）。
敏捷开发框架案例：
原文：windy