敏捷开发概念及实践ppt课件.pptx

目录,敏捷开发历史软件开发模式介绍软件生命周期模式敏捷开发介绍敏捷开发-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等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟,为什么要敏捷开发-项目为什么失败,为什么要敏捷开发-软件工程应用现状,为什么要敏捷开发-需要敏捷的理由,软件开发模式介绍,软件生命周期-同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、 -衰亡等阶段，这一般称为软件生命周期。-软件开发生命周期(SDLC)是指软件开发的全部过程、活动和任务的结构框架。SDLC的一般步骤包括：确定问题、可行性分析与开发计划、收集需求、分析与设计、编码开发、测试、安装、维护。软件生命周期模式典型的几种生命周期模式包括：瀑布模式、演化模式、螺旋模式、快速原型模式、喷泉模式和混合模式等。在这里只介绍其中最常用的几种模式：,软件生命周期模式,瀑布式它首先是由Royce提出，该模式由于酷似瀑布闻名。在该模式中首先确定需求，然后拟定规格说明，在通过验证后方可进入计划阶段。因此，瀑布模式中至关重要的一点是只有当一个阶段的文档获得认可才可以进入下一个阶段。瀑布模式通过强制性规约来确保每个阶段都能很好的完成任务，但是实际上却往往难以办到。因为整个瀑布模式几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模式有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。演化模式它主要是针对事先不能完整定义需求的软件开发。它的方法是用户先给出待开发系统的核心需求，并且在核心需求实现后，再提出反馈以支持系统的最终设计和实现。也就是说：开发人员首先会根据用户的需求开发核心系统，然后提供给用户试用；用户试用后再提出增强系统能力的需求；最后开发人员再根据用户的反馈，实施迭代开发。实际上，这个模式可看作是重复执行的多个瀑布模式。演化模式要求开发人员把项目的产品需求分解为不同组，以便分批循环开发。但这种分组并不是随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。,软件生命周期模式,螺旋模式：它是瀑布模式与演化模式相结合，并加入两者所忽略的风险分析所建立的一种软件开发模式。螺旋模式基本的做法是在瀑布模式的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被暂停。另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员还可作出决定让余下的开发工作采用另外的生命周期模式，如演化模式，瀑布模式或自定的混合模式。过程开发模式：它又叫混合模式或元模式，是指把几种不同模式组合成一种混合模式，它允许一个项目能沿着最有效的路径发展。因为上述的模式中都有自己独特的思想，现在的软件开发团队中很少说标准的采用那一种模式的，因为模式和实际应用还是有很大的区别的。实际上，许多软件开发团队都是在使用几种不同的开发方法组成他们自己的混合模式。,软件生命周期模式-总结,最后，我们来总结一下。螺旋模式是典型的迭代式生命周期模式，而RUP则是近代迭代式生命周期的代表。与螺旋模式相比，RUP将风险管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驱动架构（MDA）和敏捷（Agile）软件开发。MDA模式是基于可执行规格说明的思想，是现代转换模式的代表，其核心技术是组件技术。而敏捷开发生命周期的典型代表是XP编程，是把传统的系统设计和实现由敏捷软件开发过程中的验收测试、重构和测试驱动所取代；把传统的集成和部署由敏捷软件开发中的持续集成和短周期所取代。其实上，无论是瀑布开发模式还是螺旋开发模式，软件生命周期模式的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够管理和控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查，这就是软件开发模式产生的起因。它们体现了人们对软件过程的一个希望：严格控制、确保质量。,敏捷开发介绍,敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等,XP -eXtreme Programing极限编程:思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。SCRUM：是一种迭代的增量化过程，用于产品开发或工作管理 。水晶方法Crystal:由Alistair Cockburn在1990年代末提出。把不同类型的项目采用不同的方法。 FDD特性驱动 Feature Driven Development，由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。 DSDM-Dynamic System Development Methodology，它倡导以业务为核心，快速而有效地进行系统开发， 在英国等欧洲国家比较流行。ASD-Adaptive Software Development，由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive）,敏捷开发介绍,敏捷开发的特点,敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。很多方法很难独立的使用。如:测试驱动的开发，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。使用这些方法并不能保证一定成功。开发者的经验和技术仍旧是影响开发结果的最主要因素。对于合适的人，基于敏捷原则的开发方法可以产生更好的结果，同时形成一个愉快地、有激情的工作环境,敏捷模式理念,最高目标是能持续地、及早地向客户交付软件；拥抱变化；频繁地发布可运行的软件；客户和开发人员在一起工作；以人为本；最重要的衡量开发过程的手段，是可工作的软件；稳定的开发速度；敏捷高效的设计；简单有效；重视Teamwork；积极的调整。,敏捷开发介绍-极限编程XP,主要目的是降低需求变化的成本定义了一套简单的开发流程包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测试，验收测试等等提倡互动交流、反馈、简单、勇气、团队核心做法：小规模，频繁的版本发布，短迭代周期。测试驱动开发（Test-driven development）。结对编程（Pair programming）。持续集成（Continuous integration）。每日站立会议（Daily stand-up meeting）。共同拥有代码Collative code ownership.系统隐喻（System metaphor）。,敏捷开发介绍-精益,精益开发起源从丰田公司的产品开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原则，另外一部分由一些在相应的工具构成。核心思想查明和消除浪费。在软件开发过程中，错误（bugs），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法消除。精益开发的原则包括:强调学习。不断改进所开发的产品和开发效率。在最后时刻做决定。避免在可能改变的事情上做无谓的努力，避免浪费。用最快的速度交付用户。缩短迭代周期加速开发及交付，加快交流，提高生产力给团队自主权。激励团队并让团队成员自我管理-敏捷方法成功的基本因素之一。诚信。确保系统正常工作，客户需求是团队努力坚持的诚信和对用户的承诺。全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品， 从整体上考虑优化比从各个局部去优化更高效。 精益软件更重要的是不断完善开发过程的一种思维方式。,SCRUM 开发流程是 Agile Process 的一种，以英式橄榄球争球队形 (Scrum) 为名，基本假设是开发软件就像开发新产品，无法一开始就能定义 Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。 Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，碓保每天、每个阶段都朝向目标有明确的推进，因此 SCRUM 非常适用于产品开发项目。,敏捷开发介绍-scrum,敏捷开发介绍-scrum,SCRUM 开发流程通常以 30 天为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排 .SCRUM较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。,敏捷开发介绍-scrum,SCRUM是一个敏捷开发框架它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。Scrum定义了4种主要的角色：1、产品拥有者（Product Owner）：该角色负责产品的远景规划，平衡所有利益相关者（stakeholder）的利益，确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。2、利益相关者（Stakeholder）：该角色与产品之间有直接或间接的利益关系，通常是客户或最终用户代表。他们负责收集编写产品需求，审查项目成果等。3、Scrum专家（Scrum Master）：Scrum专家负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。 4、团队成员（Team Member）：即项目开发人员。,SCRUM体系概览,十二条惯例和规则,On-Site Customer （现场客户）计划项目 （Planning Game）频繁地小规模发布软件 （Small Releases）简单设计 （Simple Design）测试驱动开发 （Test Driven Development）持续集成 （Continuous Integration）,集体拥有代码 （Collective Code Ownership）编程规范 （Coding Standards）重构 （Refactoring）System Metaphor （系统隐喻）Pair Programming （结对编程）平稳的工作效率 （Sustainable Pace）,敏捷开发-SCRUM名词解释,backlog：可以预知的所有任务，包括功能性的和非功能性的所有任务。sprint：一次跌代开发的时间周期，一般最多以30天为一个周期。在这段时间内，开发团队需要完成一个制定的backlog，并且最终成果是一个增量的，可以交付的产品。sprint backlog：一个sprint周期内所需要完成的任务。scrumMaster：负责监督整个Scrum进程，修订计划的一个团队成员。time-box：一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。,敏捷开发-SCRUM名词解释,sprint planning meeting：在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块，决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？遇到了障碍无法继续下去？明天要做什么？通过该会议，团队成员可以相互了解项目进度。Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。,敏捷开发-实施Scrum的过程介绍,确定Sprint Backlog将整个产品的backlog分解成Sprint Backlog，这个Sprint Backlog是按照目前的人力物力条件可以完成的。召开sprint planning meeting划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。sprint开发周期进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。成果演示 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner。回顾团队成员最后召开Sprint retrospective meeting，总结问题和经验。下一次Sprint。,敏捷开发,每日会议：目的：信息同步平台，非交流问题、讨论问题渠道。形式：固定地点、时间的站立会议。生产率估算燃尽线,敏捷开发原则和方法,迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。,敏捷实践原则,1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。有统计数字表明，越早、越频繁地向用户交付软件，软件的质量就越好。,敏捷实践原则,2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。使用敏捷过程的开发组织欢迎需求的变化，因为他们认为需求变化可以让他们更多地了解市场。敏捷开发组织采用各种方法和技术，使软件的结构高度灵活，需求的变化对系统的影响被最小化。,3.经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。敏捷开发组织不满足于交付文档和计划，他们的目标是频繁地交付可以工作的软件，从而满足客户的需要。,敏捷实践原则,4.整个项目开发期间，业务人员和开发人员必须天天都在一起工作。,敏捷实践原则,5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。在一个敏捷项目中，人员被认为是最重要的因素，其它所有因素（过程、环境、管理等）都被认为是次要的，当这些因素对人员造成不利影响时，就必须对其做出改变。例如，如果某些过程步骤对团队人员来说是个障碍，那么过程就必须改变。,敏捷实践原则,6.在团队内部，最有效率和最有效果的信息传达方式就是面对面的交流。,在敏捷项目中，默认的交流方式就是交谈，而不是文档。文档在必要的时候会被创建，但不会试图用文档来捕获所有项目信息。,敏捷实践原则,7.可以工作的软件是进度的主要度量标准。对于敏捷项目来说，进度的度量标准是当前可满足用户需求的软件的量，而不是当前项目所处的阶段、文档数量或基础代码的数量。项目完成了30%的含义是用户所需功能的30%已被实现。,8.敏捷过程提倡可持续开发。出资人、开发者和用户应该共同维持一个稳定的开发速度。敏捷小组会在整个项目开发期间保持一个适当的、可持续的开发速度，从而维持最高的质量标准。敏捷项目不会使开发者感到疲惫不堪。,敏捷实践原则,9.对卓越技术和良好设计的不断追求有助于提高敏捷性。敏捷开发团队认为提高质量会加快开发进度。因此要保持软件的精简和健壮。敏捷开发团队的每个成员都要致力于开发高质量的代码，不能把混乱的、底质量的代码留到以后去修改。,10.简单尽量减少工作量的艺术是至关重要的。敏捷开发方法总是选择达到目标的最简单途径。敏捷开发团队并不花费大量精力去预防将来可能出现的问题，而是专注于对当前工作采用最简单、最高质量的解决方案，并相信将来如果问题出现，可以很方便地进行修改。,敏捷实践原则,11.最好的架构、需求和设计都出自于自组织的团队。敏捷开发团队是自组织的团队。职责并非是从团队外部加给每一个团队成员，而是团队作为一个整体接受职责并自己决定怎样去完成它。,12.每隔一定时间，团队都要总结怎样更有效率地工作，然后相应地调整自己的行为。敏捷开发团队认识到环境在不断地改变，因此团队也需要不断地对组织、规则、惯例和各种关系进行调整，以保持自身的敏捷性。,敏捷开发宣言,极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。2001年，17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式，用来替代以文档驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。敏捷软件开发宣言内容： 个体和交互胜过过程和工具可以工作的软件胜过面面具到的文档可户合作胜过合同谈判响应变化胜过遵循计划,敏捷项目的关键,布置环境,既有无隔墙隔板的工作场地，也又单独的工作间；一个足够宽敞的地方供大家开会；足够大的白板；足够长的电脑桌，可以让两个人并排坐在同一台电脑前面；每一个人都能很容易地看到其他人并和他们交流。一些白纸或者卡片。更理想的条件：POP电视机Video Game落地玻璃窗,启动开发,最佳实践-管理,发布(Release)：每一期开发结束时提交给用户的一个可运行的系统。迭代(Iteration)：一期开发过程中的一个开发周期。它有明确的目标，计划和实现方式，它包含了需求分析、设计、编程、测试等完整的开发过程。一个迭代的长度为1到3 周。在一期开发过程中，所有迭代的长度是相同的，比如都是3周。小发布(Small Release)：处于开发中的系统，每集成一个新功能，都可以称为一个小发布。理想开发时间：估计完成一项工作所需的持续工作时间，不考虑意外因素。,最佳实践-需求,SPIKE：对不确定的需求和设计等，通过写一些程序、进行详细设计或者演算等等方式做探测和尝试，以确定可行性。这些探测过程称为SPIKE。User Story：是对用户的一个需求的一段简洁清晰的描述，该段描述有三个属性，即商业优先级、开发时间和风险。从某个角度看，XP过程是面向User Story的。故事卡：用户把User Story的内容和属性写在一张卡片上，该卡片即故事卡。例，MSDN中的例子Island Hopper News： (1) 客户浏览分类广告；(2) 客户发布分类广告；,最佳实践-设计,1. CRC： Class Responsibility Collaboration。1989年， Kent Beck和Ward Cunningham提出的OO分析和设计方法，现在得到了广泛应用。Responsibility：Class的行为。Collaboration： Class之间的相互联系和作用；Collaborator指和某行为(Responsibility)相关的Class。可以在卡正面加上父类名，子类名；可以在卡背后加上属性。,最佳实践-设计,2. Engineering Task：Team一起分析设计一个User Story，把该Story要完成的事情分解，就形成了一些任务(Engineering Tasks)。这些任务要足够小，以至于每个程序员都非常清楚要做什么，并能估计出完成该任务所需要的理想开发天。每个程序员挑选了一个Task后，就成为该Task的Owner，并估计完成该Task所需的理想开发天数。Task的粒度由理想开发天限制，大于1天且小于3天。从某个角度看，程序员的工作安排是面向Task的。3. Task卡：Task的内容、Owner和理想开发天都记录在一张Task卡上。例： 上个例子中每个CRC卡可以做为一个单独的任务被承担和估计。,敏捷开发的误区,不适合敏捷开发的情况,不能接受XP 文化的组织 中大型（超过10 个人）的团队 需要很长的编译或测试周期的系统 不太容易测试的应用 人员异地分布的物理环境 XP 侧重于具体的过程和开发技术，而CMM 更关注组织和管理上的问题 XP 缺少的一个重要内容是制度化 “institutionalization”,