敏捷软件开发简介

敏捷软件开发简介（通用8篇）

篇1：敏捷软件开发简介

敏捷开发简介

2009-04-21 17:46:34.0来源:e800.com.cn

关键词：Scrum精益开发敏捷开发

在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：

1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候

集成，有些项目则每天都在这么做。

5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给

人。

简史

许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Software Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8

个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。

20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生

了一件有趣的事情。美国国防部一直以来都要求其软件开发商在开发过程中使用严格的瀑布开发模型。但是到了1987年末，国防部开始“建议”使用迭代和增量开发作为软件开发模式。后来美国国防部的项目审查显示，早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。

20世纪90年代，推荐使用迭代和增量开发的出版物和文献显著增加。在经历了多次有“瀑布心态”

（„waterfall mentality‟）项目的失败之后，美国国防部开始“要求”而不是像80年代那样仅仅是“建议”他们的软件开发商使用IID开发模式。Rational统一开发过程（Rational Unified Process）也是在这一时期产生并发展起来的，它具有更规范的迭代渐进过程。到2000年底，更多的敏捷方法被广泛推广并被使用于各种不同的项目中。2001年二月，一组由17位在DSDM，XP，Scrum，FSD等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所

认识的敏捷开发和后来的敏捷联盟。

敏捷优势

为什么瀑布模式多数情况下总会失败？为什么我们需要敏捷开发模式？这个问题在日新月异，飞速发展的今天似乎很容易解释。尽管瀑布模式能够在一个迭代周期内表现优异，但是，在如何管理需求变化面前，瀑布模式

却显得无能为力。而事实上，大多数的软件项目都具有以下一些特点：

·在初始阶段，最终用户通常不能准确得知道他们需要什么样的软件。即便知道，也很少有人能准确清楚的表

达出来。

·对于某些项目，在一开始，我们可以很好的定义其所有的功能，但是可能有很多细节只能随着项目的不断深入才能被挖掘出来。即便是我们了解了所有的细节，大多数人还是不能很好的处理这些细节，特别是在项目开

发初期。

·外部环境如客户的业务模式，技术进步，甚至是系统的终端用户都有可能在开发过程中不断改变。而预想或

试图阻止这些改变通常都是徒劳的。

·在互联网时代，许多Web应用程序的开发都是基于对远景客户的预期，而非当前用户的实际需求。在这种

情况下，变化从开始就有，而且在系统开始应用后几乎每天都会发生。

敏捷方法处理需求和技术变化主要通过迭代过程来管理。在每一次迭代周期结束时，都应交付用户一个可用的，可部署的系统。使用并体验该系统所获得的有价值的反馈意见将按顺序，在随后的迭代周期中和其它需求变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时频繁地处理需求变化和用户反馈。

采用敏捷开发方式将会给企业和用户带来诸多好处：

·精确。它将带给用户真正需要的软件系统。瀑布模式通常会在产品起点与最终结果之间计划出一条直线，然后沿着直线不断往前走。然而当项目到达终点时，用户通常会发现那已经不是他们想去的地方。而敏捷方法则

采用小步的方式向前走，每走完一步，都需要及时调整并为下一步确定当前的方向，直到真正的终点。·质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如XP等，甚至使用测试驱动开发（test-driven development），即在正式开发功能代码之前，先开发该功能的测试代码。这些都对敏捷项

目的整个开发周期提供了可靠的质量保证。

·速度。敏捷开发提倡避免较大的前期规划，认为那是一种很大的浪费。因为很多预先计划的东西都会发生改变，大规模的前期规划通常是徒劳的。敏捷团队只专注于开发项目中当前最需要的，最具价值的部分。这样能

很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。

·丰厚的投资回报率（ROI）。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。

·高效的自我管理团队。这既是采用敏捷开发的必然结果，也是推动敏捷开发不断前进的动力。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力，交流，社交，表达和领

导能力也都能得以提高。

主要的敏捷方法

极限编程（XP）

极限编程（XP）的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法，并将它们发挥到极致。比如，为了能及时得到用户的反馈，XP要求客户代表每天都必须与开发团队在一起。同时，XP要求所有的编程都采用结对编程（pair-programming）的方式。这种方式是传统的同行审查（peer review）的一种极端表现，或者可以说是它的替代方式。

XP定义了一套简单的开发流程，包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测

试，验收测试等等。

像所有其他敏捷方法一样，XP预期并积极接受变化。它具有以下的价值观或原则：

·互动交流。团队成员不是通过文档来交流，文档不是必须的。团队成员之间通过日常沟通，简单设计，测

试，系统隐喻以及代码本身来沟通产品需求和系统设计。

·反馈。反馈是一种信息的交流，能使系统更加完善。反馈也和交流密切相关，客户的实际使用、功能测试、单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈

给客户。

·简单。XP提倡简单的设计，简单的解决方案。XP总是从一个简单的系统入手，并且只创建今天，而不是明

天，需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。

·勇气。XP在这一点所要达到的目的（我们认为）是鼓励一些有较高风险的良好的做法。例如，它要求程序员

尽可能频繁地重构代码，必须删除过时的代码，不解决技术难题就不罢休，等等。

·团队。XP提倡团队合作，相互尊重。XP以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统

中。因此，每个人的代码质量必须过关。

核心做法：

·小规模，频繁的版本发布，短迭代周期。

·测试驱动开发（Test-driven development）。

·结对编程（Pair programming）。

·持续集成（Continuous integration）。

·每日站立会议（Daily stand-up meeting）。

