关于敏捷开发的含义、原则、目标和机制 理解敏捷开发，我们可以先了解一下瀑布式开发

瀑布开发模式把开发分成一系列阶段，如需求设计开发测试，就像下图它画出来的，看起来很像瀑布，所以叫瀑布开发

问题是需求的交付难道不都是要经历这些阶段吗？

瀑布开发的本质问题并不是阶段，而是批量需求批量地在一起进行设计，然后是批量地开发，批量地测试交付等等

批量有什么问题? 首先，批量让价值交付延迟，所有需求在最后的阶段才能交付，价值交付比较晚Google执行董事长施密特提出过反摩尔定律，表述为：

如果18个月之后我们只能卖出跟今天一样的东西，我们就只能得到一半的收入价值的交付时间将直接影响收入

敏捷的目标

敏捷开发有第一个目标就是更快的交付价值，这里的快指的不是绝对速度，而是更早的交付

在项目结束的时候，一定是对产品和项目的知识理解最充分的时候这显而易见，我们在项目进程中积累了知识特别是当向用户交付产品后，用户反馈：

我要的不是这个啊，我说的明明是，这时候你瞬间狂涨知识，并感叹道你怎么不早说呢？

这中间可能有沟通问题，但更多可能的是，用户这时才清楚或能够描述他们要的是啥，更有甚者，我们可能一开始连用户是谁也未必能准确地定义产品和业务开发本来就是一个探索的过程，开始时一定是最无知的时刻

项目中的大部分决策也一定是在项目开始的时刻做出的，这将有一个重大的悖论，在最无知的时刻，做出了最重要而且是绝大部分的决策，并把它作为随后执行的依据面对不确定的技术市场环境，传统开发模式已无法适应要求，悖论越发突出

敏捷开发将通过迭代应对这一问题，只做初始决策，定大致的方向通过市场反馈不断修正对产品的认知，增量的决策和调整

产品开发过程中，技术环境市场环境竞品策略团队认知都会发生变化面对变化的环境，我们必须承认自己的无知，在开发过程主动有效地学习，不断地汲取反馈，灵活地调整

这也是敏捷的第二个业务目标，有效学习和灵活响应变化

敏捷开发工具

敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为敏捷过程

在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征

在2001年年初，一些业界专家成立了敏捷联盟，起草了敏捷软件开发宣言该宣言针对一些企业的现状，提出了让软件开发团队具有快速工作快速应变能力的若干价值观和原则，其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则

敏捷开发的价值观

1.个人和交互胜过过程和工具

2.可以运行的软件胜过面面俱到的文档

3.客户合作胜过合同谈判

4.响应变化胜过遵循计划

敏捷开发应遵循的12条原则

1.通过尽早的不断地提交有价值的软件来使客户满意

2.即使到了开发的后期，也欢迎改变需求敏捷过程利用变化来为客户创造竞争优势

3.以从几个星期到几个月为周期，尽快不断地提交可运行的软件

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作

5.以积极向上的员工为中心，建立项目组，给他们提供所需的环境和支持，并对他们的工作予以充分的信任

6.在团队内部，最有效效率最高的传递信息的方法，就是面对面的交流

7.测量项目进展的首要依据是可运行软件

8.敏捷过程提倡可持续的开发，责任人开发者和用户应该为能够保持一个长期的恒定的开发速度而努力

9.时刻关注技术上的精益求精和好的设计，以增强敏捷能力

10.简单是最根本的

11.最好的构架需求和设计出于自组织的团队

12.每隔一定时间，团队要反省如何才能更有效地工作，然后相应地调整自己的行为

敏捷组织提出的敏捷开发模型的整体框架主要有三个：

ScrumXP（eXtreme Programming）OpenUP 这3个敏捷实践

敏捷开发的原则

1.凝聚人的力量，紧密协（合）作包括业务负责人开发团队客户管理者之间的关系，所有这些关系在以前都是造成项目危机的原因之一，那么，在敏捷时代，我们需要这些角色 紧密合作，最大限度的发挥各个角色的力量.

2.聚焦客户价值，消除浪费（如何聚焦用户价值，即频繁的交付用户可工作的软件，快速收到用户反馈）

敏捷团队运作机制

1.一个团队有自己的代办事项，对代办事项进行拆小

2.按客户价值进行优先级排序，产品经理负责价值排序

3.小而稳定，跨职能团队

4.多个团队松耦合（依赖性比较低），对齐迭代时间和战略目标

关键的团队角色

产品负责人

Scrum主管（流程主管）

开发团队

产品负责人（Product Owner）

