《敏捷开发流程与方法讲义bwff.pptx》由会员分享，可在线阅读，更多相关《敏捷开发流程与方法讲义bwff.pptx（59页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、敏捷开发流程与方法敏捷开发流程与方法StrictlyPrivateandConfidentialBGCN交付管理部目录1.1敏捷的起源2敏捷系列敏捷系列1.2敏捷方法体系1敏捷开发简介敏捷开发简介3 敏捷开发的误区敏捷开发的误区1.3敏捷宣言1.4为什么要敏捷?敏捷开发的起源上个世纪上个世纪90年代年代2001年年2004年以后年以后萌芽-产生敏捷方法敏捷方法是从上个世纪敏捷方法是从上个世纪90年代开始发展起来的年代开始发展起来的一组方法学的总称，包一组方法学的总称，包括极限编程等等。这些括极限编程等等。这些方法学之间有一些差异，方法学之间有一些差异，但是差异不是特别大但是差异不是特别大正规成
2、立敏捷联盟每种方法学的领导人共每种方法学的领导人共同起草了敏捷软件开发同起草了敏捷软件开发宣言，总结出方法之间宣言，总结出方法之间的共同点，最终就是价的共同点，最终就是价值，并且用敏捷这个词值，并且用敏捷这个词给这种方法学一个统称给这种方法学一个统称发展开始广为流行500强公司中众多公司强公司中众多公司应用敏捷应用敏捷;如如HP,Microsoft,IBM等等 什么是敏捷开发？敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法。q子子项目特征目特征 -各个子项目的成果都经过测试各个子项目的成果都经过测试 -具备集成和可运行的特征具备集成和可运行的特征 -小
3、项目相互联系小项目相互联系目录1.1敏捷的起源1.2敏捷方法体系1敏捷开发简介敏捷开发简介1.3敏捷宣言1.4为什么要敏捷?2敏捷系列敏捷系列3 敏捷开发的误区敏捷开发的误区 敏捷方法XP-eXtreme Programing极限编程:思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。SCRUM：是一种迭代的增量化过程，用于产品开发或工作管理。水晶方法Crystal:由Alistair Cockburn在1990年代末提出。把不同类型的项目采用不同的方法。FDD特性驱动 Feature Driven Development，由Peter Coad、Jeff de
4、 Luca、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。DSDM-Dynamic System Development Methodology，它倡导以业务为核心，快速而有效地进行系统开发，在英国等欧洲国家比较流行。ASD-Adaptive Software Development，由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive）敏捷开发特点 敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引
5、力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。很多方法很难独立的使用。如:测试驱动的开发，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。使用这些方法并不能保证一定成功。开发者的经验和技术仍旧是影响开发结果的最主要因素。对于合适的人，基于敏捷原则的开发方法可以产生更好的结果，同时形成一个愉快地、有激情的工作环境目录1.1敏捷的起源1.2敏捷方法体系1敏捷开发简介敏捷开发简介1.3敏捷宣言1.4为什么要敏捷?2敏捷系列敏捷系列3 敏捷开发的误区敏捷开发的误区 敏捷宣言核心理念核心理念：适应和以人为本适应和以人为本客户合作胜过合客户合作胜
6、过合同谈判同谈判响应变化胜过遵响应变化胜过遵循计划循计划可以工作的软件胜过面可以工作的软件胜过面面俱到的文档面俱到的文档个体和交互个体和交互胜过过胜过过程和工具程和工具敏捷规则最高目标是能持续地、及早地向客户交付软件；拥抱变化；频繁地发布可运行的软件；客户和开发人员在一起工作；以人为本；最重要的衡量开发过程的手段，是可工作的软件；稳定的开发速度；敏捷高效的设计；简单有效；重视Teamwork；积极的调整。目录1.1敏捷的起源1.2敏捷方法体系1敏捷开发简介敏捷开发简介1.3敏捷宣言1.4为什么要敏捷?2敏捷系列敏捷系列3 敏捷开发的误区敏捷开发的误区 我们为什么需要敏捷项目为什么失败？软件工程
7、试图解决这些问题：1)1)对用户需求理解得不清楚，甚至有对用户需求理解得不清楚，甚至有错误；错误；2)2)用户需求变化；用户需求变化；3)3)软件很难维护或扩展；软件很难维护或扩展；4)4)在项目后期阶段发现很严重的设计在项目后期阶段发现很严重的设计缺陷；缺陷；5)5)软件质量或性能不合格；软件质量或性能不合格；6)6)Test-Build-ReleaseTest-Build-Release过程的可操作过程的可操作性、可维护性很差；性、可维护性很差；7)7)人员流动；人员流动；1)1)为了为了规范化开发过程，引进传统工程的规范化开发过程，引进传统工程的概念（瀑布型）；概念（瀑布型）；2)2)为
8、了理解需求，提出原型法；为了理解需求，提出原型法；3)3)为了提高设计开发的效率和扩展性，提为了提高设计开发的效率和扩展性，提出重用和面向对象等思想；出重用和面向对象等思想；4)4)为了让开发过程更灵活，提出了开发框为了让开发过程更灵活，提出了开发框架的概念；架的概念；5)5)为了降低风险，为了降低风险，提出了风险评估、成本提出了风险评估、成本控制和增量开发等思想；控制和增量开发等思想；我们为什么需要敏捷部门：1)培养团队合作精神，稳定开发队伍；2)提高开发人员的水平；3)提高项目成功率，降低开发成本，提升软件开发效率项目经理：1)更好地和用户沟通，更清晰地理解用户需求；2)更充分地使用资源，
9、更科学地调配资源，更精确地掌握开发进度。系统分析设计：1)设计更加完善；2)更有效地更新知识，得到其他成员更多的尊重。程序员：1)学习系统设计和项目管理；2)提高学习和工作效率，受到重视，减少加班时间，工作更高效 谁在用敏捷Fortune 500 公司中成功应用XP的公司包括Ford，Daimler-Chrysler，First Union National Bank，IBM，HP等等。通信业NS，Ericsson,Alcatel等都号称在转向敏捷更多是小规模开发队伍（小规模开发队伍 小规模项目）越来越多的公司开始使用敏捷开发过程敏捷开发成功的因素知识和技能知识和技能文化和氛围文化和氛围自组织
10、团队自组织团队开放的心态开放的心态 目录2.1XP-eXtreme Programing2敏捷系列敏捷系列2.2SCRUM1敏捷开发简介敏捷开发简介3 敏捷开发的误区敏捷开发的误区 敏捷实践l在敏捷的两个门派：在敏捷的两个门派：XP、Scrum中，整理归纳了很多可以中，整理归纳了很多可以用于协助软件开发的实践，后面统称为敏捷实践。用于协助软件开发的实践，后面统称为敏捷实践。什么是XPXPisalightweightmethodologyforsmalltomediumsizedteamsdevelopingsoftwareinthefaceofvagueorrapidlychangingreq
11、uirements.-KentBeck.KentBeck,WardCunningham,MartinFowler,RonJeffries于2000年创立XP是软件开发过程中的纪律，它规定你：必须在编程前些测试，必须两个人一起编程，必须遵守编程规范。XP是把最好的实践经验提取出来，形成了一个崭新的开发方法。Extreme Programming 什么是XPExtreme Programmingl极限的含义：极限的含义：软件开发中的优点发挥到极致(KentBeck).lXP：给程序员提供了明确的方法，使得程序员尽管面对需求的改变，却能够从容应对，即使着重变化发生在项目的后期，仍然能够编出代码。lX
12、P核心：核心：沟通、简明、反馈和勇气 lXP重视沟通，客户、开发人员、管理者共同组成团队。lXP是一个实践系统是一个实践系统p13个实践lXP方法的贡献方法的贡献p以拥抱变化的思想，协作的团队，简单的规则等为原则的13个具体实践p是知名度最高的敏捷开发方法 XP的计划/反馈循环 XP开发工作流 XP的关键实践:编程方法编程方法交付和管理交付和管理小组实践小组实践 XP的关键实践结对编程结对编程测试驱动开发测试驱动开发重构重构简单简单设计设计代码集体所有代码集体所有编码标准编码标准稳定高速的步伐稳定高速的步伐持续集成持续集成隐喻隐喻现场客户现场客户完整的完整的团队团队小规模发小规模发布布计划游戏
13、计划游戏编程方法编程方法小组实践小组实践交付和管理交付和管理交付和管理交付和管理 交付和管理1:完整的团队(Whole Team)ProductManager/ProjectmanagerCoachTeamleadDevelopersTrackerTester(On-Site)Customersl所有的小组成员应在同一个工作地点工作。l成员中必须有一个用户代表（On-siteUser）,由他/她来提出需求，确定开发优先级，把握开发的动向。l通常还设一个教练（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。l小组每个成员都应围绕用户代表，充分贡献自己的技能。交付和管理2:计划游戏(P
14、lanning Game)增加/改变需求产生和评估UserStory发布计划迭代计划1迭代计划2迭代计划n实施迭代1实施迭代2实施迭代n1.N个发布个发布探索阶段探索阶段计划阶段计划阶段调整阶段调整阶段调整开发速度/内容 交付和管理3:现场客户(On-Site Customer)客户是Team成员，在开发现场和开发人员一起工作。传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。XP新增加的任务：(1)写User Story (2)评估User Story的商业优先级 (3)为每个User Story定义验收测试 (4)计划开发内容 (5)调控开发过程 (6)建立商业模型，把隐藏在客户
15、需求下的原则传授给开发人员 (8)程序员分担任务的过程支解了对他们商业模型的理解 (9)参加设计过程 (10)和程序员一起找出Metaphor，导引设计方向 (11)在Metaphor的帮助下，定义更有效更实际的功能测试，给程序员的设计制定了规范 交付和管理4:小规模发布降低开发风险。降低开发风险。保证客户有足够的依据调控开保证客户有足够的依据调控开发过程发过程(增加、删除或改变增加、删除或改变User Story)。客户使用发布的系统，可以保证客户使用发布的系统，可以保证频繁地反馈和交流。频繁地反馈和交流。发布过程应该尽可能发布过程应该尽可能地自动化、规范化。地自动化、规范化。不断地发布可用
16、的系统可以告不断地发布可用的系统可以告诉客户你在做正确的事情。诉客户你在做正确的事情。低风险低风险智能化智能化适应调整适应调整频繁交流频繁交流知会客户知会客户频繁发布频繁发布经过验证经过验证随着开发的推进，发布越随着开发的推进，发布越来越频繁。来越频繁。所有的发布都要经过所有的发布都要经过功能测试。功能测试。小规模发布小规模发布小规模发布小规模发布小组实践小组实践 小组实践1:持续集成(Continuous integration)持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。“A Test a
17、 day,takes the bugs away”-Siemens失败通过时间功能测试 小组实践1:持续集成(Continuous integration)1自动化编译自动化编译质量度量质量度量23自动化测试自动化测试持续反馈持续反馈 团队实践2:隐喻(System Metaphor)“The system metaphor is a story that everyone-customers,programmers,and managers-can tell about how the system works.”Kent Beck Team将Domain/Sub-Domain Model，
18、Design/Sub-Design Model以及一些关键概念等等抽象化为比喻。通过这些比喻，加强客户和程序员之间的相互理解，消化积累知识，指导设计开发的方向。例：Market 发布/浏览，价格洽谈，生成和履行合同；String，Tree，Package，Chartroom，Spider，Robot；电影后期制作 邮递 电影院播放电影。小组实践2:隐喻(System Metaphor)Metaphor的形成过程，是客户建立并抽象商业模型和商业概念的过程，是程序员建立并抽象设计模型和设计概念的过程。Metaphor使客户和程序员用共通的模型和语言进行交流 “One Team,one langua
19、ge”。Metaphor可以帮助减少“知识泄露”和“支解知识”。Metaphor是设计过程的航标 真正灵活有效的设计是针对商业原则的设计，而不是针对商业原则表现形式的设计，更不是脱离商业需求目的的学术设计。随着开发的继续，Team会找到更好的Metaphor。这是知识细化、深化的结果，是“持续学习”(Continuous learning)的过程；是对商业模型和设计模型的持续重构。小组实践3:编码标准(Coding standards)编码标准的目的：防止团队被一些无关紧要的愚蠢争论搞得不知所措。不要预先花费太多时间不要预先花费太多时间目标应该是团队中没有人辨认各自的代码目标应该是团队中没有人
20、辨认各自的代码以团队为单位对某一标准达成协议，然后遵守这一标准以团队为单位对某一标准达成协议，然后遵守这一标准不是事无巨细的规则列表，而是确保代码可交流的指导方针不是事无巨细的规则列表，而是确保代码可交流的指导方针七个原则七个原则七个原则七个原则编码标准开始时应很简单，然后根据团队经验逐步进化编码标准开始时应很简单，然后根据团队经验逐步进化创建能够工作的最简单标准，然后逐步发展创建能够工作的最简单标准，然后逐步发展只制订适合本团队的只制订适合本团队的 小组实践4:集体拥有代码“我们”的代码，而不是“我”的代码。任何人可以改动任何一段代码，但改动后的代码必须通过所有相关的测试。简单设计，编码标准
21、和结对编程，使阅读和修改Team内其他人的代码变得实际可行。思考：同公司信息安全可能有冲突？在一定范围内进行集体拥有代码还是可行的在一定范围内进行集体拥有代码还是可行的 小组实践5:稳定高速的步伐(40-Hour Week)“每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足。”-Kent Beck 8:00 AM Standup MeetingPair UpTester自我测试自我测试编码编码重构重构集成并纳入集成并纳入CI 验证验证5:30PM 结束结束测试用例编程方法编程方法 编程方法1:测试驱动开发(TDD)失败通过时间单元测试100%通过设计先先写写单元测试单元测试重构运行运行单元
22、测试单元测试编程发现BUG集成先先写写功能测试功能测试UserStory运行运行功能测试功能测试 编程方法2:重构(Refactoring)减少重复设计，优化设计结构，提高技术上的重用性和可扩展性。减少重复设计，优化设计结构，提高技术上的重用性和可扩展性。重构和编程前的计划型设计重构和编程前的计划型设计(Planned Design)结合，使结合，使XP的简单设计可行有效。的简单设计可行有效。XP提倡毫不留情的重构提倡毫不留情的重构(Refactor mercilessly)。任何人可以重构任何代码，前提是重构后的代码一定要通过任何人可以重构任何代码，前提是重构后的代码一定要通过100%测试单
23、元测试后才能被测试单元测试后才能被Check-in。可以根据需要，将一个迭代的全部目标定为重构。可以根据需要，将一个迭代的全部目标定为重构。不要太在意什么是最简单的设计不要太在意什么是最简单的设计 愿意在最后重构，比知道如何做简单的设计重要得多。愿意在最后重构，比知道如何做简单的设计重要得多。在在Metaphor指引下的重构，是为商业模型服务的。不要把重构变成不断的盲目精简代码。指引下的重构，是为商业模型服务的。不要把重构变成不断的盲目精简代码。编程方法3:简单设计 简单设计 Do the simplest thing that could possibly work；You arent go
24、ing to need it如果没有它和众多惯例规则之间的耦合，XP的演化设计就蜕化成CODE-FIX。XP的演化设计是在Up-front design和Refactoring之间找到新的平衡。需求 分析 设计 编码 测试 集成 使用和维护PlannedDesignXP Design变化导致的成本增加软件研发异动曲线 编程方法3:简单设计 标准(依重要性)：通过所有测试，可读性高的代码，避免重复，最少数量的类别或方法。System Metaphor给设计提供了指引，加强Team对设计的理解；第一个迭代搭建了基本的系统框架。以后的迭代过程，是在反馈和编程的基础上做交互式设计，减少了设计的投机性。
25、迭代过程中的CRC卡帮助Team交流设计思想，简化了设计文档。构对设计进行优化。XP 认为设计非常重要，因此应该是一个持续的事务。我们总是先尝试使用能认为设计非常重要，因此应该是一个持续的事务。我们总是先尝试使用能够工作的最简单的设计，然后随着现实的不断显现来更改它。够工作的最简单的设计，然后随着现实的不断显现来更改它。对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。它们只不过需要尽可能简单，但是仍能工作。它们只不过需要尽可能简单，但是仍能工作。编程方法4:结对编程(Pair Programming)所有设计决
26、策都牵涉到至少两个人。至少有两个人熟悉系统的每一部分。几乎不可能出现两个人同时疏忽测试或其它任务。改变各对的组合在可以在团队范围内传播知识。代码总是由至少一人复查。结对的编程比单独编程更有效。XP中最有争议的实践之一 目录2.1XP-eXtreme Programing2敏捷系列敏捷系列2.2SCRUM1敏捷开发简介敏捷开发简介3敏捷与敏捷与CMMCMM4 敏捷开发的误区敏捷开发的误区 SCRUMSCRUM来源于橄榄球运动，指：“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。”Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发
27、现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来的重大变化。(Ken Schwaber)Scrum是一种灵活的软件管理过程，它可以帮助驾驭迭代、递增的软件开发过程。Scrum于1995年提出，并在2001年同其他方法论一起组成“敏捷联盟（Agile Alliance）”。Scrum这个轻量的过程可以作为包装器，也就是说你可以把Scrum与其它灵活的过程框架组合起来。SCRUM的过程图 SCRUM实践 1.Scrum团队：5-7个人的小项目团队，团队的负责人可能担负起Scrum Master的角色。2.Backlog:急待完成的一系列任务，包括：未细化的产品
28、功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。3.Sprint(冲刺):通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。每一次Sprint之后，一定要有可以交付使用的功能。4.Scrum会议:这是与传统方式最大的区别，每天15-20分钟的Scrum会议，通常在每天的同一时间和同一个房间内举行。Scrum团队所有人都参加，也可以有旁听者（但不允许旁听者指手划脚）。在这个15分钟的会议上，Scrum Master会询问每个成员三个问题:a)自上次
29、Scrum会议后的1天里你做了什么？b)从现在到下次Scrum会议的1天时间里你准备做什么？c)你在工作中遇到了哪些困难？每个成员在Backlog条目上所花费的时间会被记录到Spring backlog中。Scrum Master在会上对存在的问题提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它起到了快速简报的作用。5.通过Sprint Backlog的分析，可以了解Backlog的进度，尽早的了解所发生的问题6.管理者不在是项目或者团队的老板,而是帮助团队解决问题的协调者或是助手。7.每一次Sprint之后要review，团队按照既定的Sprin
30、t Backlog目标来演示完成的内容。Scrum中的3、3、3待开发任务列表待开发任务列表(The Sprint Backlog)待修复缺陷列表待修复缺陷列表(The defect backlog)进度图、燃尽图进度图、燃尽图(Brun Down Chart)Product OwnerScrum Master团队成员团队成员(Scrum Team）迭代计划会议迭代计划会议(Sprint Planning Meeting)每日晨会每日晨会(Daily Scrum Meeting)迭代回顾会议迭代回顾会议(Sprint Review Meeting)Product Backlog SPRINT划
31、分示意 Sprint会议根据Backlog，制定每次Sprint的计划目录2敏捷系列敏捷系列1敏捷开发简介敏捷开发简介3 敏捷开发的误区敏捷开发的误区讨论误区一:敏捷是一个”过程误区二:敏捷仅是个软件过程误区三:敏捷是反文档的 误区四:为了敏捷而敏捷误区五:重做就是重构误区一:敏捷是一个”过程l敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。敏捷价值观，遵循敏捷的原则。误区二:敏捷仅是个软件过程l敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正敏捷相对以前的软件工程最大的革
32、新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条如敏捷宣言的第一条“个体和交互胜过过程和工具个体和交互胜过过程和工具”所说的。所说的。l涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：l把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，
33、而不是收钱就完事儿。而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。l把人的能动性调动起来，给动力而不是给压力。把人的能动性调动起来，给动力而不是给压力。l要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。机械地实施规范。l没有绝对的权威，每个人都有可取之处。没有绝对的权威，每个人都有可取之处。文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的
34、想法，那样更是低效的。应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。文档不是目的，有效沟通才是目的。误区三:敏捷是反文档的“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：Q：“我们现有的过程很好，不知道怎么用敏捷改进?”A：“既然很好，那就不要用敏捷”。做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。误区四:为了敏捷而敏捷重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。误区五:重做就是重构提升你的潜力提升你的潜力