敏捷开发概念及实践PPT课件.pptVIP

敏捷开发原则和方法 迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。 增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。 敏捷实践原则 1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 有统计数字表明，越早、越频繁地向用户交付软件，软件的质量就越好。 敏捷实践原则 2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 使用敏捷过程的开发组织欢迎需求的变化，因为他们认为需求变化可以让他们更多地了解市场。 敏捷开发组织采用各种方法和技术，使软件的结构高度灵活，需求的变化对系统的影响被最小化。 3.经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 敏捷开发组织不满足于交付文档和计划，他们的目标是频繁地交付可以工作的软件，从而满足客户的需要。 敏捷实践原则 4.整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 敏捷实践原则 5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 在一个敏捷项目中，人员被认为是最重要的因素，其它所有因素（过程、环境、管理等）都被认为是次要的，当这些因素对人员造成不利影响时，就必须对其做出改变。 例如，如果某些过程步骤对团队人员来说是个障碍，那么过程就必须改变。 敏捷实践原则 6.在团队内部，最有效率和最有效果的信息传达方式就是面对面的交流。 在敏捷项目中，默认的交流方式就是交谈，而不是文档。文档在必要的时候会被创建，但不会试图用文档来捕获所有项目信息。 敏捷实践原则 7.可以工作的软件是进度的主要度量标准。 对于敏捷项目来说，进度的度量标准是当前可满足用户需求的软件的量，而不是当前项目所处的阶段、文档数量或基础代码的数量。 项目完成了30%的含义是用户所需功能的30%已被实现。 8.敏捷过程提倡可持续开发。出资人、开发者和用户应该共同维持一个稳定的开发速度。 敏捷小组会在整个项目开发期间保持一个适当的、可持续的开发速度，从而维持最高的质量标准。敏捷项目不会使开发者感到疲惫不堪。 * * -*- -*- 目录 敏捷开发历史 软件开发模式介绍 软件生命周期模式 敏捷开发介绍 敏捷开发-SCRUM名词解释 敏捷开发-实施Scrum的过程介绍 敏捷开发-原则和方法 敏捷开发-宣言 敏捷开发-最佳实践 敏捷开发历史 敏捷开发并不现代 起源于20世纪30年代的一些项目（美国航天局水星计划） 最早记载使用在20世纪70年代 最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。 在1976年，第一部阐述敏捷方法的书籍 Tom Gilb在他的著作《软件度量》（“Software Metrics”）一书中阐述了他的迭代和增量开发实践 20世纪80年代正式定义迭代开发螺旋模型 20世纪80年代在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型 敏捷开发历史 美国国防部的项目审查早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。 20世纪90年代推荐使用迭代和增量开发的出版物和文献显著增加 2001年二月敏捷开发宣言后形成敏捷联盟 一组由17位在DSDM，XP，Scrum，FSD等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟 为什么要敏捷开发-项目为什么失败 项目为什么失败？ 软件工程试图解决这些问题： 对用户需求理解得不清楚，甚至有错误； 用户需求变化； 软件很难维护或扩展； 在项目后期阶段发现很严重的设计