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

《敏捷开发概念及实践ppt课件.pptx》由会员分享，可在线阅读，更多相关《敏捷开发概念及实践ppt课件.pptx（44页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、目录 敏捷开发历史 软件开发模式介绍 软件生命周期模式 敏捷开发介绍 敏捷开发-SCRUM名词解释 敏捷开发-实施实施Scrum的过程介绍的过程介绍 敏捷开发-原则和方法 敏捷开发-宣言 敏捷开发-最佳实践敏捷开发历史l敏捷开发并不现代敏捷开发并不现代起源于20世纪30年代的一些项目（美国航天局水星计划）l最早记载使用在最早记载使用在20世纪世纪70年代年代最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。l在在1976年，第一部阐述敏捷方法的书籍年，第一部阐述敏捷方法的书籍Tom Gilb在他的著作软件

2、度量（“Software Metrics”）一书中阐述了他的迭代和增量开发实践l20世纪世纪80年代正式定义迭代开发螺旋模型年代正式定义迭代开发螺旋模型20世纪80年代在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型敏捷开发历史美国国防部的项目审查早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。l20世纪世纪90年代推荐使用迭代和增量开发的出版年代推荐使用迭代和增量开发的出版物和文献显著增加物和文献显著增加l2001年二月敏捷开发宣言后形成敏捷联盟年二月敏捷开发宣言后形成敏捷联

3、盟一组由17位在DSDM，XP，Scrum，FSD等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟为什么要敏捷开发-项目为什么失败项目为什么失败？软件工程试图解决这些问题：1)对用户需求理解得不清楚，甚至有错误；2)用户需求变化；3)软件很难维护或扩展；4)在项目后期阶段发现很严重的设计缺陷；5)软件质量或性能不合格；6)Test - Build - Release过程的可操作性、可维护性很差；7)人员流动；1)为了规范化开发过程，引进传统工程的概念（瀑布型）；2)为了理解需求，提出原型法；

4、3)为了提高设计开发的效率和扩展性，提出重用和面向对象等思想；4)为了让开发过程更灵活，提出了开发框架的概念；5)为了降低风险，提出了风险评估、成本控制和增量开发等思想；为什么要敏捷开发-软件工程应用现状软件工程的应用现状：“特色”问题还是难以解决：1)国内因为资源限制，软件工程的实施流于形式；2)国内软件工程的研究及推广工作，和实践脱钩；3)旧的软件工程方法一直不能有效地支持变化。4)在北美，虽然软件工程提高了项目成功率，但耗费巨大资源；5)以前的软件工程方法无法摆脱传统工程方法的束缚。1)需求难以量化；2)软件从开发到维护及扩展，需求都有可能发生大变化；3)编程对设计的反馈非常重要；4)项

5、目中的设计可能会经常变化；5)代码的可读性和可维护性； 为什么要敏捷开发-需要敏捷的理由需要敏捷的理由部门培养团队合作精神，稳定开发队伍；提高开发人员的水平；提高项目成功率，降低开发成本，提升软件开发效率项目经理 更好地和用户沟通，更清晰地理解用户需求；更充分地使用资源，更科学地调配资源，更精确地掌握开发进度。系统分析 设计更加完善；更有效地更新知识，得到其他成员更多的尊重。程序员学习系统设计和项目管理；提高学习和工作效率，受到重视，减少加班时间，工作更高效软件开发模式介绍l软件生命周期软件生命周期-同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、 -衰亡等阶段，这一般称

6、为软件生命周期。-软件开发生命周期(SDLC)是指软件开发的全部过程、活动和任务的结构框架。- SDLC的一般步骤包括：确定问题、可行性分析与开发计划、收集需求、分析与设计、编码开发、测试、安装、维护。l软件生命周期模式软件生命周期模式典型的几种生命周期模式包括：瀑布模式、演化模式、螺旋模式、快速原型模式、喷泉模式和混合模式等。在这里只介绍其中最常用的几种模式：软件生命周期模式l瀑布式瀑布式它首先是由Royce提出，该模式由于酷似瀑布闻名。在该模式中首先确定需求，然后拟定规格说明，在通过验证后方可进入计划阶段。因此，瀑布模式中至关重要的一点是只有当一个阶段的文档获得认可才可以进入下一个阶段只有

