敏捷开发流程与方法

敏捷开发流程与方法StrictlyPrivateandConfidentialBGCN交付管理部目录1.1敏捷的起源2敏捷系列1.2敏捷方法体系1敏捷开发简介3敏捷开发的误区1.3敏捷宣言1.4为什么要敏捷?敏捷开发的起源上个世纪90年代2001年2004年以后萌芽--产生敏捷方法敏捷方法是从上个世纪90年代开始发展起来的一组方法学的总称，包括极限编程等等。这些方法学之间有一些差异，但是差异不是特别大正规—成立敏捷联盟每种方法学的领导人共同起草了敏捷软件开发宣言，总结出方法之间的共同点，最终就是价值，并且用敏捷这个词给这种方法学一个统称发展—开始广为流行500强公司中众多公司应用敏捷;如HP,Microsoft,IBM等什么是敏捷开发？敏捷开发（AgileDevelopment）是一种以人为核心、迭代、循序渐进的开发方法。子项目特征-各个子项目的成果都经过测试-具备集成和可运行的特征-小项目相互联系目录1.1敏捷的起源1.2敏捷方法体系1敏捷开发简介1.3敏捷宣言1.4为什么要敏捷?2敏捷系列3敏捷开发的误区敏捷方法XP-eXtremePrograming极限编程:–思想源自KentBeck和WardCunningham在软件项目中的合作经历。SCRUM：–是一种迭代的增量化过程，用于产品开发或工作管理。水晶方法Crystal:–由AlistairCockburn在1990年代末提出。把不同类型的项目采用不同的方法。FDD－特性驱动FeatureDrivenDevelopment，–由PeterCoad、JeffdeLuca、EricLefebvre共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。DSDM-DynamicSystemDevelopmentMethodology，–它倡导以业务为核心，快速而有效地进行系统开发，在英国等欧洲国家比较流行。ASD-AdaptiveSoftwareDevelopment，–由JimHighsmith在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)软件很难维护或扩展；4)在项目后期阶段发现很严重的设计缺陷；5)软件质量或性能不合格；6)Test-Build-Release过程的可操作性、可维护性很差；7)人员流动；……1)为了规范化开发过程，引进传统工程的概念（瀑布型）；2)为了理解需求，提出原型法；3)为了提高设计开发的效率和扩展性，提出重用和面向对象等思想；4)为了让开发过程更灵活，提出了开发框架的概念；5)为了降低风险，提出了风险评估、成本控制和增量开发等思想；我们为什么需要敏捷部门：1)培养团队合作精神，稳定开发队伍；2)提高开发人员的水平；3)提高项目成功率，降低开发成本，提升软件开发效率项目经理：1)更好地和用户沟通，更清晰地理解用户需求；2)更充分地使用资源，更科学地调配资源，更精确地掌握开发进度。系统分析设计：1)设计更加完善；2)更有效地更新知识，得到其他成员更多的尊重。程序员：1)学习系统设计和项目管理；2)提高学习和工作效率，受到重视，减少加班时间，工作更高效谁在用敏捷Fortune500公司中成功应用XP的公司包括Ford，Daimler-Chrysler，FirstUnionNationalBank，IBM，HP等等。通信业NS，Ericsson,Alcatel等都号称在转向敏捷更多是小规模开发队伍（小规模开发队伍小规模项目）越来越多的公司开始使用敏捷开发过程敏捷开发成功的因素知识和技能文化和氛围自组织团队开放的心态目录2.1XP-eXtremePrograming2敏捷系列2.2SCRUM1敏捷开发简介3敏捷开发的误区敏捷实践在敏捷的两个门派：XP、Scrum中，整理归纳了很多可以用于协助软件开发的实践，后面统称为敏捷实践。什么是XPXPisalightweightmethodologyforsmalltomediumsizedteamsdevelopingsoftwareinthefaceofvagueorrapidlychangingrequirements.--KentBeck.KentBeck,WardCunningham,MartinFowler,RonJeffries于2000年创立XP是软件开发过程中的纪律，它规定你：必须在编程前些测试，必须两个人一起编程，必须遵守编程规范……。XP是把最好的实践经验提取出来，形成了一个崭新的开发方法。ExtremeProgramming什么是XPExtremeProgramming极限的含义：软件开发中的优点发挥到极致(KentBeck).XP：给程序员提供了明确的方法，使得程序员尽管面对需求的改变，却能够从容应对，即使着重变化发生在项目的后期，仍然能够编出代码。XP核心：沟通、简明、反馈和勇气XP重视沟通，客户、开发人员、管理者共同组成团队。XP是一个实践系统13个实践XP方法的贡献以拥抱变化的思想，协作的团队，简单的规则等为原则的13个具体实践是知名度最高的敏捷开发方法XP的计划/反馈循环XP开发工作流XP的关键实践:编程方法交付和管理小组实践XP的关键实践结对编程测试驱动开发重构简单设计代码集体所有编码标准稳定高速的步伐持续集成隐喻现场客户完整的团队小规模发布计划游戏编程方法小组实践交付和管理交付和管理交付和管理1:完整的团队(WholeTeam)ProductManager/ProjectmanagerCoachTeamleadDevelopersTrackerTester(On-Site)Customers所有的小组成员应在同一个工作地点工作。成员中必须有一个用户代表（On-siteUser）,由他/她来提出需求，确定开发优先级，把握开发的动向。通常还设一个教练（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。小组每个成员都应围绕用户代表，充分贡献自己的技能。交付和管理2:计划游戏(PlanningGame)增加/改变需求产生和评估UserStory发布计划迭代计划1迭代计划2迭代计划n…………实施迭代1实施迭代2实施迭代n…………1..N个发布探索阶段计划阶段调整阶段调整开发速度/内容交付和管理3:现场客户(On-SiteCustomer)客户是Team成员，在开发现场和开发人员一起工作。传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。XP新增加的任务：(1)写UserStory(2)评估UserStory的商业优先级(3)为每个UserStory定义验收测试(4)计划开发内容(5)调控开发过程(6)建立商业模型，把隐藏在客户需求下的原则传授给开发人员(8)程序员分担任务的过程支解了对他们商业模型的理解(9)参加设计过程(10)和程序员一起找出Metaphor，导引设计方向(11)在Metaphor的帮助下，定义更有效更实际的功能测试，给程序员的设计制定了规范交付和管理4:小规模发布降低开发风险。保证客户有足够的依据调控开发过程(增加、删除或改变UserStory)。客户使用发布的系统，可以保证频繁地反馈和交流。发布过程应该尽可能地自动化、规范化。不断地发布可用的系统可以告诉客户你在做正确的事情。低风险智能化适应调整频繁交流知会客户频繁发布经过验证随着开发的推进，发布越来越频繁。所有的发布都要经过功能测试。小规模发布小组实践小组实践1:持续集成(Continuousintegration)持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。“ATestaday,takesthebugsaway”---Siemens失败通过时间功能测试小组实践1:持续集成(Continuousintegration)1自动化编译质量度量23自动化测试持续反馈团队实践2:隐喻(SystemMetaphor)“Thesystemmetaphorisastorythateveryone-customers,programmers,andmanagers-cantellabouthowthesystemworks.”—KentBeckTeam将Domain/Sub-DomainModel，Design/Sub-DesignModel以及一些关键概念等等抽象化为比喻。通过这些比喻，加强客户和程序员之间的相互理解，消化积累知识，指导设计开发的方向。例：Market—发布/浏览，价格洽谈，生成和履行合同；String，Tree，Package，Chartroom，Spider，Robot……；电影后期制作—邮递—电影院播放电影。小组实践2:隐喻(SystemMetaphor)Metaphor的形成过程，是客户建立并抽象商业模型和商业概念的过程，是程序员建立并抽象设计模型和设计概念的过程。Metaphor使客户和程序员用共通的模型和语言进行交流—“OneTeam,onelanguage”。Metaphor可以帮助减少“知识泄露”和“支解知识”。Metaphor是设计过程的航标——真正灵活有效的设计是针对商业原则的设计，而不是针对商业原则表现形式的设计，更不是脱离商业需求目的的学术设计。随着开发的继续，Team会找到更好的Metaphor。这是知识细化、深化的结果，是“持续学习”(Continuouslearning)的过程；是对商业模型和设计模型的持续重构。小组实践3:编码标准(Codingstandards)编码标准的目的：防止团队被一些无关紧要的愚蠢争论搞得不知所措。不要预先花费太多时间目标应该是团队中没有人辨认各自的代码以团队为单位对某一标准达成协议，然后遵守这一标准不是事无巨细的规则列表，而是确保代码可交流的指导方针七个原则编码标准开始时应很简单，然后根据团队经验逐步进化创建能够工作的最简单标准，然后逐步发展只制订适合本团队的小组实践4:集体拥有代码“我们”的代码，而不是“我”的代码。任何人可以改动任何一段代码，但改动后的代码必须通过所有相关的测试。简单设计，编码标准和结对编程，使阅读和修改Team内其他人的代码变得实际可行。思考：同公司信息安全可能有冲突？在一定范围内进行集体拥有代码还是可行的小组实践5:稳定高速的步伐(40-HourWeek)“每天早晨都感到有活力有激情，每天晚