敏捷开发流程与方法.ppt

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