7、当一个阶段的文档获得认可才可以进入下一个阶段。瀑布模式通过强制性规约来确保每个阶段都能很好的完成任务，但是实际上却往往难以办到。因为整个瀑布模式几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模式有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。l演化模式演化模式 它主要是针对事先不能完整定义需求的软件开发。它的方法是用户先给出待开发系统的核心需求核心需求，并且在核心需求实现后，再提出反馈以支持系统的最终设计和实现。也就是说：开发人员首先会根据用户的需求开发核心系统，然后提供给用户试用；用户试用后再提出增强系统能力的需求；最后开发人员再根据用户的反馈，实施迭代开发

8、。实际上，这个模式可看作是重复执行的多个瀑布模式。演化模式要求开发人员把项目的产品需求分解为不同组，以便分批循环开发。但这种分组并不是随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。软件生命周期模式l螺旋模式：螺旋模式：它是瀑布模式与演化模式相结合，并加入两者所忽略的风险分析所建立的一种软件开发模式。螺旋模式基本的做法是在瀑布模式的每一个开发阶段开发阶段之前之前，引入非常严格的风险识别、风险分析和风险控制风险识别、风险分析和风险控制。直到采取了消除直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被

9、暂停。另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员还可作出决定让余下的开发工作采用另外的生命周期模式，如演化模式，瀑布模式或自定的混合模式。l过程开发模式：过程开发模式：它又叫混合模式或元模式，是指把几种不同模式组合成一种混合模式混合模式，它允许一个项目能沿着最有效的路径发展项目能沿着最有效的路径发展。因为上述的模式中都有自己独特的思想，现在的软件开发团队中很少说标准的采用那一种模式的，因为模式和实际应用还是有很大的区别的。实际上，许多软件开发团队都是在使用几种不同的开发方法组成他们自己的混合模式。软件生命周期模式-总结 最后，我们来总结一下。螺旋模式是典型的迭代式生命

10、周期模式，而RUP则是近代迭代式生命周期的代表。与螺旋模式相比，RUP将风险管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驱动架构（MDA）和敏捷（Agile）软件开发。MDA模式是基于可执行规格说明的思想，是现代转换模式的代表，其核心技术是组件技术。而敏捷开发生命周期的典型代表是XP编程，是把传统的系统设计和实现由敏捷软件开发过程中的验收测试、重构和测试驱动所取代；把传统的集成和部署由敏捷软件开发中的持续集成和短周期所取代。 其实上，无论是瀑布开发模式还是螺旋开发模式，软件生命周期模式的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱无序、混乱的情

11、况。一些人为了能够管理和控制软件的开发过程能够管理和控制软件的开发过程，就把软件开发严格的区分区分为多个不同的阶段阶段，并在阶段间加上严格严格的审查审查，这就是软件开发模式产生的起因。它们体现了人们对软件过程的一个希望：严格控制、确保质量严格控制、确保质量。敏捷开发介绍l敏捷开发（敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件

12、一直处于可使用状态。l捷开发由几种轻量级的软件开发方法组成。捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等 XP -XP -eXtremeeXtreme ProgramingPrograming极限编程极限编程: :思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。 SCRUMSCRUM：是一种迭代的增量化过程，用于产品开发或工作管理 。 水晶方

13、法水晶方法Crystal:Crystal:由Alistair Cockburn在1990年代末提出。把不同类型的项目采用不同的方法。 FDDFDD特性驱动特性驱动 Feature Driven DevelopmentFeature Driven Development，由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。 DSDM-Dynamic System Development MethodologyDSDM-Dynamic System De

14、velopment Methodology，它倡导以业务为核心，快速而有效地进行系统开发， 在英国等欧洲国家比较流行。 ASD-Adaptive Software DevelopmentASD-Adaptive Software Development，由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive） 敏捷开发介绍敏捷开发的特点敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。很多方法很难独立的使用。如:测试驱动的开发