·共同拥有代码Collative code ownership.·系统隐喻（System metaphor）。

SCRUM Scrum是一个敏捷开发框架，它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于

软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。

在Scrum中，产品需求被定义为产品需求积压（product backlogs）。产品需求积压可以是用户案例，独立的功能描述，技术要求等。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开

发的程度。

Scrum将开发过程分为多个Sprint周期，每个Sprint代表一个2-4周的开发周期，有固定的时间长度。首先，产品需求被分成不同的产品需求积压条目。然后，在Sprint计划会议（Sprint planning meeting）上，最重要或者是最具价值的产品需求积压被优先安排到下一个Sprint周期中。同时，在Sprint计划会上，将会预先估计所有已经分配到Sprint周期中的产品需求积压的工作量，并对每个条目进行设计和任务分配。在Sprint开发过程中，每天开发团队都会进行一次简短的Scrum会议（Daily Scrum Meeting）。会议上，每个团队成员需要汇报各自的进展情况，同时提出目前遇到的各种障碍。每个Sprint周期结束后，都会有一个可以被使用的系统交付给客户，并进行Sprint审查会议（Sprint review meeting）。审查会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求积压的形式保留下来，并在随后的Sprint周期中得以实现。Sprint回顾会随后会总结上次Sprint周期中有哪些不足需要改进，以及有哪些值得肯定的方面。最后整个过程将从头开始，开始一个新的Sprint计划会议。

Scrum定义了4种主要的角色：

·产品拥有者（Product Owner）：该角色负责产品的远景规划，平衡所有利益相关者（stakeholder）的利

益，确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。

·利益相关者（Stakeholder）：该角色与产品之间有直接或间接的利益关系，通常是客户或最终用户代表。

他们负责收集编写产品需求，审查项目成果等。

·Scrum专家（Scrum Master）：Scrum专家负责指导开发团队进行Scrum开发与实践。它也是开发团

队与产品拥有者之间交流的联络点。

·团队成员（Team Member）：即项目开发人员。

Scrum提供一个敏捷开发框架，其他许多敏捷方法都可以被集成到Scrum中。比如测试驱动开发（test-

driven development）和结对编程（pair programming）等都可以被整合到Scrum中。

精益开发（LEAN DEVELOPMENT）

精益软件开发模式是从丰田公司的产品开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原

则，另外一部分由一些在相应的工具构成。

精益开发的核心思想是查明和消除浪费。在软件开发过程中，错误（bugs），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法消除。精益开发的其它原则

包括:

·强调学习。软件开发过程是一个不断学习的过程。每个团队成员都需要从日常的失败，互动，交流以及信息

反馈中学习，不断改进所开发的产品和开发效率。

·在最后时刻做决定。这样可以避免在可能改变的事情上做无谓的努力，从而有效的避免浪费。

·用最快的速度交付用户。较短的迭代周期能够加速产品的开发及交付，加快交流，提高生产力。

·给团队自主权。激励团队并让所有团队成员自我管理始终是所有敏捷方法获得成功的基本因素之一。·诚信。确保整个系统正常工作，真正满足客户的需求是整个团队需要努力坚持的诚信和和对用户的承诺。·全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品，从整体上考虑优化比从各个局

部去优化更高效。

对于上述的每个原则，都有一些相应的实现工具。这些工具包括价值流图（Value Stream Mapping），基于集合的开发（set-based development），拉系统（pull system），排队论（queuing theory），等

等。

和其它敏捷方法相比，精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷

开发模式一起使用将会取得很好的效果。

其它敏捷方法

动态系统开发方法（DSDM）是由快速应用程序开发（RAD）方法演变而来的敏捷开发模式。DSDM在普遍的敏捷价值和原则的基础上，定义了更加详细的流程，以涵盖更完整的项目生命周期。它们包括项目前期活动

（pre-project activities），项目可行性研究，功能建模，设计和开发，实施或部署，项目后期维护（post-project maintenance），等等。同时，每个过程都定义了诸如如何将每个功能模型转化为实际代码，如何将原型交付最终用户使用并审查，如何处理反馈信息等的详细步骤。因此，DSDM相比于其它敏捷

方法在过程上显得比较繁重。

特征驱动开发（FDD）是另一种敏捷开发方式，它将用户的功能需求划分成更小的功能特征，然后逐步地在每个迭代周期中开发实现这些产品特征。与DSDM方式一样，FDD仍然会在项目初期对整个项目做较大的规

划和建模，以获得对该系统的全面了解。但是相比DSDM来说，FDD在这些方面简捷了一些。

Crystal Clear是另一种敏捷方法。Crystal Clear更专注于人。相比于其他的敏捷方法，它可使人获得更大的解放。据称这种方法更适合于较小规模的开发小组（由2-8个人组成）和非关键项目。Crystal Clear定义了七种属性。前3个属性-频繁的交付（frequent delivery），渗透交流（osmotic communication），反思提高（reflective improvement）-反映出基本的敏捷开发做法和价值，如周期较短的迭代式开发，自我管理的开发团队和反馈带动增量发展等等。另外的4个属性分别是：个人安全（personal safety），集中

（focus），容易接触专家用户（easy access to expert users）和技术环境（technical