负责管理产品backlog（代办事项）的唯一负责人

代表客户/项目如责任人

定义产品的所有特性

负责产品的投入产出

负责最大化产品和开发团队工作的价值

Scrum Master（流程主管）

起到教练的职责，领导团队完成Scrum的实践以及体现其价值

排除团队遇到的困难，使得团队紧密合作，使得团队个人具有多方面职能的工作能力

确保团队能胜任其工作，并保持高效的生产率

保护团队不受到外来无端影响

关键的团队活动

每日例会：每日5分钟左右的一个简单例会，尽可能多的开发人员参与进来对紧要问题的讨论

评审会：需要在迭代周期的最后一天召开，1个小时左右就可以了，需要客户出席，如果客户不能出席，则需要产品经理出席

迭代回顾会：迭代回顾会是在每个迭代结束时进行，总结工作中的经验和教训，时间维持在30-60分钟内，整个团队都需要参加（Scrum MasterProduct Owner开发团队以及客户）

迭代回顾会包括两部分，第一部分是定量分析，第二部分是定性分析

其中定量分析又包含团队是否完成了迭代目标，收集并评审迭代度量指标（包括速率迭代燃尽图迭代计划故事和实际完成故事计划发布日期与实际发布日期客户满意度团队满意度生产环境Bug数生产Bug解决时间用户故事等）

定性分析包含哪些工作良好（应该继续保持），哪些做的不好（应该停止）；哪些可以改进（团队选出1－2条在下一个迭代实现）

敏捷开发框架案例： www.learun.cn/Home/VerificationForm

原文：windy

以亲身经历解读敏捷软件开发（一）什么是敏捷软件开发敏捷开发以用户的需求进化为核心，采用迭代循序渐进的方法进行软件开发在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视可集成和可运行使用的特征换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态



价值观
敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通简单反馈勇气，此外，还扩展了第五个价值观：谦逊
互联网是个神奇的大网，软件框架也是一种模式，如果你真的想做，可以来这里，这个手技的开始数字是一八七中间的是三儿零最后的是一四二五零，按照顺序组合起来就可以找到，我想说的是，除非你想做或者了解这方面的内容，如果只是凑热闹的话，就不要来了
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发



沟通
建模不但能够促进你团队内部的开发人员之间沟通还能够促进你的团队和你的project stakeholder之间的沟通

简单
画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进636f7079e79fa5e9819331333363356634



反馈
Kent Beck在Extreme Programming Explained中有句话讲得非常好：过度自信是编程的职业病，反馈则是其处方通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事

谦逊
最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重



原则
敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述而XP中的一些原则又是源于众所周知的软件工程学复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待



核心原则
主张简单
当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案不要过分构建
敏捷开发
（overbuild）你的软件用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统尽可能的保持模型的简单



拥抱变化
需求时刻在变，人们对于需求的理解也时刻在变项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实



你的第二个目标是可持续性
即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现项目投资者的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度简单的说，你在开发的时候，你要能想象到未来



递增的变化
和建模相关的一个重要概念是你不用在一开始就准备好一切实际上，你就算想这么做也不太可能而且，你不用在模型中包容所有的细节，你只要足够的细节就够了没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型这就是递增的思想



令投资最大化
你的项目投资者为了开发出满足自己需要的软件，需要投入时间金钱设备等各种资源投资者应该可以选取最好的方式投资，也可以要求你的团队不浪费资源并且，他们还有最后的发言权，决定要投入多少的资源如果是这些资源是你自己的，你希望你的资源被误用吗



有目的的建模
对于自己的产出，例如模型源代码文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确你不应该毫无意义的建模，应该先问问，为什么要建立这个产出，为谁建立它和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作维护改进系统如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细一旦一个模型实现了目标，你就可以结束工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作该项原则也可适用于改变现有模型：如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样例如，如果你是为维护人员建立模型，他们到底需要些什么？是厚达500页的详细文档才够呢，还是10页的工作总览就够了？你不清楚？去和他们谈谈，找出你想要的



多种模型
开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，要开发现今的商业应
敏捷开发
用，我们该需要什么样的模型？考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于产出的清单，可以参阅AM的建模工件）有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型不同的系统使用不同部分的模型比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型有多少的建模工件可供使用呢，如果你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling



成功

随机应变
要达到敏捷的成功交付支撑业务的最佳软件软件专家也可以引用这些规则



自主权

专注于工作，交付正确的软件，而不是被他人的愤怒情绪所影响

分享经验
构建完美软件开发流程，并没有统一的模式但是在这个领域，敏捷技术，加上持续的应用和改进，都能够达到敏捷的成功