15、，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。使用这些方法并不能保证一定成功。开发者的经验和技术仍旧是影响开发结果的最主要因素。对于合适的人，基于敏捷原则的开发方法可以产生更好的结果，同时形成一个愉快地、有激情的工作环境敏捷模式理念最高目标是能持续地、及早地向客户交付软件；拥抱变化；频繁地发布可运行的软件；客户和开发人员在一起工作；以人为本；最重要的衡量开发过程的手段，是可工作的软件；稳定的开发速度；敏捷高效的设计；简单有效；重视Teamwork；积极的调整。敏捷开发介绍-极限编程XPl主要目的是降低需求变化的成本主要目的是降低需求变化的成本l定义了一套简单

16、的开发流程定义了一套简单的开发流程包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测试，验收测试等等l提倡互动交流、反馈、简单、勇气、团队提倡互动交流、反馈、简单、勇气、团队l核心做法：核心做法：小规模，频繁的版本发布，短迭代周期。测试驱动开发（Test-driven development）。结对编程（Pair programming）。持续集成（Continuous integration）。每日站立会议（Daily stand-up meeting）。共同拥有代码Collative code ownership.系统隐喻（System metaphor）。敏捷开发介绍-精

17、益l精益开发起源精益开发起源从丰田公司的产品开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原则核心思想及原则，另外一部分由一些在相应的工具相应的工具构成。l核心思想核心思想查明和消除浪费查明和消除浪费。在软件开发过程中，错误（bugs），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法消除。l精益开发的原则包括精益开发的原则包括:强调学习。不断改进所开发的产品和开发效率。在最后时刻做决定。避免在可能改变的事情上做无谓的努力，避免浪费。用最快的速度交付用户。缩短迭代周期加速开发及交付，加快交流，提高生产力给团队自主权。激励团队并让团队

18、成员自我管理-敏捷方法成功的基本因素之一。诚信。确保系统正常工作，客户需求是团队努力坚持的诚信和对用户的承诺。全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品， 从整体上考虑优化比从各个局部去优化更高效。 精益软件更重要的是不断完善开发过程的一种思维方式。精益软件更重要的是不断完善开发过程的一种思维方式。 SCRUM 开发流程是 Agile Process 的一种，以英式橄榄球争球队形 (Scrum) 为名，基本假设是开发软件就像开发新产品，无法一开始就能定义 Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。 Scr

19、um 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，碓保每天、每个阶段都朝向目标有明确的推进，因此 SCRUM 非常适用于产品开发项目。 敏捷开发介绍-scrum敏捷开发介绍-scrum SCRUM 开发流程通常以 30 天为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排

20、. SCRUM较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。 敏捷开发介绍-scrumlSCRUM是一个敏捷开发框架是一个敏捷开发框架它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。lScrum定义了定义了4种主要的角色：种主要的角色：1、产品拥有者（Product Owner）：该角色负责产品的远景规划，平衡所有利益相关者（stakeholder）的利益，确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。2

21、、利益相关者（Stakeholder）：该角色与产品之间有直接或间接的利益关系，通常是客户或最终用户代表。他们负责收集编写产品需求，审查项目成果等。3、Scrum专家（Scrum Master）：Scrum专家负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。 4、团队成员（Team Member）：即项目开发人员。SCRUM体系概览迭代迭代每30天Daily SCRUM每24小时高优先级可运行的软件可运行的软件工作项分解产品订单产品订单Product Backlog迭代订单迭代订单Sprint Backlog新的功能新的功能增量增量迭代规划会议迭代规划会议

22、Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排迭代复审会议迭代复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况迭代回顾会议迭代回顾会议Sprint Retrospective一般3个小时， ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meetin

23、g在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗? 产品负责人产品负责人Scrum主管主管开发团队开发团队十二条惯例和规则 On-Site Customer （现场客户） 计划项目 （Planning Game） 频繁地小规模发布软件 （Small Releases） 简单设计 （Simple Design） 测试驱动开发 （Test Driven Development） 持续集成 （Continuous Integration） 集体拥有代码

24、 （Collective Code Ownership） 编程规范 （Coding Standards） 重构 （Refactoring） System Metaphor （系统隐喻） Pair Programming （结对编程） 平稳的工作效率 （Sustainable Pace）敏捷开发-SCRUM名词解释lbacklog：可以预知的所有任务，包括功能性的和非功能性的所有任务。lsprint：一次跌代开发的时间周期，一般最多以30天为一个周期。在这段时间内，开发团队需要完成一个制定的backlog，并且最终成果是一个增量的，可以交付的产品。lsprint backlog：一个sprint