environment）。其中，容易接触专家用户实际就是敏捷方法中提到的客户持续参与，但Crystal Clear对此要求比较宽松。Crystal Clear也提供了一些通用的做法，比如，它提供了三种回顾分析的方法：访谈，问卷调查和工作组。Crystal Clear的过程也是相当简单，其中涉及短的迭代周期，日常会议及持续集成等。还有其他一些敏捷方法如敏捷统一过程（Agile Unified process），上下文驱动开发（Context Driven Development），Getting Real等。这些方法都是增量和迭代开发过程，并且重视人多过于整个过程。而各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷

开发，并且了解更多的最佳应用。

如何选择一种敏捷方法

选择一种合适的方法取决于多种因素。在做出决定之前，我们需要充分考虑以下这些方面：

·方法的复杂度。确保你的团队或组织能够应付这种复杂度。

·社区和业界支持。流行的方法可能并不是你最理想的选择，但流行的方法 至少有较多的社区及行业支持，可

以使你受益匪浅。

·实用工具。选择一种可以为你提供支持工具的方法。一个良好的软件工具可以帮助团队有效的处理日常工

作，促进团队协作，并减少管理成本。

·你目前的开发方式以及团队关于敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有

助于推动该方法的实施。

·你的团队规模。较小规模的团队最好从简单的方式入手。当然，这并不意味着你必须选择那些本身就比较简单的方法如Crystal Clear。你可以选择一些相对比较全面的方法，但从简单入手。当你的团队规模逐渐扩

大，再增加相应的细节。

·你不需要只遵从一种方法。你可以为团队选择一个主要的方法（如Scrum），然后从其他方法中借鉴对你的团队或组织有所帮助的其他方式加以整合。

敏捷总是在不断发展演变，因此，没有一个人能保证目前的敏捷方法都是正确的。每个采用敏捷开发的团队都

可以通过发现并形成自己的想法和最佳实践，对敏捷开发做出自己的贡献。

相关培训服务请查看：http:///services/training

1.SCRUM SCRUM?这个单词我以前没见过,所以我就不喜欢它,呵呵.SCRUM本义表示“混乱”,它包括

多个“怪异”的方法/过程名称。比如，SCRUM将开发过程分为30天的迭代周期，每个

迭代周期叫做一个Sprint(原意:冲啊!)；每天有一个15分钟的短会，用来决定第二天的任务安排这样的短会就叫做scrum。

我不喜欢SCRUM的原因如下:

1)一个方法,搞出这么多名词,加重我们程序员的负担,不好;

2)SCRUM的迭代周期为30天,而且一个周期叫一个“冲”,那不是要累死我们程序员?

3)每天有一个15分钟的短会,唉,XX党的会多!

4)15分钟的短会叫“混乱”,那....,15分钟能结束吗?

5)SCRUM强调,开发者每天要向管理者报告项目进度,唉,我受不了了....2.Crystal Crystal根据项目规模和项目的重要性(如发射火箭的项目和一个“hello world”程序的重要性当然是不一样的)来区别项目,并赋以相应的方法,所以,crystal是方法的组合.相对于其它敏捷方法,Crystal强调软件开发流程的纪律性,所以,它比其它敏捷方法易

于使用,但它的生产率不如XP等其它敏捷方法.3.ASD（Adaptive Software Development）

ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论(这个

名字大家应该都听说过了,炒股的用的很多,呵呵)。ASD不象其他方法那样有很多具体的实践做法，它更侧重于理论,因为它的作者就是搞理论出身的。

4.FDD FDD（Feature Driven Development）定义了5个流程，分别是Develop an Overall Model、Build a Features List、Plan by Feature、Design by Feature和Build by Feature。

前3个流程是在项目开始就进行的，其实总体相当于我们现在的系统分析;后两个则出

现在每次迭代周期中,FDD的迭代周期是两周,相当于我们现在的设计/编码/测试。

开发人员被归为两种，一种是主程序员，另一种是class所有者。主程序员不作具体的编程工作，但要负责将Feature和Class对应起来，并充当开发协调者、设计者、技术

支持和指导者等；class所有者则进行实际的编程。我认为这样的划分对国内的软件开

发情况不合适,因为,真正达到主程序员水平的人,太少了!

对于ASD和FDD,国内介绍的还是比较多的.5.XP

篇2：敏捷软件开发简介

什么是敏捷开发？

一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。

通过这项工作，他们认为：

·个体和交互 胜过 过程和工具

·可以工作的软件 胜过 面面俱到的文档

·客户合作 胜过 合同谈判

·响应变化 胜过 遵循计划

并提出了以下遵循的原则：

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

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

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。

责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。

简单是最根本的。

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

每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

参看《敏捷开发横空出世》

极限编程（XP）是一种轻量级的软件开发方法论，XP从实践中来，是对实践的总结，也是经过实践检验的，其主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动精神。XP承诺降低软件项目风险，改善业务变化的反应能力，提高开发期间的生产力，为软件开发过程增加乐趣，相信这些足以吸引每个人的眼球。

在XP的项目开发中，首先引入了四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。

为了能成功地实施XP，XP制定四个准则：沟通、简单、反馈和勇气

和十二条原则：计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代码集体所有、持续集成、每周工作40小时、现场客户、编码标准

以及对开发人员的工作要求：编码、测试、倾听和设计。

篇3：敏捷软件开发应用分析

1敏捷软件开发价值观及开发原则分析

1.1敏捷软件开发价值观分析

对敏感软件的开发有着相应价值观, 在经典软件工程方面旨在定义完备的过程规范, 从而使得软件开发运作犹如机械设备运转一般, 人在其中知只是起到零件更换的作用。敏捷软件还提出了实施软件开发要能对人的积极创造性充分发挥。从重型方法观念层面来看其认为软件等于文档加代码。敏捷软件开发对客户参与有着强调, 并给客户调整需求机会对客户的需求得到了有效满足。

