敏捷开发过程范文

敏捷开发的流程是怎样的

敏捷开发是一种做事情的方法，是一套工具，也是一种企业管理方式。

首先解释为什么用敏捷开发：外部市场竞争激烈，赶在竞争对手前交付一个不完美但至少能用的产品非常重要；加上客户的需求也会时常更改（更多的时候客户根本不知道自己想要什么，用敏捷开发可以较快速的解决这个问题）。敏捷开发适用于在一个地方办公的小团队，一般10个人以内，这样能使敏捷中主要的直面沟通是可行的。

其次解释工作过程：1. 站会：三个问题，简洁有效的小团队沟通方式2. 看板：直观反映工作进度，反映流程遵守情况，反映流程缺陷3. 演示，计划，反思会：适合于小团队的协作和优化反馈方式4. 用户故事：站在用户的角度讲需求5. 持续集成：随时高质量交付的基础，有利于应对变化剧烈的市场最后提几点敏捷开发的好处：敏捷不专注于敏捷团队中个人的绩效考核，而更多的侧重于整个团队的绩效，更好的避免了KPI驱动模式；把大项目拆分成小项目去做，把bug的生存期控制在一个迭代以内，降低了风险，也减少了后期改bug的工作量；把数十人的大team分成几个敏捷团队，这几个敏捷团队的的leader再组成一个更高一级的敏捷团队，利用站会，反思，看板等等敏捷元素，可以避免数十份邮件也不能解决一个小问题，大家互相踢皮球，沟通不畅的问题。

什么是计算机软件敏捷开发

常讨论敏捷开发过程的知识，并且我们也会经常争论结合使用敏捷开发过程和CMMI高级别的话题。

他们两个是否能够结合使用？或者他们两个只是向相反的方向发展？带着这个疑问，下面我们一起来探讨。这个问题可以说是老生常谈，但是我对第5级别中的那个基本差异有一个疑问，这个疑问会使人产生不安的情绪。

CMMI1。2强调了想在组织中控制结果的变更，进而将其重心转移到了个人的身上。

敏捷开发在意义上说不单单是为了让每个项目能在应对各种各样的环境中都拥有灵活的能力，并且可以让他们在这个环境中尽其所能表现的最好。我们并没有特别关注在所有项目中要规范行为以便可以预知结果是可靠的。

但是，我并不清楚我现在尽力想说明的这种区别，是否确实是敏捷开发和CMMI的基本概念中的一个基础的区别，还是只是组织如何解释和执行CMMI第5级别的一个结果。当然，敏捷开发团队在过程模型和过程实践资产中拥有的信任似乎要比CMMI团队中的要少――虽然在敏捷中没有方法可以规范这些事情即便他们是低成本的，但是没有假设说明这就是组织要走的路。

事实上，敏捷开发支持者偏向于这样的想法，在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果。是否这就是等同说敏捷开发支持者相信特殊原因会影响执行效果是如此的普遍，以至在组织中试图建立预见性的模型是无用的？ CMMI第4级别： QPM（量化项目管理）：主要关注懂得过程行为变更的个别项目，他们认为这些变更影响着他们的成功和如何处理事情――或者至少影响着完成产品发展或者达成目标。

组织单位（EPG）必须要监控成果。 OPP（组织过程实践）：主要关注集成模型，项目可以使用模型来规范他们想要达到成功的方面，比如说质量，进度表，预算，维护以及其他任何事情。

诀窍就是项目在过程执行中以这些模型为基础，控制QPM中的行为。比较典型的是，这些模型可能是基于相似的项目中的重复的结果不断建立起来的，虽然可能并没有这样的需求。

在个别项目级别中模型应该先被改进以便使用，所以在CMMI模型中使用基于一个项目的历史数据（比如说，增量）或者20个项目的历史数据是没有区别的，虽然这可能对使用者来说是有区别的。 CMMI第5级别： CAR（原因分析与解决方法）：主要关注引起问题的主要原因，过失，管理问题或者其他一切需要解决的问题。

项目，EPG或者其他任何人是否可以应用，是作为解决问题的方法。EPG在OPP中监控结果，或者得到别的经验。

（敏捷开发是否在增量开始点或者结束点不建议进行类似的行为？我不清楚我所知道的术语是否正确） OID（组织创新与推展）：完全非项目特点。关注基于个体，CAR，模型使用，外界因素等的组织改进。

你是否会收集并且使用所有这些学到的经验？你进入企业后是否会寻求新的或者更好的做生意的方法（其中敏捷开发可能只是一个例子）？在组织中又该如何处理证明，分析（职业），和使用（结构请参照第4级别中的模型和过程控制）这些改进。我个人认为CMMI高级别和敏捷开发应该结合起来工作。

敏捷可以帮助CMMI高级别更容易实现短期的转变，并且它在处理事情的发展上起了很重要的作用。我的经验基本是从第5级别得来的，有部分来自第4级别。

许多组织怀着每个人都必须如此做的想法而通过了第3级别，但是他们却反对在第4,5级别中有着同样的想法。就像我曾经提到的，敏捷开发是使用CMMI第4,5级别来改进如何发展产品的完美例子。

敏捷开发方式有哪些

敏捷开发包括一系列的方法，主流的有如下七种：

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开发方法而已。

软件开发方法之敏捷开发,你用了么

1）敏捷开发的过程有着更强的适应性而不是预设性，从敏捷宣言的第四条响应变化高于预设计划便可以看出来。

因为软件开发过程的本身的不可预见性，很多用户在项目开始时不可能对于这个项目有着一个完整而明确的预期。很多对软件的预期都在后期的修改和完善过程中产生。

因此高适应性显然更加符合软件工程开发的实际。而敏捷开发实现其适应性的方式主要在于，第一，缩短把项目提交给用户的周期；第二，增加用户，业务人员，开发人员这三者之间的交流；第三，通过减少重构的成本以增加软件的适应性。

（2）敏捷开发的过程中，更加的注重人的因素。在传统软件工程中，个人的因素很少的被考虑到分工中，每个个体都是只是整个代码开发机器的一个小小的螺丝钉，个人的意志和创造力很大程度上的被抹去为了更好的为集体服务。

而在敏捷开发过程中，每个个人的潜力被充分的考虑，应用什么技术很大程度上直接由在第一线开发的技术人员决定；每个人的特点和创造力都可以充分地发挥，这样开发出来的软件更加的具有生命力，因为他融入了开发者的心血和创意，开发者不再是进行机械的乏味的堆砌，而是创造属于自己的艺术品，这样的条件下产生的代码必然在质量上更占优势。（3）在敏捷开发的过程中，整个项目是测试驱动的而不是文档驱动的。

不仅每个模块有着自己的相应的测试单元，开发人员在开发自己的模块的过程中必须保证自己所开发的模块可以通过这一单元的测试，并且集成测试贯穿了整个开发过程的始终。集成测试每天会进行十几次甚至几十次，而不是像传统方法一样只有当各个模块的编码都结束了之后再进行联合调试。

这样，在软件开发的进程中每一点改动所引起的问题都容嘉容易暴露出来，使得更加容易在错误刚刚产生的时候发现问题从而解决问题。这样就避免了在最后整个系统完成时错误隐藏的太深给调试造成极大的困难。