25、周期内所需要完成的任务。lscrumMaster：负责监督整个Scrum进程，修订计划的一个团队成员。ltime-box：一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。敏捷开发-SCRUM名词解释lsprint planning meeting：在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块，决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能

26、模块。制定的这些模块的工作量以小时计算。lDaily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？遇到了障碍无法继续下去？明天要做什么？通过该会议，团队成员可以相互了解项目进度。lSprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。敏捷开

27、发-实施实施ScrumScrum的过程介的过程介绍绍l确定确定Sprint Backlog将整个产品的backlog分解成Sprint Backlog，这个Sprint Backlog是按照目前的人力物力条件可以完成的。l召开召开sprint planning meeting划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。lsprint开发周期开发周期进入sprint开发周期，在这个周期内，每天每天需要召开Daily Scrum meeting。l成果演示成果演示 整个sprint周期结束，召开Sprint revi

28、ew meeting，将成果演示给Product Owner。l回顾回顾团队成员最后召开Sprint retrospective meeting，总结问题和经验。下一次下一次Sprint。敏捷开发每日会议：每日会议：l 目的：信息同步平台，非交流问题、讨论问题渠道。目的：信息同步平台，非交流问题、讨论问题渠道。l 形式：固定地点、时间的站立会议。形式：固定地点、时间的站立会议。生产率估算生产率估算燃尽线燃尽线敏捷开发原则和方法l迭代式开发。迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。l增量交付。增量交付。产

29、品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。l开发团队和用户反馈推动产品开发。开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。l持续集成持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。 l开发团队自我管理。开发团队自我管理。拥有一个积极的、自我管理的、具备

30、自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。敏捷实践原则1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。w有统计数字表明，越早、越频繁地向用户交付软件，软件的质量就越好。敏捷实践原则2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。w使用敏捷过程的开发组织欢迎需求的变化，因为他们认为需求变化可以让他们更多地了解市场。w敏捷开发组织采用各种方法和技术，使软件的结构高度灵活，需求的变化对系统的影响被最小化。3.经常性的交付可以工作的软件，交付的间隔可

31、以从几个星期到几个月，交付的时间间隔越短越好。w敏捷开发组织不满足于交付文档和计划，他们的目标是频繁地交付可以工作的软件，从而满足客户的需要。敏捷实践原则4.整个项目开发期间，业务人员和开发人员必须天天都在一起工作。敏捷实践原则5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。w在一个敏捷项目中，人员被认为是最重要的因素，其它所有因素（过程、环境、管理等）都被认为是次要的，当这些因素对人员造成不利影响时，就必须对其做出改变。w例如，如果某些过程步骤对团队人员来说是个障碍，那么过程就必须改变。敏捷实践原则6.在团队内部，最有效率和最有效果的信息传达方式就是

32、面对面的交流。w在敏捷项目中，默认的交流方式就是交谈，而不是文档。文档在必要的时候会被创建，但不会试图用文档来捕获所有项目信息。敏捷实践原则7.可以工作的软件是进度的主要度量标准。w对于敏捷项目来说，进度的度量标准是当前可满足用户需求的软件的量，而不是当前项目所处的阶段、文档数量或基础代码的数量。w项目完成了30%的含义是用户所需功能的30%已被实现。8.敏捷过程提倡可持续开发。出资人、开发者和用户应该共同维持一个稳定的开发速度。w敏捷小组会在整个项目开发期间保持一个适当的、可持续的开发速度，从而维持最高的质量标准。敏捷项目不会使开发者感到疲惫不堪。敏捷实践原则9.对卓越技术和良好设计的不断追

33、求有助于提高敏捷性。w敏捷开发团队认为提高质量会加快开发进度。因此要保持软件的精简和健壮。w敏捷开发团队的每个成员都要致力于开发高质量的代码，不能把混乱的、底质量的代码留到以后去修改。10.简单尽量减少工作量的艺术是至关重要的。w敏捷开发方法总是选择达到目标的最简单途径。w敏捷开发团队并不花费大量精力去预防将来可能出现的问题，而是专注于对当前工作采用最简单、最高质量的解决方案，并相信将来如果问题出现，可以很方便地进行修改。敏捷实践原则11.最好的架构、需求和设计都出自于自组织的团队。w敏捷开发团队是自组织的团队。职责并非是从团队外部加给每一个团队成员，而是团队作为一个整体接受职责并自己决定怎样