1.2敏捷软件开发原则分析

敏捷软件开发过程中要能够遵循相应的原则, 最为主要的是满足客户的需求, 开发出真正有价值的软件, 即便是到了软件开发后期也要能够对对需求充分重视, 将其放在首要位置。通过开发的变化对客户创造出竞争优势, 要能经常性交付可工作软件, 在间隔上最好是愈短愈好。并且在整个项目开发当中开发人员和业务员的关系要保持融洽, 这样才有利于软件的实际开发, 然后要能围绕被激励的个体对项目加以构建。敏捷过程要提倡可持续开发速度, 开发简单的软件是根本目的。

2敏捷软件开发方法特征及敏捷管理优势

2.1敏捷软件开发方法特征体现

对敏捷软件开发有着显著的特征, 主要体现在灵活性以及简捷性等层面, 其中在灵活性层面主要是通过迭代式开发流程, 把整体开发过程细化成比较独立并完整的阶段进程, 这样在每阶段进程中开发人员就能对产品方向随时进行调整。和传统的设计模型相比较而言, 这一开发就比较方便适用于现代的软件产品研发, 在灵活性特征方面以及持续性方面的体现就使得其应用的广泛性也能得以突出。另外, 在敏捷软件开发的简捷性特征层面主要是对客户需求比较重视, 在此基础上将软件开发的应用性能也能有效提升。

2.2敏捷管理的主要优势分析

敏捷管理方法对软件的开发有着重要意义, 也有着诸多优势呈现, 有着允许用户需求变化的优势, 在这一变化方面能够将成本降到最低程度。还有是对设计的错误有了相应减少, 在未经编程想象的设计实施编程阶段就可能发现有的地方是错误的, 而敏捷管理方法就是把设计工作和编码实现工作得到有机融合, 从而就能够减少错误情况的发生。同时也能将项目风险得以有效降低, 敏捷管理的方法主要是对尽快发布可运行及有价值软件有着强调, 也提出了明确需求。由于这一管理的方法对传统方法的繁重文档维护成本得到了有效降低, 所以就在时间成本的减少层面有了显著体现。最后就是在评估进度以及工作量方面较为方便化, 所以通过敏捷管理的方法在软件开发中的作用还是比较突出的。

3敏捷开发在维护性软件开发中的可行性及开发模型

3.1敏捷开发在维护性软件开发中的可行性

软件维护性开发和软件全新开发项目两者就有着一些不同, 从软件维护过程方面主要有更改需求获取以及程序设计实践变化等等, 在每次的软件维护方面就是小型严格的需求限制活动。根据实际的软件维护过程就能够看出, 软件维护开发有着特定特征就能够适应敏捷软件的开发, 这些特征主要体现在软件开发中维护人员和对软件系统结构较为熟悉, 还有是软件维护性开发当中的是最终结果, 并且对时间过程文档资料的要求相对较少。软件维护开发中更改需求要和需求人员进行充分有效的沟通。软件维护是在软件系统交付使用后对其实施的有效更改, 其最为主要的目的就是修改缺陷将软件性能进行有效提升。

3.2敏捷开发在维护性软件开发中的开发模型

敏捷开发在维护性软件开发中的开发模型分析也是比较必要的, 为能够有效满足保险应用系统维护性开发的需求, 就要能够将敏捷开发的方法进行有效适用, 从而才能获得良好效果。结合软件维护特征以及敏捷软件开发特征在多次软件维护过程实践中总结了相应的开发模型, 通过开发模型就能够对整个过程得到明晰。从开发模型中的名词解释方面来说就有着行业标准以及内部编码规范等内容, 例如在行业标准方面就有业务需求类型以及开发类型, 前者主要是涉及到的行业规范, 而后者则是在开发时候所涉及到的行业标准。

另外就是开发模型中的项目开发过程, 这就有着项目参与人员以及需求讨论等内容, 在参与人员方面就有着开发人员以及需求人员, 开发人员是参与需求讨论和对系统开发完成的。而需求人员是对模型的审核以及确认等测试来进行参与的。需求讨论方面则主要是结合行业标准开发人员结合需求实施修改模型获得需求人员认可等。

4结语

总而言之, 对于敏捷软件的开发应用理论分析基础上, 能够进一步了解当前的软件开发过程以及重要性, 为软件开发应用创造出有利发展条件。此次主要就敏捷软件开发应用的特征以及优势等层面进行了理论分析研究, 希望能够在此次的努力下为敏捷软件开发的效率提升有所裨益。

参考文献

[1]丁志平.敏捷软件开发中的风险管理[J].信息与电脑 (理论版) , 2014 (01) .

[2]高志升.改造敏捷模型在高校软件开发中的实践[J].电脑知识与技术, 2014 (07) .

[3]桑大勇.敏捷开发过程中的需求分析[J].程序员, 2014 (02) .

[4]马波.敏捷开发方法在游戏软件开发中的应用[J].电脑知识与技术, 2013 (06) .

篇4：给敏捷开发加上管理

敏捷开发之所以广受认可，是因为强调持续集成、快速迭代、重构、测试驱动的敏捷开发与传统开发方法相比，能更快速、更有效地交付给客户可用的软件，在市场竞争日益激烈、强调新产品快速交付的今天，能更好地支持企业创新。

