质量保证系列课件-敏捷项目过程介绍(V1.3).pptx

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Confidential 2010 iSoftStone Group.All Rights Reserved.,#,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,#,质量保证系列课件,敏捷项目过程介绍,2011,年,3,月,2,1.,敏捷核心理念,1.1,敏捷宣言,1.2.,敏捷原则,1,.3.,敏捷理念,1.4.,瀑布、迭代和敏捷的区别,2.,敏捷优秀实践,3.,敏捷流程介绍,目录,1.1,敏捷宣言,3,敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作。,我们认为左项具有更大的价值当然这并不意味着右项没有价值,个体和交互,过程和工具,胜过,可以工作的软件,面面俱到的文档,胜过,客户合作,合同谈判,胜过,响应变化,遵循计划,胜过,1.2,敏捷原则,4,我们最优先要做的是通过,尽早的、持续的,交付有价值的软件来使客户满意。,即使到了开发的后期，也欢迎改变需求。敏捷过程,利用变化来为客户,创造竞争优势。,经常性地,交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。,可以工作的软件,是首要的,进度,度量标准。,在整个项目开发期间，业务人员和开发人员必须,天天都在一起工作,。,围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且,信任,他们能够完成工作。,在团队内部，最具有效果并且富有效率的传递信息的方法，就是,面对面,的交谈。,敏捷过程提倡,可持续的开发速度,。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。,不断地关注,优秀的技能和好的设计,会增强敏捷能力。,简单,使未完成的工作最大化的艺术,是根本的。,最好的构架、需求和设计出自于“,自组织,”的团队。,每隔一定时间，团队会在如何才能更有效地工作方面进行,反省,，然后响应地对自己的行为进行调整。,敏捷,=,理念,+,优秀实践,+,应用,理念,（核心思想）,应用,1.3,敏捷理念,优秀实践,（经验积累）,5,1.3.1 Value,：聚焦客户,价值,，消除浪费,6,Source,：,如何提升软件开发效率,08,年统计,华为：研发版本废弃特性,07.1-08.6,年某产品线所有产品中重要特性无应用的比例达,22%,（需求变更和分析不足占,63%,）,软件业：,45%,的软件特性客户没有使用,Source,：,Standish Group,来自,5,万个软件开发项目的调查,可以工作的软件,面面俱到的文档,胜过,客户合作,合同谈判,胜过,1.3.2 Team,：激发,团队,潜能，加强协作,7,团队是价值的真正创造者，应加强团队协作、激发团队潜能。,软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本。,效率,流行度,文档,录制的视频,录制,的音频,2,人,邮件沟通,2,人,白板沟通,2,人,电话沟通,不支持问答形式,支持问答形式,业界,调查,：,50,人团队,，每人平均,30%,时间用于编码，,70%,的时间用于与其,他成员,交流。,需求变更降低比例,补充场景数,TR4,前发现缺陷比例,版本周期缩短（周数）,无线,49.36%,88,55.90%,2.82,核心网,45%,190,45.18%,3.5,网络,31%,330,42.5%,2.6,业软,30%,300,48.15%,2.1,公司平均,38.84%,908,47.93%,2.76,华为,试点调查：开发,测试拉通，效率质量改善明显,个体和交互,过程和工具,胜过,1.3.3 Adapting,：不断调整以,适应,变化,8,能够结合自身灵活应用才是真正敏捷，,不断的根据经验调整，最终交付达到业务目标的产品,软件开发是复杂不可预测的经验控制过程,随软件规模增长，需求变化呈非线性增长,响应变化,遵循计划,胜过,1.4,瀑布、迭代和敏捷的区别,9,瀑布：开发,模型,重量级：,所有需求统一步伐，全部分析完毕后再开始设计，全部设计完毕后再启动编码,重过程：有明显的过程，每个过程不重叠，界线清晰,SRS,、,HLD,、,LLD,、,Coding,、,UT,、,IT,、,ST,，开发完毕后集中转测试。,迭代：开发,模型,中量级：,需求分成多批，每批一轮迭代，每轮内都是小瀑布；每轮迭代出一个版本交付测试。,没有明显的过程。,敏捷：开发,模式,轻量级：,需求分解成更小粒度，每个小粒度需求,1,3,天实现，并立即转测试。从瀑布、迭代到敏捷，是量变引起质变。（每轮迭代结束时出版本并不是测试的开始，更多的是开发和测试共同结束点）,过程：在一个过程框架下，嵌入了很多敏捷实践，并由很强的原则进行约束。,开发模式之外，更是一种,思想、理念、文化！,10,1.,敏捷核心理念,2.,敏捷优秀实践,2.1.,迭代开发,2.2.,持续集成,2.3.,Story,驱动,2.4.,站立会议,2.5.,完整团队,2.6.,可视化管理,2.7.,结对编程,2.8.,TDD,2.9.,RCA,2.10.,演示,3.,敏捷流程介绍,目录,2.1.,迭代开发,11,什么是,迭代开发,迭代开发是将,整个,软件开发生命周期,分成多个小,的阶段（,一般,2-4,周,），,每,个阶段,都开展需求分析,、设计、实现和,测试，,每个阶段都,可以生成一个稳定和被验证过的软件,版本。,通过,将高技术风险的需求在早期迭代里实现，有助于,尽早暴露问题和及时消除,风险,。,通过提供功能渐增的产品，,持续,获得客户,反馈,，,根据反馈及时调整,，,使产品,更加符合,客户需要。,确保每次迭代交付质量，,避免形成技术债务,，,每,一次迭代,都必须建立,在,稳定的质量基础,上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地,增长并不断,完善,。,每次迭代要,邀请用户代表（外部或内部）验收,，提供需求是否满足的,反馈。,如果迭代周期已到，无论任务是否结束，也要求终止当前迭代，未完成任务放到下次迭代再做。,迭代开发的好处,迭代开发的关键点,2.2.,持续集成,12,持续集成（,CI,）,要求,团队成员经常集成他们的工作，以,验证新合入的变化没有造成任何 破坏，,通常,每人每天至少集成一次,，每次集成通过自动化构建完成,。,维护,单一的代码配置库,，每个人每天将对代码的改动提交配置库。,实现,构建自动化,-,自动的度量、检查和测试，减少了重复的人力活动,持续集成要尽量快，最好快到,5,分钟内能完成,本地构建,，,30,分钟内完成产品,提交构建,，,8,小时内完成,每日构建,。,持续集成的问题是,项目组最高优先解决的问题,。,构建成功率和频率,是衡量,CI,效果的重要指标。,每个人都较容易得到最新可正常运行的软件。,持续集成实现,“,无事件,”,局面，尽早发现项目存在的问题，减少返工。,降低风险，,在缺陷引入的时候即被发现,，缺陷容易修复,给频繁的应用部署提供帮助，随时都可能发布软件。,持续集成的好处,持续集成操作关键点,什么是持续集成,2.3.Story,驱动,13,Story,驱动是指以,Story,为交付单元进行开发、测试、发布,Story,是能够独立交付，能够被,用户,感知的最小需求,UserStory,是,Story,开发的基准，它从客户的角度描述,Story,所需要实现的功能,传统项目,：,所有功能,Story,驱动项目,：,测试,测试,Story,测试,Story1,StoryN,只一个开发,周期,，所有功能开发完成后，集成进行测试,每个,Story,为一个开发周期,，每完成一个,Story,即转入测试状态，并,与,已完成的,Story,不断集成,需求,设计,CODE,测试,2.4,站立会议,团队成员的例行沟通机制，每天,固定时间、固定地点、,不超过,15,分钟，,Team,成员全体站立参加：,从上次会议之后完成了哪些工作？,在下次会议之前准备完成哪些工作？,在工作进行中存在哪些障碍？,有哪些好的实践或学到了哪些教训？,14,增加团队凝聚力，产生积极的工作氛围,及时暴露风险和问题。,整个团队都清楚团队内部所发生的事情。,每日跟进工作进展，快速解决问题或提供帮助。,会议中禁止针对问题的讨论，如果需要讨论，将在会后进行。,会议提出的问题必须被记录，并在会后铲除障碍。,团队是在互相汇报和交流情况，,并不是向,PO,、项目经理或敏捷教练汇报。,站立会议的好处,站立会议关键点,2.4,站立会议案例,15,目的：通过站立会议,实现团队自我管理,陈述昨天开展什么工作时，以,Story,为中心，从工作对象、进展和工作质量等方面进行总结,。,比如“,昨天我开展测试,”,“,昨天我开展哪个,Story,测试，测试了多少用例，发现了多少问题，其中哪些问题比较严重值得关注”；,比如“,昨天我编码完成,”,“,完成,Story,代码写作，,findbugs,全部清零,，自测试通过，合入服务器，编码过程中，我发现某两个类有重复代码，可以优化,”,每个人都要把觉得对团队有价值的想法说出来；昨天做了什么事情，或是想到什么事情对团队有帮助；你知道哪些事情是大家需要知道的。,切忌对别人的话漠不关心、描述从燃烧图上就能看到的进度，比如昨天做某个,Story,，今天计划做某个,Story,等,会后又发现很多问题。,Team,：,系统、开发、测试、资料在一个团队内，并且全程参与,项目,团队之间采用最高效的沟通方式,面对面的沟通,角色,主要职责,PO,Product Owner,（产品所有者），负责将客户的需求信息化并传递给项目组，,代表利益相关人（如用户、,Marketing,、,用服、管理者等），对产品投资回报负责,Story,分解和澄清，确保需求理解一致,项目组内维护架构、确保设计思路一致,划分,Story,并输出迭代,backlog,，随时澄清需求,参与,showcase,、验收,story,Master,团队的教练和组织者，帮助团队正确应用敏捷实践，引导团队建立并遵守规则,组织开工会、站立会议、回顾会议,监控整个项目的进度、质量、风险,CI-CO,CI Coordinator,（持续集成协调员），负责持续集成的正常运转,2.5.,完整团队,16,HSS,质量部,PM,开发,测试,资料,CMO,(,兼,),CI-CO(,兼,),Master,PO,QA,质量保证,项目组,2.6.,可视化管理,故事墙（,展示,Story,进度,）,缺陷走势图（,展示缺陷解决进展,）,特性墙,项目组计划墙,燃尽图（,Burn Down Chart,）,17,可视化管理的好处,简单，一目了然，降低管理成本；,实时状态显示，及时暴露问题；,信息同源，使团队理解一致，提升团队,凝聚力,；,激励先进，鞭策后进，增强团队进取心。,可视化管理形式举例,2.7.,结对编程,什么是结对编程,结对编程是指两位程序员在一台电脑前工作，一个负责敲代码，另外一个实时检视。负责操作键盘和鼠标的程序员被称为“,驾驶员,”，负责实时评审和协助的程序员被称为“,领航员,”；领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。,18,有助于提升代码设计质量，大幅促进,团队能力提升和知识传播,。,帮助快速培训新手。,来自同伴的竞争压力，能起到有效的激励作用。,知识和良好的实践在两人之间共享。,结对的两人时间要同步。,结对编程要多花,15,的时间，在时间紧迫时结对是比较困难的事情。,结对编程的好处,结对编程的风险和挑战,2.8.TDD,19,Test Drive Develop,测试驱动开发，是驱动软件设计和实现的有效手段，是在有测试保证的环境下以一种简单的、增量式的方法构建软件。,TDD,可以借助测试的约束帮助开发人员在正确的时间作出正确的决策。,不需要强调一次性把代码写到最好，通过使用,TDD,和不断地重构代码和测试代码可以让软件最终满足客户需求。,TDD,五部曲,针对要新增的功能，编写测试用例（代码）。,运行测试用例不能通过。,编写产品代码，直至运行测试通过。,重构代码，以消除重复设计，优化设计结构。,执行所有用例通过。,RCA,（,Root Cause Analysis,）缺陷根源分析，目的是为了更好地做好缺陷预防,问题如何在后续迭代开发中改进和避免。,20,缺陷预防的成本最低。,RCA,和缺陷预防是,CMM,的优秀实践，希望我们在敏捷项目继续发扬光大。,2.9.RCA,Show Case,（迭代演示）,也称,客户验收,，在迭代测试阶段,PO,或测试人员,向客户代表做一个全面的演示,能及时定期地提供反馈信息,，,加强对产品的信心,，,对于客户反馈的问题可以选择在,当前迭代周期内解决或遗留到下一次迭代（也许就是下一次迭代的需求），问题一定要记录跟踪关闭。,21,2.10.,演示,演示注意事项：,不需要刻意准备，我们只演示已完成的特性,要重点关注功能，不要过多地纠缠细节，要知道参加演示的人员时间都很宝贵。,提前进行,：如果开发过程中，通过口头交流还是难以把握需求（比如界面类需求），可以在功能基本跑通时，就进行,showcase,，,以尽早获得反馈，尽早调整,。,22,1.,敏捷核心理念,2.,敏捷优秀实践,3.,敏捷流程,3.1.,实践选择原则,3.2.,敏捷开发框架,3.2.1.,迭代准备,3.2.2.,迭代,3.2.3.,发布测试,目录,RCA,?,?,?,3.1.,实践选择注意项,23,在充分理解敏捷理念的前提下，因地制定宜地选择适合的敏捷实践,站立会议,持续集成,TDD,结对编程,迭代开发,Story,驱动,完整团队,可视化管理,演示,软件公司敏捷项目，要求开展四个基本实践、三类测试活动、三类项目管理会议,四个基本实践：,迭代开发、持续集成、,Story,驱动、完整团队,三类测试活动,：,Story,测试、迭代测试、,SIT,测试,三类项目管理会议,：迭代计划会议、每日站立会议、迭代回顾会议,验收准入评估点,立项,计划,实 施,验收,发布,生命周期,可行性评估点,计划评估点,迭代,N,迭代,2,迭代,1,迭代发布评审点,.,.,发布测试,发布测试,发布测试,迭代准备,迭代开发,发布测试,3.2.,敏捷开发框架,24,3.2.1.,迭代准备,(1/2),25,组建团队,敏捷办公环境布置,可视化管理准备,搭建持续集成环境,3.2.1.,迭代准备,(2/2),26,评估项目交付范围、规模、复杂度、项目周期、准备采用哪些敏捷实践以及需要哪些培训等。,制定项目的,整体计划,（粗略的迭代计划）：根据项目人力、时间等资源，划分迭代，确定迭代轮次、每轮迭代的范围（主要包含,Story,列表）、最终,SIT,时间等。,项目初始评估、制定项目计划,项目启动会议,Story,分析、估计,项目启动是很正式的事情，由所有的利益相关人参加。,收集各职能团队的承诺，这些团队包括开发组、测试组、资料开发组、质量组、,客户,、管理组以及其它项目相关的组织。,PO,对需求规格进行分解，转换成,story,条目，设置优先级，完成,Story,的初步估计，并挑选迭代,1,的,story,完成分析。伴随,Story,要同时输出可接受,性测试用例（,Acceptance Test Case,，简称,AT,）,-,必须要通过软件开发人员、测试人员、资料开发人员、客户的评审,3.2.2.,迭代,迭代流程,27,持 续 集 成,迭代开发,迭代验收,迭代测试,需求澄清、,Story,分解,迭代计划,收尾,评估、,回顾,Story,开发过程不断重复，直到迭代计划,Story,结束,3.2.2.,迭代,迭代计划,28,PM,按照,Story,的优先级和相关度，将最佳或对客户最为重要的,Story,作为初始迭代的一部分进行规划，确定本次迭代的目标。,召开迭代计划会议,，,PO,按,优先,级,澄清本次迭代,将实现的,Story,，以,明确需求要做成什么样子、验收条件是什么,，由团队,对每,个,Story,做,估算，达成一致,，并进行认领，,故事交付计划,由故事认领人来确定，并作出承偌,。,如果会议中，团队觉得,Story,的粒度需要分解，可以对,Story,进一步的拆分。,3.2.2.,迭代,迭代开发,.,流程,29,故事开发过程不断重复，直到迭代计划故事结束,Story,分析,代码和测试码评审,测试代码，代码,准备、运行,和重构,故事,卡,AT,测试,测试用例,准备,测试用例,评审,故事测试检查表更新,故事交付检查表更新,故事,卡相关资料文档开发,资料开发人员进行同行评审,软件开发人员,评审资料原型,Story,测试,Story,签收,SDV,测试用例,自动化,测试代码评审,资料交付检查表更新,3.2.2.,迭代,迭代开发,.Story,分析,30,在开发某个故事前，,PO,、开发、测试、资料对复杂的,Story,进行一个简短的头脑风暴，,侧重,Story,如何实现以及各种测试场景,。,建议在头脑风暴之前，熟悉,story,和验收条件，开发输出,Story,设计文档,，测试输出,测试点,，然后再召开会议。,有思考后再与会，效果往往会更好。,直接澄清需求是正向理解需求，讨论测试点和实现方案是逆向理解需求,，“正向,+,逆向”能确保需求理解的更充分。,简单的,story,可以在需求澄清后直接进入编码。,会议简短高效，在座位上召开即可，一般,10,30,分钟。,31,什么是,Story,签收,？,Story,签收是,转,ST,的入口,，用于检验开发者与客户在功能理解上的一致性，签收责任人,-,开发人员（,Pair,）、故事测试人员、资料人员、,PO,3.2.2.,迭代,-,迭代开发,.Story,签收,Story,签收必须在持续构建版本上进行，不能在程序员本机环境操作。,用于,签收的,AT,（可接受性测试用例），必须是已经过团队的评审并,达成一致理解的，签收通过的基本条件是,AT,必须通过。,签收过程中,提出的,新需求,，尽量启动新的,Story,跟踪。,签收,的形式可以多样化，可以,是签收者直接,体验，也可以是开发者,演示。,Story,必须经过开发人员的自测试，才能进入签收,，正常情况下单个,Story,的签收时间是非常短暂的，大概是几分钟到十几分钟的样子。,Story,签收注意事项：,32,3.2.2.,迭代,-,迭代开发,.Story,测试,Story,测试,Story,测试是针对,单个,Story,的功能和非功能测试,，,并分析其对整个系统的影响。,Story,测试的主体是,测试人员,。,Story,测试及问题回归必须在,持续构建版本,上进行，不能在程序员本机环境操作,Story,测试出的问题，开发人员需要,停下手头新,Story,的开发工作,优先处理问题单,，以保证已完成工作的有效性及完整性。,当前的,Story,测试需要考虑与已完成,Story,的,依赖关系,。,尽量避免只能到迭代末才能提供版本给测试。,Story,测试注意事项：,3.2.2.,迭代,迭代验收,迭代测试,在完成,ST,（故事级测试）后，测试组再针对整个,迭代范围的所有,Story,（也会有针对前次迭代的回归）进行完整的功能和非功能测试。,测试的入口条件：所有,ST,通过。迭代测试,要走正式的转测试电子流。,资料开发组评审也是在迭代测试范围内进行。,迭代测试的主体是测试人员。,测试结束后需要给出测试报告。,在迭代测试期间，测试人员的重点是进行,探索性测试，重点关注非功能测试,，比如,性能测试,设计测试用例以便在探索性测试中查找缺陷，使该过程自动化,33,回看过去，分析问题、明确措施、进行改进,。,回顾会议内容：,1.,总结本轮迭代哪些地方做得好。,2.,总结本轮迭代哪些地方可以做得更好。,3.,得出最主要的改进建议（约,3,条），并在以后的迭代中持续跟踪。,34,3.2.2.,迭代,收尾,.,回顾,35,3.2.2.,迭代,收尾,.,回顾,每轮迭代末，或进展不畅时，都应召开回顾会议。,迭代回顾会议是促进团队持续改进的最有效手段。,建议议程：,开场：,致欢迎词；每个人用一两个形容词描述对本次回顾会议的期望；,分析：,回顾本轮迭代所有度量数据、图表、完成的特性、重要问题、周边评价等信息；,信息收集：,发给每人贴纸，,10,分钟写出白板上要求的内容，并自行贴到白板上,；,快速归类：,主持人发动大家一起归类；,快速分享：,主持人念出贴纸上的内容，让大家知道；,探讨,TOP,问题根因,&,解决方法：,针对,TOP3,5,问题，使用头脑风暴进行讨论，并得出措施（可以分组也可以一起讨论）；,会后跟踪：,解决措施在下轮迭代就应立即实施，努力让本轮,TOP,问题不再是下轮,TOP,问题。,准备,开会,跟踪,关键道具,3.2.3.,发布测试,发布测试（,Release Test,），有时也称,SIT,、系统验收测试,。,测试范围：所有迭代的综合测试，包括功能和非功能测试，尤其关注,性能测试等非功能测试,。,测试的主体在测试人员，要给出,测试报告,。,每次正式的,release,前,建议都要有这样的测试。,36,37,参考资料,端到端定制敏捷开发生命周期,.ppt,软件公司敏捷项目过程介绍,V2.6.pdf,敏捷参考过程,.pdf,推荐书籍,38,针对管理者：,Scrum,敏捷项目管理,KEN SCHWABER,清华大学出版社,PMPL,必读，,Scrum,理论与实践的重要奠基之作，作者是,Scrum,的缔造者。,敏捷迭代开发 管理者指南,Craig Larman,中国电力出版社,PMPL,参考手册，了解敏捷的多个流派，里面有很多的,checklist,可以参考。,敏捷估计与规划,MIKE COHN,清华大学出版社,了解优秀的计划由哪些东西组成，如何才能使计划也成为敏捷的。,人月神话,Frederick P.Brooks,，,Jr.,清华大学出版社,很多人都知道了。,针对需求分析人员：,User Stories Applied,MIKE COHN Addison-Wesley,敏捷项目需求分析人员必读。,针对系统设计、开发人员：,大规模,C+,程序设计,John lacks,中国电力出版社,经典之作，,C,程序员也应阅读。,敏捷软件开发,原则、模式与实践,Robert C.Martin,清华大学出版社,OOD,最经典的一本书，使用过程化开发语言也可借鉴其中思想。,修改代码的艺术,MICHAEL FEATHERS,人民邮电出版社,了解如何重构大型的、无测试的遗留系统。产品历史,3,年以上的开发人员必备书籍。,重构,-,改善既有代码的设计,Martin Fowler,中国电力出版社,了解重构的基本技巧和思想，编码过程中如何进行重构。,持续集成,:,软件质量改进和风险降低之道,Paul M.Duvall,等,了解持续集成的基本原则、工具和方法。,计算机程序的构造和解释,Harold Abelson,Gerald Jay Sussman,Julie Sussman,机械工业出版社 英文名：,SICP:Structure and Interpretation of Computer Programs ,麻省理工计算机系教材。,谢 谢！,