34、去完成它。12.每隔一定时间，团队都要总结怎样更有效率地工作，然后相应地调整自己的行为。w敏捷开发团队认识到环境在不断地改变，因此团队也需要不断地对组织、规则、惯例和各种关系进行调整，以保持自身的敏捷性。敏捷开发宣言极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。2001年，17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式，敏捷软件开发是一个开发软件的管理新模式，用来替代以文档驱动开发的

35、瀑布开发模式用来替代以文档驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。敏捷软件开发宣言内容： 个体和交互胜过过程和工具个体和交互胜过过程和工具可以工作的软件胜过面面具到的文档可以工作的软件胜过面面具到的文档可户合作胜过合同谈判可户合作胜过合同谈判响应变化胜过遵循计划响应变化胜过遵循计划核心理念核心理念：适应和以人适应和以人为本为本客户合作胜客户合作胜过合同谈判过合同谈判响应变化胜响应变化胜过遵循计划过遵循计划可以工作的可以工作的软件胜过面软件胜过面面俱到的文面俱到的文档档个体和交个体和交互互胜过过程胜过过程和工具和工具知识知识和技和技能能文化和文化和氛围氛围自组织团队自组织团队开放的心

36、态开放的心态敏捷项目的关键可用的可用的软件软件信息的信息的透明化透明化清晰的迭清晰的迭代目标代目标拥抱变化拥抱变化发现并解发现并解决问题决问题布置环境既有无隔墙隔板的工作场地，也又单独的工作间；一个足够宽敞的地方供大家开会；足够大的白板；足够长的电脑桌，可以让两个人并排坐在同一台电脑前面；每一个人都能很容易地看到其他人并和他们交流。一些白纸或者卡片。更理想的条件：POP电视机Video Game落地玻璃窗启动开发迭代计划迭代计划CRC卡设计卡设计承担承担Task分解分解TaskPair进行进行测试驱动的开发测试驱动的开发持续集成和发布持续集成和发布迭代结束迭代结束发布发布计划计划产生产生Sto

37、ry评估评估Story开始提炼开始提炼Metaphor多个迭代多个迭代多期多期计划计划最佳实践-管理 发布(Release)：每一期开发结束时提交给用户的一个可运行的系统。 迭代(Iteration)：一期开发过程中的一个开发周期。它有明确的目标，计划和实现方式，它包含了需求分析、设计、编程、测试等完整的开发过程。一个迭代的长度为1到3 周。在一期开发过程中，所有迭代的长度是相同的，比如都是3周。 小发布(Small Release)：处于开发中的系统，每集成一个新功能，都可以称为一个小发布。 理想开发时间：估计完成一项工作所需的持续工作时间，不考虑意外因素。最佳实践-需求 SPIKE：对不确

38、定的需求和设计等，通过写一些程序、进行详细设计或者演算等等方式做探测和尝试，以确定可行性。这些探测过程称为SPIKE。 User Story：是对用户的一个需求的一段简洁清晰的描述，该段描述有三个属性，即商业优先级、开发时间和风险。从某个角度看，XP过程是面向User Story的。 故事卡：用户把User Story的内容和属性写在一张卡片上，该卡片即故事卡。例，MSDN中的例子Island Hopper News： (1) 客户浏览分类广告；(2) 客户发布分类广告；客户浏览分类广告1周周价值：高价值：高风险：低风险：低客户发布分类广告2周周价值：高价值：高风险：低风险：低最佳实践-设计1

39、. CRC： Class Responsibility Collaboration。1989年， Kent Beck和Ward Cunningham提出的OO分析和设计方法，现在得到了广泛应用。Responsibility：Class的行为。Collaboration： Class之间的相互联系和作用；Collaborator指和某行为(Responsibility)相关的Class。可以在卡正面加上父类名，子类名；可以在卡背后加上属性。Class NameResponsibilitiesCollaboratorsAdSelectSingleAdBrowseAdDetails(aspx) Di

40、splay an adAd最佳实践-设计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”