然而，敏捷开发并不是一剂万能药，不能解决软件开发团队的所有问题，甚至也不能用以完全取代传统开发方法（比如瀑布流开发）。曾有研究机构进行过调查，走向敏捷开发的公司中有73%并不完全是敏捷开发，而是敏捷开发与传统开发同时采用。

“敏捷开发最初是作为传统开发方法的颠覆者出现的，它摒弃了传统开发方法在工作流程上的严格限制，能更好地彰显软件开发者个人的创造力。然而，在管理方面天生不足，比如规划管理、需求管理、资源管理等方面。”TechExcel公司创始人兼CEO周铁人博士告诉记者。

TechExcel是周铁人博士于1995年在美国加州创建的一家以软件开发为主要业务领域的公司。最初的10多年来公司一直专注于提供软件开发工具，近5年来逐步将业务重点转到软件项目管理。作为公司创立者的周铁人对包括敏捷开发在内的软件开发过程管理和项目管理也有着更为深入和全面的认识。基于多年的软件开发经验的积累，周铁人总结出了一套软件开发的方法论——SpecDD （需求驱动开发），并基于它推出了一套软件开发及项目管理的工具。

“让敏捷开发的团队有一个好的工具，更好地走上敏捷之路。这是我们推出SpecDD方法论及其相关解决方案的初衷。”周铁人说。

SpecDD是一个开发框架，旨在促进敏捷开发过程中的两个交付件：可执行的软件和量化的产品设计。周博士说，SpecDD的本质是一种混合开发模式，既兼容敏捷开发的快速、灵活的优点，同时又融入了传统软件开发方法在开发过程管理方面的优势。

因为敏捷开发否定了文档、流程，也几乎没有需求管理，而这些对于大型软件项目的管理非常必要。以需求管理为例，敏捷开发的入口只有一个简单的功能列表，而大型软件项目的需求涉及很多人，制订功能列表是一个比较复杂的过程，对工作量也需要进行预估。另外，由于敏捷开发没有需求管理，也就没有了需求用例管理，而这些用例对将来的测试是非常重要。

SpecDD要求软件的开发过程由一组连续的迭代组成，每次迭代都含有两个交付件：改进后的可执行软件，可以发布给内部团队和客户验证;改进后的“概念产品”，对原始需求更好的理解，包括需求、设计和质量标准的改进。可执行的软件可以用于市场的商业发布，并为企业带来成功。“概念产品”则在内部团队进行沉淀，并让团队在将来持续获得成功。

篇5：8044敏捷开发方法

Marty Cagan 发表于6月1日，原文地址，译者：蒋彬 / 审校：周舜莉 徐定翔

许多产品开发机构都尝试过所谓的“敏捷软件开发”方法，其中最为流行的是“极限编程”(XP)，此外还有其它一些敏捷方法，比如Crystal、Adaptive、Scrum和Pragmatic Programming等。

在使用这些敏捷方法时，产品经理常常弄不清自己的角色定位。有些产品经理甚至担心采用敏捷方法会影响产品质量。

我打算首先总结敏捷开发的核心原则，然后以极限编程(XP)?为例，指出极限编程的难点，以及如何更好地发挥它的作用。

敏捷方法一览

各种敏捷方法的要求千差万别，但是它们都遵循以下12条原则。?

1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户——尽早交付有价值的软件。

2、?频繁地交付可运行的软件，数周或者数月交付一次——频繁发布新版本。

3、可运行的软件是衡量进展的主要标准——软件比文档更重要

4、接受?需求变更，即便是在开发最后阶段——倾听，并快速学习

5、项目期间业务人员与开发者共同工作——紧密协作?

6、找积极主动的人来开发项目——为他们提供所需的环境和支持，相信他们能做好自己的工作

7、开发团队里最节省时间最有效的信息传递方式是面对面的交流

8、?自发组织的团队才能做出最好的架构、和设计——架构要敏捷，好主意无处不在

9、?持续关注先进的技术和优秀的设计能促进敏捷性——频繁地重构

10、?敏捷过程促进可持续的开发——此举应能维持相对稳健的节奏——而不是?导致失败

?11、简洁是一切的基础——少即是多

12、?团队定期反思如何提高效率，并调整?工作流程——事后反思?

极限编程概览?

要阐述?遵循敏捷方法到底意味着什么，?不妨看看敏捷方法中最为流行的极限编程的详细规范。该方法的发明者强调，极限编程并非万能，应该有选择性地加以使用。其主要原则如下。

-结对编程——两位程序员使用同一台电脑开发同一款软件

-简单设计——只设计和开发你现在就需要的东西，不考虑将来的潜在需求

-现场客户——客户代表入驻开发团队，他代表了所有产品的需求，在开发过程中不断的说明需求并帮助决策

-增量开发——频敏小规模发布产品?，快速推动产品?进入理想状态

-做好规划——工程师只做评估，客户决定?每次发布的功能和时间

-持续评审代码——基于结对编程的模式，两位开发者相互评审对方的工作

-持续测试——开发者在编码时就撰写单元测试，客户则撰写用例中规定的功能测试，?这些测试均是自动、持续地进行

-持续构建——持续开发和整合软件，这样能及早发现问题，系统也一直处于可构建的状态

-持续重构——软件开发人员不懈努力，通过重构代码来简化和改进工作，同时保证所有测试正常运行?

-代码共有——与每个开发人员“独享”?自己的代码这一模式不同的是，极限编辑模式中每个开发人员只要认为有机会有必要，就可以优化系统中任意处的任意代码?

