第一篇：敏捷开发简介
敏捷开发简介
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
第二篇：敏捷开发与极限编程的简介（最终版）
敏捷开发与极限编程的简介
什么是敏捷开发？
一种以人为核心、迭代、循序渐进的开发方法。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。
通过这项工作，他们认为：
·个体和交互 胜过 过程和工具
·可以工作的软件 胜过 面面俱到的文档
·客户合作 胜过 合同谈判
·响应变化 胜过 遵循计划
并提出了以下遵循的原则：
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。
简单是最根本的。
最好的构架、需求和设计出于自组织团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
参看《敏捷开发横空出世》
极限编程（XP）是一种轻量级的软件开发方法论，XP从实践中来，是对实践的总结，也是经过实践检验的，其主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动精神。XP承诺降低软件项目风险，改善业务变化的反应能力，提高开发期间的生产力，为软件开发过程增加乐趣，相信这些足以吸引每个人的眼球。
在XP的项目开发中，首先引入了四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。
为了能成功地实施XP，XP制定四个准则：沟通、简单、反馈和勇气
和十二条原则：计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代码集体所有、持续集成、每周工作40小时、现场客户、编码标准
以及对开发人员的工作要求：编码、测试、倾听和设计。
XP是一个非常庞大的知识库，每一项都是一门值得深究的学问。提出这些要求和原则后，XP有提出了一系列的解决方案，也就是策略，其中包含：管理策略、设施策略、计划策略、开发策略、设计策略和测试策略。在真正去实现XP时，XP又提供了将策略成功应用的实践。可以说XP为你的软件开发的指导老师。XP是从实践中来的，应此有好多人围绕XP发表了一些自己的实践经验，其中主要包括：测试驱动开发、结队编程、重构和极限编程工具。
第三篇：敏捷开发个人体会和分享报告
敏捷开发个人体会和分享报告
敏捷开发，曾经对它的理解就是没有文档的快速开发，先做原型，针对原型面对面交流，按照大家认可的原型再做快速开发，多次的面对面讨论原型，不断迭代原型，针对每次迭代的原型进行快速开发。众所周知，写软件开发文档是每一个程序员都懒于做的事情，认为比较痛苦的事情，所以越来越多的人因为这点去使用敏捷开发。但是经过培训学习之后，我对敏捷开发有了一些新的理解。
首先，对敏捷开发下个定义，借用百度百科的定义。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
这个定义只从表面上解释了一下敏捷开发，没有具体说明怎样使用敏捷开发。下面讲一下我对敏捷开发的具体心得。
1、架构师的重要性
首先，敏捷开发对于个人能力的要求是十分高的，尤其是领导人的能力。领导者及架构师是个举足轻重的角色，需要眼观大图，并关注最终成果，这就要求领导者及架构师有深厚的行业背景、创新能力、以及架构能力。一个好的架构师，必须能考虑到产品当前使用模块、产品可以继续发展的模块以及下一代产品的方向。只有考虑到这三种模块和特性，这样的产品才能保持长期的生命力。敏捷开发也强调拥抱市场变化，这对产品架构师提出了更高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。
2、能够随时应对变化的结构，适应需求变化，并能驾驭需求变化 能够随时应对变化的结构，比遵循计划更重要。计划不要考虑太远，因为各种环境都在发生变化，随着软件的提交，需求也许会发生变化。完美的甘特图能够体现对项目的整体控制力，但是详细的甘特图也是不切合实际的。感觉一般做一周的计划，是最切合实际的。
3、尽早地、持续地交付有价值的软件来满足客户需求
经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品成果就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到可以交付的标准。
4、严格执行单元测试
所有编程人员都知道需要做单元测试，但是有多少人可以认真对待。很少人是真的想尽办法构建测试案例，大多数人都是应付了事。所以要认真对待单元测试，无单元测试的代码严禁提交。“Y23理论”教导我们不要忽视细小的错误，如果不把细小的错误消灭掉，它会给你带来毁灭性的重创。
5、每日站立会议，面对面交流
各团队成员的工作相对比较独立，对其它成员的工作了解不多，不利于整个项目的发展，每个成员容易歇入研究的死胡同。所以在团队内部，每日站立会议、面对面交流是最具有效果并且富有效率的传递信息的方法。每日站立会议要求每个人必须定点进入会议状态。每日会议前每个人要更新自己的任务面板。每日会议中决定要签出的任务，并在会议后更新任务面板，并在任务便签上注明任务的签出人。
6、关注成果，把工作按照重要性和紧急性进行分类，权衡工作重点 团队成员围绕“眼观大图，关注成果”这一导向，把自己的近期工作按照重要性和紧急性进行分类，分为四类：
1、重要、紧急
2、重要、不紧急
3、不重要、紧急
4、不重要、不紧急。根据四类情况对自己的近期工作进行权衡，把握工作重点，紧扣要事，使近期工作得以顺利开展，使远期工作也得以顺利进行。
现在社会工作的节奏越来越快，相信敏捷开发的使用者也越来越多。通过不断的对敏捷开发方法进行改善，我相信，以后不只那些中小型项目会使用敏捷开发，而且一些大的项目也会使用。总有一天，人们使用敏捷开发时会做到驾驭自如！
第四篇：用友UAP打造全周期开发平台 实现敏捷开发
用友UAP打造全周期开发平台 实现敏捷开发
为了解开用友UAP平台的面纱，了解更多平台技术，5月28日记者来到用友软件园，采访了用友集团UAP中心的两位专家，重点介绍了用友UAP的平台产品之一——开发平台所包含的组件及其特性，详细讲解了开发平台如何使得敏捷开发成为可能。
用友UAP平台诞生背景
中国软件行业正在经历第三次转型的阵痛，用友UAP伴随NC产品诞生，随着业务复杂度的提升，对页面交互、页面数据处理能力都提出了新的要求，这促使全新的用友UAP开发平台诞生。
用友UAP开发平台从不同类型的软件开发过程中，研究、分析、总结和提炼了大量的设计工具、开发工具、应用开发框架、中间件、基础技术类库以及研发模式等成果，并提供了一个集成的软件开发环境。
用友集团UAP中心Java应用平台开发部经理刘昆鹏表示，用友公司“平台化发展 产业链共赢”的策略，对如何有效利用和扩展研发成果，并在不同研发层次进行独立的资产管理和发展提出了要求。另一方面，随着软件工程的不断推进，整个开发过程的各个环节更加精细化，管理人员、需求人员、设计人员、开发测试等各开发人员都需要协同工作。所以将在开发过程中所产生的最佳实践达到有效的积累，也是开发平台要解决的问题。
用友集团UAP中心Java应用平台开发部经理 刘昆鹏
UAP开发平台的核心优势
用友集团UAP中心技术支持部总经理彭立东介绍，该平台包括了覆盖软件全生命周期的需求分析、设计、开发、测试、构造、发布、运行及维护等各阶段所需的工具。基于用友UAP开发平台能够大幅度提升软件的开发效率、稳定性、可集成性及可维护性，降低软件实现的技术难度以及开发成本。
用友集团UAP中心技术支持部总经理 彭立东
用友UAP开发平台由可视化集成开发环境、应用开发框架、公共服务以及基础技术类库/中间件几个部分组成，同时从开发过程角度提供了软件配置管理与研发管理功能。可视化集成开发环境UAP Studio支持业务建模、分析、设计、开发、测试、组装、发布等开发过程的全生命周期管理，提供各种管理工具、设计器、监控工具，以及软件配置管理系统。采用模型驱动开发的方式，通过上一阶段的输出与下一阶段的输入结合，利用可视化设计器将开发过程串接起来，大大降低开发难度，降低各阶段的鸿沟和不一致性。
用友UAP开发平台的“灵魂”
随后，彭立东先生向记者重点介绍了开发平台的“灵魂”——元数据。元数据框架支持访问服务、开发服务、管理服务，支持建模开发工具整合与适配其他系统模型数据，并提供统一的查询服务，使得平台上的开发者只需要关注业务逻辑，实现了业务与技术的分离。
开发平台的实体设计器包含多种建模元素和实体元素，可以可视化的方式创建面向对象的实体组件，可通过配置代码模板，自动产生可以直接运行的业务实体源代码。
业务与技术相分离
用友UAP开发平台的应用开发框架是基于企业建模理论的，将应用软件的业务逻辑和开发技术相分离，是应用软件开发者可以仅仅关注应用的业务逻辑，而不必关注繁琐的技术实现，使得管理层与业务人员参与应用软件的开发成为可能。大大缩短研发周期、提高研发效率、加快应用开发速度、减少企业信息系统开发的风险，并保证应用开发软件的质量，实现最终用户的个性化的需求。
除了支持开发WEB应用等常见的应用类型外，还支持开发跨平台移动应用。用友UAP移动应用框架提供了数据处理、应用适配器等功能，提供移动应用商店，开发者可以在上面发布自己的移动应用产品。
用友UAP平台产品的问世，能够支持我国大型企业及公共组织更好的实现IT及软件系统的运营与运维，提升管理绩效，并帮助客户参与全球化竞争。其开发平台将开发的全过程做为资产管理起来，大量的原数据模型和可视化界面大大降低开发的难度，实现了敏捷开发。
第五篇：(敏捷开发).NET性能优化方面的总结.docx
(敏捷开发).NET性能优化方面的总结
一、SqlDataRead和Dataset的选择
Sqldataread优点：读取数据非常快。如果对返回的数据不需做大量处理的情况下，建议使用SqlDataReader，其性能要比datset好很多。缺点：直到数据读完才可close掉于数据库的连接。(SqlDataReader读数据是快速向前的。SqlDataReader类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。它使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。DataReader需及时显式的close。可及时的释放对数据的连接。)
Dataset是把数据读出，缓存在内存中。缺点：对内存的占用较高。如果对返回的数据需做大量的处理用Dataset比较好些可以减少对数据库的连接操作。优点：只需连接一次就可close于数据库的连接。一般情况下,读取大量数据,对返回数据不做大量处理用SqlDataReader.对返回数据大量处理用datset比较合适.对SqlDataReader和Dataset的选择取决于程序功能的实现。
二、ExecuteNonQuery和ExecuteScalar 对数据的更新不需要返回结果集，建议使用ExecuteNonQuery。由于不返回结果集可省掉网络数据传输。它仅仅返回受影响的行数。如果只需更新数据用ExecuteNonQuery性能的开销比较小。
ExecuteScalar它只返回结果集中第一行的第一列。使用ExecuteScalar方法从数据库中检索单个值（例如id号）。与使用ExecuteReader方法，返回的数据执行生成单个值所需的操作相比，此操作需要的代码较少。
只需更新数据用ExecuteNonQuery.单个值的查询使用ExecuteScalar。数据绑定的选择
三、数据的绑定DataBinder 一般的绑定方法<%# DataBinder.Eval(Container.DataItem, “字段名”)%>用DataBinder.eval绑定不必关心数据来源(Dataread或dataset)。不必关心数据的类型eval会把这个数据对象转换为一个字符串。在底层绑定做了很多工作，使用了反射性能。正因为使用方便了，但却影响了数据性能。来看下<%# DataBinder.Eval(Container.DataItem, “字段名”)%>。当于dataset绑定时，DataItem其实式一个DataRowView（如果绑定的是一个数据读取器（dataread）它就是一个IdataRecord。）因此直接转换成DataRowView的话，将会给性能带来很大提升。.<%# ctype(Container.DataItem,DataRowView).Row(“字段名”)%> 对数据的绑定建议使用<%# ctype(Container.DataItem,DataRowView).Row(“字段名”)%>。数据量大的时候可提高几百倍的速度。使用时注意2方面：1.需在页面添加<%@ Import namespace=“System.Data”%>.2.注意字段名的大小写（要特别注意）。如果和查询的不一致，在某些情况下会导致比<%# DataBinder.Eval(Container.DataItem, “字段名”)%>还要慢。如果想进一步提高速度，可采用<%# ctype(Container.DataItem,DataRowView).Row(0)%>的方法。不过其可读性不高。以上的是vb.net的写法。在c#中：<@%((DataRowView)Container.DataItem)[“字段名”] %>
一、应用Ado.net的一些思考原则 1.根据数据使用的方式来设计数据访问层 2.缓存数据，避免不必要的操作 3.使用服务帐户进行连接 4.必要时申请，尽早释放 5.关闭可关闭的资源 6.减少往返
7.仅返回需要的数据 8.选择适当的事务类型 9.使用存储过程
二、Connection
数据库连接是一种共享资源，并且打开和关闭的开销较大。Ado.net默认启用了连接池机制，关闭连接不会真的关闭物理连接，而只是把连接放回到连接池中。因为池中共享的连接资源始终是有限的，如果在使用连接后不尽快关闭连接，那么就有可能导致申请连接的线程被阻塞住，影响整个系统的性能表现。
1、在方法中打开和关闭连接 这个原则有几层含义：
1）主要目的是为了做到必要时申请和尽早释放
2）不要在类的构造函数中打开连接、在析构函数中释放连接。因为这将依赖于垃圾回收，而垃圾回收只受内存影响，回收时机不定
3）不要在方法之间传递连接，这往往导致连接保持打开的时间过长 这里强调一下在方法之间传递连接的危害：曾经在压力测试中遇到过一个测试案例，当增大用户数的时候，这个案例要比别 的案例早很久就用掉连接池中的所有连接。经分析，就是因为A方法把一个打开的连接传递到了B方法，而B方法又调用了一个
自行打开和关闭连接的C方法。在A方法的整个运行期间，它至少需要占用两条连接才能够成功工作，并且其中的一条连接占用时间还特别长，所以造成连接池资源紧张，影响了整个系统的可伸缩性！
2、显式关闭连接
Connection对象本身在垃圾回收时可以被关闭，而依赖垃圾回收是很不好的策略。推荐使用using语句显式关闭连接，如下例：
using(SqlConnection conn = newSqlConnection(connString)){ conn.Open();} // Dispose is automatically called on the conn variable here
3、确保连接池启用
Ado.net是为每个不同的连接串建立连接池，因此应该确保连接串不会出现与具体用户相关的信息。另外，要注意连接串是 大小写敏感的。
4、不要缓存连接
例如，把连接缓存到Session或Application中。在启用连接池的情况下，这种做法没有任何意义。
三、Command
1、使用ExecuteScalar和ExecuteNonQuery 如果想返回像Count(*)、Sum(Price)或Avg(Quantity)那样的单值，可以使用ExecuteScalar方法。ExecuteScalar返回第一行第一列的值，将结果集作为标量值返回。因为单独一步就能完成，所以ExecuteScalar不仅简化了代码，还提高了性能。
使用不返回行的SQL语句时，例如修改数据（INSERT、UPDATE或DELETE）或仅返回输出参数或返回值，请使用ExecuteNonQuery。这避免了用于创建空DataReader的任何不必要处理。
2、使用Prepare 当需要重复执行同一SQL语句多次，可考虑使用Prepare方法提升效率。需要注意的是，如果只是执行一次或两次，则完全没有必要。例如： cmd.CommandText = “insert into Table1(Col1, Col2)values(@val1, @val2)”;cmd.Parameters.Add(“@val1”, SqlDbType.Int, 4, “Col1”);cms.Parameters.Add(“@val2”, SqlDbType.NChar, 50, “Col2”);cmd.Parameters[0].Value = 1;cmd.Parameters[1].Value = “XXX”;cmd.Prepare();cmd.ExecuteNonQuery();cmd.Parameters[0].Value = 2;cmd.Parameters[1].Value = “YYY”;cmd.ExecuteNonQuery();cmd.Parameters[0].Value = 3;cmd.Parameters[1].Value = “ZZZ”;cmd.ExecuteNonQuery();
3、使用绑定变量
SQL语句需要先被编译成执行计划，然后再执行。如果使用绑定变量的方式，那么这个执行计划就可以被后续执行的SQL语句所复用。而如果直接把参数合并到了SQL语句中，由于参数值千变万化，执行计划就难以被复用了。例如上面Prepare一节给出的示例，如果把参数值直接写到insert语句中，那么上面的四次调用将需要编译四次执行计划。
为避免这种情况造成性能损失，要求一律使用绑定变量方式。
四、DataReader DataReader最适合于访问只读的单向数据集。与DataSet不同，数据集并不全部在内存中，而是随不断发出的read请求，一旦发现数据缓冲区中的数据均被读取，则从数据源传输一个数据缓冲区大小的数据块过来。另外，DataReader保持连接，DataSet则与连接断开。
1、显式关闭DataReader 与连接类似，也需要显式关闭DataReader。另外，如果与DataReader关联的Connection仅为DataReader服务的话，可考虑使用Command对象的ExecuteReader(CommandBehavior.CloseConnection)方式。这可以保证当DataReader关闭时，同时自动关闭Connection。
2、用索引号访问代替名称索引号访问属性
从Row中访问某列属性，使用索引号的方式比使用名称方式有细微提高。如果会被频繁调用，例如在循环中，那么可考虑此类优化。示例如下：
cmd.CommandText = “select Col1, Col2 from Table1”;SqlDataReaderdr = cmd.ExecuteReader();int col1 = dr.GetOrdinal(“Col1”);int col2 = dr.GetOrdinal(“Col2”);while(dr.Read()){ Console.WriteLine(dr[col1] + “_” + dr[col2]);}
3、使用类型化方法访问属性
从Row中访问某列属性，用GetString、GetInt32这种显式指明类型的方法，其效率较通用的GetValue方法有细微提高，因为不需要做类型转换。
4、使用多数据集
部分场景可以考虑一次返回多数据集来降低网络交互次数，提升效率。示例如下：
cmd.CommandText = “StoredProcedureName”;// The stored procedure returns multiple result sets.SqlDataReaderdr = cmd.ExecuteReader();while(dr.read())// read first result setdr.NextResult();while(dr.read())
五、DataSet
1、利用索引加快查找行的效率
如果需要反复查找行，建议增加索引。有两种方式： 1）设置DataTable的PrimaryKey 适用于按PrimaryKey查找行的情况。注意此时应调用DataTable.Rows.Find方法，一般惯用的Select方法不能利用索引。2）使用DataView 适用于按Non-PrimaryKey查找行的情况。可为DataTable创建一个DataView，并通过SortOrder参数指示建立索引。此后使用Find或FindRows查找行。
一、减少往返行程（Reduce Round Trips）
使用下面的方法可以减少Web服务器和Browser之间的往返行程：
1、为Browser启用缓存
如果呈现的内容是静态的或变化周期较长，应启用Browser缓存，避免发出冗余的http请求。
2、缓冲页面输出
如果可能，则尽量缓冲页面输出，处理结束后再一次传送到客户端，这可以避免频繁传递小块内容所造成的多次网络交互。由于这种方式在页面处理结束之前客户端无法看到页面内容，因此如果一个页面的尺寸较大的话，可考虑使用Response.Flush方法。该方法强制输出迄今为止在缓冲区中的内容，你应当采用合理的算法控制调用Response.Flush方法的次数。
3、使用Server.Transfer重定向请求
使用Server.Transfer方法重定向请求优于Response.Redirect方法。原因是Response.Redirect会向Broswer回送一个响应头，在响应头中指出重定向的URL，之后Brower使用新的URL重新发出请求。而Server.Transfer方法直接是一个简单的服务端调用，完全没有这些开销！需要注意Server.Transfer有局限性：第一，它会跳过安全检查；第二，只适用于在同一Web应用内的页面间跳转。
二、避免阻塞和长时间的作业
如果需要运行阻塞或长时间运行的操作，可以考虑使用异步调用的机制，以便Web服务器能够继续处理其它的请求。
1、使用异步方式调用Web服务和远程对象
只要有可能就要避免在请求的处理过程中对Web服务和远程对象的同步调用，因为它占用的是的ASP.NET 线程池中的工作线程，这将直接影响Web服务器响应其它请求的能力。
2、考虑给不需要返回值的Web方法或远程对象的方法添加OneWay属性
这种模式能让Web Server调用之后就立即返回。可根据实际情况决定是否使用这种方法。
3、使用工作队列
将作业提交到服务器上的工作队列中。客户端通过发送请求来轮询作业的执行结果。
三、使用缓存
缓存能在很大程度上决定ASP.NET应用的最终性能。Asp.net支持页面输出缓存和页面部分缓存，并提供Cache API，供应用程序缓存自己的数据。是否使用缓存可考虑下面的要点：
1、识别创建与访问代价较大的数据
2、评估需要缓存数据的易变性
3、评估数据的使用频次
4、将要缓存数据中易变数据和不变数据分离，只缓存不变数据
5、选择合适的缓存机制（除Asp.net Cache外，Application state和Session state也可以作为缓存使用）
四、多线程
1、避免在请求处理过程中创建线程
在执行请求的过程中创建线程是一种代价较大的操作，会严重影响Web Server的性能。如果后续的操作必须用线程完成，建议通过thread pool来创建/管理线程。
2、不要依赖线程数据槽或线程静态变量
由于执行请求的线程是ASP.NET thread pool中的工作线程，同一个Client的两次请求不一定由相同的线程来处理。
3、避免阻塞处理请求的线程
4、避免异步调用
这和1的情况类似。异步调用会导致创建新的线程，增加服务器的负担。所以，如果没有并发的作业要执行，就不要执行异步调用。
五、系统资源
1、考虑实现资源池以提升性能
2、明确地调用Dispose或Close释放系统资源
3、不要缓存或长时间占用资源池中的资源
4、尽可能晚的申请，尽可能早的释放
六、页面处理
1、尽量减小Page的尺寸
包括缩短控件的名称、CSS的class的名称、去掉无谓空行和空格、禁用不需要的ViewState
2、启用页面输出的缓冲区（Buffer）
如果Buffer的机制被关闭，可以用下面的方法打开。使用程序打开页面输出缓存： Response.BufferOutput = true;使用@Page开关打开页面输出缓冲机制： <%@ Page Buffer = “true” %> 使用Web.config或Machine.config配置文件的
节点：
3、利用Page.IsPostBack优化页面输出
4、通过分离页面的不同的内容，来提高缓存效率和减少呈现的时间
5、优化复杂和代价较大的循环
6、合理利用客户端的计算资源，将一些操作转移到客户端进行
七、ViewState ViewState是Asp.net为服务端控件在页面回传之间跟踪状态信息而设计的一种机制。1.关闭ViewState 如果不需要跟踪页面状态，例如页面不会回传（PostBack）、不需要处理服务端控件事件或者每次页面刷新时都会重新计算控件内容，那么就不需要用ViewState来记录页面状态了。可以对特定的WebControl设置EnableViewState属性，也可以在页面一级设置： <%@ Page EnableViewState=“false” %>
2、在恰当的时间点初始化控件属性
ASP.NET的控件在执行构造函数、初始化的期间设置的属性不会被跟踪变化；而在初始化阶段之后对属性的修改都会被跟踪，并最终记录到IE页面的__VIEWSTATE之中。所以，选择合理的初始化控件属性的执行点，能有效的减小页面尺寸。
3、谨慎选择放到ViewState中的内容
放到ViewState中的内容会被序列化/反序列化，Asp.net为String、Integer、Boolean等基本类型的序列化做了优化，如果Array、ArrayList、HashTable存储的是基本类型效率也较高，但其它类型则需要提供类型转换器（Type Converter），否则将使用代价昂贵的二进制序列化程序。
点击咨询 