敏捷开发介绍

敏捷开发之SCRUM,2012.10.11,导航,敏捷开发的诞生历史,软件团队的不断增大效率确越来越差？,概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，并把这些价值观和原则称为敏捷开发,2001年一批业界专家,软件团队,敏捷开发的历史,我们提倡,团队价值,沟通,敏捷开发十年的发展,概念,实践,普及,为什么需要敏捷开发？,软件开发面临问题,为什么需要敏捷开发,用户需求总是在变化,传统软件开发周期长,传统软件开发后续难以调整,为什么需要敏捷开发,能快速响应需求的变化,快速、频繁的交付有价值的软件,客户合作（快速交流反馈）,快,敏捷开发有什么特性？,为什么需要敏捷开发,敏捷开发优势,精确,质量,速度,高效的自我团队,丰厚的投资回报率,最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。,传统开发一次设计，开发周期很长。而敏捷方法则是通过短周期“设计开发交付”有用的软件给用户，并从用户那里得到反馈，再根据用户反馈进行下一个周期的“设计开发交付”,敏捷开发团队成员在开发过程中都能积极主动，自我管理。每个团队成员的技术能力、交流、社交、表达和领导能力都能得以提高。,开发了一年，这不是我需要的软件,不断发布版本给客户，不断提供新的需求，不断改进,传统瀑布开发模型,VS,敏捷开发,为什么需要敏捷开发,相对于（非敏捷），敏捷软件开发具有以人为本、轻载灵活、降低风险、提高质量、减少成本、效率高、见效快等优点,相关统计表明，敏捷开发可以将效率提高310倍，软件的质量也有更加可靠的保证；同时，还给团队内的每个成员提供了良好的发展机会，技术和合作水平都能得到相应提高,这么一大堆的优点，所以我们需要敏捷开发,XX,敏捷开发介绍,什么是SCRUM,迭代，增量,大家先弄清楚这两个词的意思,模糊,清晰,迭代反复求精,增量逐块构建,每次构建一点点,Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程,一个迭代开发周期,需求,完成,开发,发布,测试,计划,SCRUM基本流程,迭代,交付后客户重新调整需求,频繁交付给客户，根据客户的新需求，不断完善软件,Scrum基本元素,1.产品Backlog（ProductBacklog）2.SprintBacklog3.Sprint燃尽图（SprintBurndownChart）,1.产品负责人（ProductOwner）2.ScrumMaster3.Scrum团,1.Sprint计划会议（SprintPlanningMeeting）2.每日站会（DailyScrumMeeting）3.Sprint评审会议（SprintReviewMeeting）4.Sprint回顾会议（SprintRetrospectiveMeeting）,三个角色,四个仪式,三个物件,Scrum由三个角色、四个仪式和三个物件（343）,三个角色-Scrum角色和职责,确定产品的功能。决定发布的日期和发布内容。为产品的profitabilityoftheproduct(ROI)负责。根据市场价值确定功能优先级。每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。接受或拒绝接受开发团队的工作成果。,保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织DailyScrum,SprintReviewandSprintPlanning,一般情况人数在5-9个左右团队要跨职能（包括开发人员、测试人员、用户界面设计师等）团队成员需要全职。（有些情况例外，比如数据库管理员）在项目向导范围内有权利做任何事情已确保达到Sprint的目标。高度的自我组织能力。向ProductOwner演示产品功能。团队成员构成在sprint内不允许变化。,项目经理,项目管理,团队,XX,迭代规划会议SprintPlan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排,评审会议（外部）SprintReview一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况,评审会议（内部）SprintRetrospective一般3个小时，ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快,每日站立会议DailyScrumMeeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗?,开发团队,一个迭代周期,需求转化成任务,每日开发,完成一个迭代周期,四个会议-仪式,回顾会议团队的定期自我检视，发现什么是好的，什么是不好的。一般控制在15-30分钟每个Sprint都要做全体参加Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。,XX,三个物件-Scrum物件之产品Backlog,一般情况使用用户故事来表示backlog条目理想情况每个需求项都对产品的客户或用户有价值Backlog条目按照商业价值排列优先级优先级由产品负责人来排列在每个Sprint结束的时候要更新优先级的排列,一个需求的列表,三个物件-Scrum物件之SprintBacklog,Sprintbacklog定义了Sprint的目标，明确了Sprint过程中具体需要完成的任务,三个物件-Scrum物件之SprintBacklog,如何管理sprintBacklog,团队成员自己挑选任务，而不是指派任务,对每一个任务，每天要更新剩余的工作量估算,每个团队成员都可以修改Sprintbacklog，增加、删除或者修改任务,三个物件-Scrum物件之燃尽图,随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。,燃尽图直观的反映了Sprint过程中，剩余的工作量情况,腾讯企鹅帝国的敏捷开发,敏捷测试,我是开发,我是测试,敏捷开发正快速跑步前进中,我们测试从头到尾一直参与,设计文档转换成用例,开发中,全面测试重点测试,开发用例编写者一起讨论完善功能测试点,完成诺干个功能点,测试用例,设计文档,自由测试,敏捷测试工程师的十条法则,需求转换成测试，完成测试提供有意义的反馈,对会影响核心功能的花俏功能，可以质疑这些功能影响大局，优先关注核心功能,敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时，她会与客户和开发人员讨论,1、提供持续反馈,2、为用户创造价值,3、促进面对面的沟通,敏捷测试工程师的十条法则,我们需要勇气允许自己失败，至少我们会短暂失败，并从中学习教训。在由于构建版本不稳定导致一次迭代失败之后，我们开始寻找方法以确保这种事情不再发生,找到合适的方法，简单的方法进行测试,反馈问题给团队，问题持续解决,4、勇气,5、简单化,6、持续改进,敏捷测试工程师的十条法则,敏捷开发项目在持续开发，持续变化，测试也在持续不停进