-开放的工作场所——指整个团队都在一个在房间里共同工作，其中开发人员坐在中间

-每周工作40小时——限制加班以提高工作质量?

-代码即文档——最有用的文档就是软件本身，整个团队应该遵循编码规范

当然了，这种方法是从软件开发人员的角度提出来的，

在他们看来，除了程序员和用户(客户)，就不需要其他工作人员了。这正是让产品经理感受担忧的地方。?

产品经理的工作至少包含以下三个方面。?

定义产品

首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的，目的是满足特定客户的特定需求(比如内部员工薪资系统)，它并不适用于通用产品。事实上，在描述极限编程方法的图书和文章里，几乎很少提及产品管理或是界面设计。

最让人担忧的通常产品经理能否代替现场客户的作用。只有在深入研究目标用户、理解用户需求、使用环境以及竞争格局，产品经理才能发挥最大的作用。

更让人担心的是产品设计(界面设计)角色的缺失。对于产品来说(不同于那些签署合同后开发的定制软件)，用户界面和用户体验至关重要，需要专业设计师运用其专业技能进行设计，因此在工作流程中引入这一重要职位非常重要。

只要把最初的迭代作为持续演进的原型并不断检验，以确保开发团队能开发出正确的产品，然后再在接下来的迭代中实施产品执行，就能更好地利用极限编程方 法。关键是确保你开发的产品是客户想要购买的，而且客户能搞清楚该如何使用。只有一个客户或是产品经理理解这个产品并不足够，它应该为目标市场的广大群体 所检验。

开发产品

其次要考虑的是，??这些用来开发可扩展、?高性能、可靠、易维护产品的技术会带来什么样的后果。这些担忧使人马上陷入一种近乎宗教狂热的争论，争论的重 点是，什么才是开发和测试软件的最佳方法，而这完全在产品管理职责之外。?产品经理?只需要清晰地确定需求，然后让技术团队按自己认为最合适的方式来控制 风险。?

极限编程过程依靠客户来定义用例(又被称为用户故事)?，以此作为功能测试的基础。这用在小型项目上或许还不错?，但如果是大型、通用产品的话，有必要请 专人来负责设计必要的测试用例，以确保可扩展性、功能、性能、容错性和本地化特性等。这些通常都是QA的职责，极限编程的方法完全也可以借鉴。关键是让开 发人员负责单元测试，QA人员负责其它测试(比如系统、集成和功能测试等)?。?

部署产品

最后一个为人们所关注的，是产品的发布。人们长期以来一直认为随着时间的推移，做出改变的成本也越来越高，但极限编程挑战了这一看法。换言之，只要遵循极 限编程实践，你可以降低开发中系统需要变更带来的影响。这对于定制化软件来说这没错，但对于许多商业软件产品来说，变更带来的影响仍然很大，尤其是对于拥 有大量活跃用户群体的互联网服务来说。

我曾经探讨过“平滑部署”的?策略，这些方法有助于降低极限编程项目所提倡的频繁发布和更新策略所带来的负面影响。

?总结

大到敏捷开发，小到极限编程方法，都是为了解决传统软件开发方法中的实际问题而创造的，尤其是致力于增强开发人员与客户的沟通，节省时间及早弄清楚你所开发的产品是否正是客户需要的，并减少增量开发过程中的风险，同时优先开发高优化级的功能。此外还有另外一些颇有价值的技术，尤其是结对编程、增量开发、持 续集成与自动化测试等。?

?然而，对于提供商用产品及服务的公司来说，更重要的是将这些方法与产品管理、产品设计、质量保证结合起来，确保你开发的产品能为广大用户和消费者使用。这样的话才能覆盖较广的消费者群体。

本文节选自《启示录：打造用户喜爱的产品》作者Marty Cagan的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。

篇6：用敏捷方法做软件重用

Brandon Olivares发起了讨论。他说，他刚刚在某些代码上用了30小时的时间，然后觉得这些代码可能会被重用，于是就觉得很矛盾，不知道是不是该把这些代码抽象出来，这样其他项目就有可能也用得到。

按照我个人理解来看，XP不鼓励假想某些东西可能会被用到，除非确实到了要用那个东西的时间点上。还是我的个人理解，刚才所说的东西也包括提取代码以供日后重用，XP提倡的是到了出现重复的时候再去做重构。

软件重用长期以来一直被极力宣扬为可以大量节省时间，也许另一个项目中的人可以重用你的代码，而不用重新开发。Brandon想知道其他人都是怎么决定在什么时候抽象代码加以泛化的。

Ron Jeffries第一个回复，他讲了为什么跨团队重用的做法比初看起来要困难且昂贵得多：

我必须得给它打包，要是就我自己用的话这活就不用干了;我得给它写文档;我得让它更加抗造，把周边的一些问题去掉;我得给它提供支持，回答很多问题;我得训练别人用它。

如果我做了这些事情，代价就很高;如果我不做，别人用我的东西就很困难，给他们带不来多少帮助。

因为这些原因，Ron采取的是这种做法：

我只做适当的抽象，够自己用就好，

管理资料

如果我以后在一个稍微不同的环境下还需要用的话，我就会改进抽象。不过除非我的项目目标是给其他项目构建成品，我就不会浪费时间和金钱去给其他项目做东西。

还有一位认为，如果所有的项目都共享一套通用构建系统和测试套件，那重用就会容易一些。在这样的环境中，如果某个团队打算重用某些可以泛化的代码，这个构建系统就可以保证他们不会给其他需要这些代码的团队造成障碍。

George Dinwiddie、Ralph E. Johnson等人推荐到第二次(乃至更晚)用到同样代码的时候再做泛化。Adam Sroka把这个叫做“演化重用”，他认为这种方法比“为重用而设计”效率更高。一名叫做Tim的人发帖说，他这样给业务人员解释：“第一次，你是给编码买单;第二次，你是给重用买单;第三次，它就是免费的了。”

George指出，更困难的地方在于怎么让其他团队意识到有些代码可以重用。帮助大家发现良机的沟通成本可能会很高。Jeff Langr说，让开发人员跨团队结对，可以解决这个问题。

Scott Ambler也加入了交流，他提到，开源也是重用的一种形式，它已经取得了巨大成功。他同时也提到，代码库、开发工具包乃至mash-up这些都是软件重用的成功案例。

你怎么判断重用代码的时机?请留下你的宝贵意见。

查看英文原文：An Agile Approach to Code Reuse

篇7：安全代码开发：敏捷的牺牲者？

根据一项中小型企业的研究表明，敏捷团队并没有把安全当回事，即使是开发通过Web访问的系统。该研究引用说，

采访表明，小型和中型的敏捷软件开发组织不使用任何特定的方法来实现安全目标，即使当他们的软件是面向Web的，是潜在的攻击目标。这种情况下，研究证实即使在某些案例中安全是被明确要求的，安全设计作为实施团队的输入要求之一，最终的结果是否满足安全目标也没有保证。

Adrian Lane，也关注 敏捷方法开发软件风险的安全方面。 Adrian

关注功能的高效交付、以牺牲软件开发的安全为代价基于书本式的敏捷实施问题，并推动软件之外的安全确认与服务。

Rocky Heckman认为，像TDD和结对编程这样的技术， 主要还是聚焦在功能上。

测试的重点放在高质量代码与可靠的可重复性操作。很少或根本没有提及渗透式测试或威胁模型。

敏捷开发是否意味着完全无视安全？看起来也许有一些解决方法。

Jim Bird提出，通过一点点地提醒可能是一种渐进地解决这些风险的方法.

据Jim的观点，就像其他的质量提升实践那样，安全实践是要融入团队的意识中，

管理资料

团队可以使用增量受攻击面分析来监控系统的安全风险状况的变化，这可能是由于接口架构的改变导致的。

对于逐步构建软件并对代码非常熟悉的团队来说，威胁模型并没有想象的那么严重。大部分可在1周或2周的Sprint做完的变更并不大，而且可以增量的修改，不用花太多时间来评审，即使受攻击面被改变了。

Jim还提到了利用安全Sprint，微软称之为安全突击或“迷你安全推进”，在该sprint中，团队寻找现有代码的安全漏洞，然后再作出进一步的重大变更。Jim引用Adrian Lane的话，他提到，开发团队比客户更关注安全性。开发团队在其开发过程中应给予足够的重视并担负起责任。

即使一个强大的和善意的客户也不能被指望了解应用程序的安全问题，或如何构建安全的软件。他们自己的事情已经很多了。

因此，正确的措施和心态有可能把安全作为开发过程的一部分。

Jim说，

没有理由认为敏捷开发=安全故障。技术工作，对于质量和细节与构建安全软件的承诺是相同的，而不论团队采用什么样的开发方式。

篇8：敏捷开发软件模式初探

软件工程是用工程的思想设计并实现解决自然世界所需的软件系统的过程。传统的软件工程方法, 有瀑布模型、喷泉模型和螺旋模型等, 它们重视开发文档 (含程序) 的规范和结构的严谨与完整, 被广泛使用。然而需求的不确定性、难以描述和开发效率慢, 为软件需求分析阶段提出极大地挑战, 制约着软件设计发展。敏捷开发 (Agile Development) 方法作为一个快捷、高效的软件开发方式, 提高了传统软件开发方法的效率, 成为软件业界提倡的一种开发方法。

敏捷开发方法是轻量型的开发方法, 反对庞大的、万事巨细的重型传统方法, 重视与客户的交流, 并及时提供“样品模型”, 以便为所需的结果提供可参考的依据。敏捷开发方法往往为效率与质量之间做出平衡, 通过第三方构件或工具快速提供可参考的样品模型, 明确或满足客户的需求。

1 敏捷开发方法应用举例

软件开发人员使用敏捷开发思想, 借助于第三方软件可以轻松的构建出灵活的数据分析, 网络报表等应用系统, 大大缩短项目周期和减少实施成本。

Fine Report是一种普通的敏捷开发辅助工具, 是一款集数据展示 (报表) 、数据查询 (参数) 和数据录入 (填报) 功能于一身, 用来辅助开发基于B/S软件系统的报表软件。基于Fine Repore开发的软件系统可以使用于金融、能源、交通、财税和通信等各个行业, 并成功实施于上千家客户的信息化应用项目。基于敏捷开发的核心思想, Fine Report具有“专业数据处理、简捷方便、灵活无码”的特点, 仅需简单的拖拽操作便可以设计格式报表。

1.1 使用Fine Report快速开发一个查询

青岛高校信息有限公司自2007年与青岛工学院合作, 青岛工学院培养学生的同时, 中间件技术课程实践课上讲授青岛高校信息有限公司的常用第三方报表敏捷开发辅助工具Fine Report, 学生很快就进入企业, 胜任开发岗位。现结合本开发工具, 假设一个环境, 进行一个快捷开发。如果现在需要根据如表1所示的销售表结构结构, 设计一个基于B/S平台的销售查询页面, 无论使用最简单的HTML语言还是采用交互式动态页面JSP或ASP都需要花费很大的精力编写代码。

采用Java环境进行B/S系统开发, 需要数据库的同时, 还需要安装配置Java环境, 安装Tomcat作为Web服务器, 编写查询和结果等JSP页面等[7], 但通过敏捷开发工具进行平台的搭建和页面设计就非常简单。Fine Report6.0以上的版本安装后, 不仅具有了一个Web系统服务器, 还提供了一个可以连接Access、Oracle、My SQL或Ms SQL Server等DBMS系统软件的一个服务平台。设计查询界面只需在页面内拖拽一些中间件、点击设置属性和简单的代码 (甚至是无代码) 就可实现一个复杂的查询和报表样式 (如图1所示) 。

1.2 第三方工具的优点

敏捷开发采用第三方工具具有如下优点:首先为敏捷开发提供了技术和经验的支持, 为敏捷开发方法提供了简单的可行路线, 其次采用了迭代式增量开发经典的软件工程开发方法, 为敏捷开发方法积累更多的开发模版和演示的成果, 其三采用第三方工具进行敏捷开发减少了代码的编写, 提高了效率和减少了错误概率。

2 应用型本科教学中的实践

2.1 基于敏捷开发软件人才培养

用型本科高校区别于研究型高校和工程型高校, 它根据社会需求和结合自身实际, 主要培养企事业单位培养一线技术岗位急需的人才。近几年软件工程 (含计算机科学与技术) 人才就业较困难, 但仔细分析并非如此, 出现了“企业招不到合适的人才, 毕业生找不到合适的岗位”的怪圈。根据教育部高等学校计算机科学与技术专业教学指导分委员会在《中国计算机本科专业发展战略研究报告》中指出的“计算机类专业毕业生就业出现困难的主要原因, 不是数量太多或质量太差, 而是满足社会需要的针对性不够明确, 导致了结构上的不合理[9]”。2008年以来青岛工学院根据企业需要, 主动与企业结合进行软件工程人才培养, 为企业培养了人才, 提高了学生就业率。

青岛工学院借助民办本科高校办学自主权的优势与企业密切结合, 2008年和2013年两次人才培养方案修订时, 首先考察周边行业内的企业人才需求, 借助与青岛海信网络科技、青岛海尔软件, 以及青岛市软件园软件企业30多家合作的天然优势, 采取“请进来和走出去”的路线, 一方面把软件企业内的专家请进来为人才培养方案的制定献演献策, 保证培养的人才是企业所喜好的 (具备企业所需的技能) , 把企业的项目经理请进来, 进入到第二课堂和专家讲坛为学生传授一线岗位的实用技能;另一方软件教师走出去, 利用暑假去企业交流学习, 学生走出去, 在合作单位参观实习 (一年级) 、技术实习 (暑期实习) 、毕业实习 (四年级) 和毕业设计。

2.2 就敏捷开发与企业的合作

软件企业有着对优质的敏捷开发技术人员的需求, 青岛工学院在软件人才培养的过程中抓住这一关键点, 开展了与企业的多方位合作。学生在校园学习的同时与企业能够多次交流, 并通过参加外包项目和科研, 以及企业实习, 学习到企业的第三方敏捷开发辅助工具, 对就业和教师成果转化都有提高, 达到学校、企业、学生、教师四方共赢的效果。

3 结语

敏捷开发方法作为软件工程的主要方法之一, 具有高效、快捷的优点, 为应用型软件工程人才培养实践出一条可行的方向, 成为企业、学校、学生与教师四方共赢的方式, 具有同类高校的借鉴性。但在合作初期, 需要教师具有一定奉献精神, 不能急功近利, 需要企业具有很强的社会责任心;需要学校为敏捷开发合作人才培养具有一定的政策支持, 学生要有积极的参与热情, 否则合作互赢的敏捷开发人才培养模式也有很大的实践难度。

摘要：针对高效的软件工程开发方法之一, 敏捷开发能够克服软件危机的实际问题, 分析了敏捷开发的优点, 提出借助第三方工具进行报表设计和数据库查询的敏捷开发过程的, 阐述了应用型本科高校软件工程专业的企业、学校、学生、教师多方共赢的敏捷软件人才培养模式, 对软件工程专业培养方案进行了规划, 明确敏捷开发的多方合作关系等, 实践结果证明合作互赢的敏捷开发人才培养模式对提高软件人才就业和满足企业需求具有实际意义。

关键词：软件人才,敏捷开发,培养模式

参考文献

[1]杨芙清.浅论软件技术发展[J].电子学报, 2002.

[2]张海藩.软件工程导论.第四版[M].北京:清华大学出版社, 2009.

[3]刘家侨.论软件外包技术的开发[J].长春工业大学学报 (自然科学版) , 2008.

[4]彭志楠.敏捷开发在软件开发中的应用研究[D].电子科技大学, 2009.

[5]戴哲明, 顺卿, 王敬平.基于J2EE架构的敏捷开发平台[J].计算机工程, 2008.

[6]张嘉路等译.敏捷建模:极限编程和统一过程的有效实践[M].北京:机械工业出版社, 2003.

[7]吴晓义, 唐晓鸣.应用型本科高校的发展定位、指导思想与校本特色[J].高教探索, 2008.

[8]教育部计算机科学与技术专业教学指导分委员会[N].中国计算机本科专业发展战略研究报告, 2005.