质量保证系列课件-敏捷项目过程介绍(V).pptx
质量保证系列课件敏捷项目过程介绍,2011年3月,2,目录,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,团队是价值的真正创造者，应加强团队协作、激发团队潜能。软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本。,业界调查：50人团队，每人平均30%时间用于编码，70%的时间用于与其他成员交流。,华为试点调查：开发测试拉通，效率质量改善明显,1.3.3 Adapting：不断调整以适应 变化,8,能够结合自身灵活应用才是真正敏捷，不断的根据经验调整，最终交付达到业务目标的产品,软件开发是复杂不可预测的经验控制过程,随软件规模增长，需求变化呈非线性增长,1.4 瀑布、迭代和敏捷的区别,9,瀑布：开发模型重量级：所有需求统一步伐，全部分析完毕后再开始设计，全部设计完毕后再启动编码重过程：有明显的过程，每个过程不重叠，界线清晰 SRS、HLD、LLD、Coding、UT、IT、ST，开发完毕后集中转测试。迭代：开发模型中量级：需求分成多批，每批一轮迭代，每轮内都是小瀑布；每轮迭代出一个版本交付测试。没有明显的过程。敏捷：开发模式轻量级：需求分解成更小粒度，每个小粒度需求13天实现，并立即转测试。从瀑布、迭代到敏捷，是量变引起质变。（每轮迭代结束时出版本并不是测试的开始，更多的是开发和测试共同结束点）过程：在一个过程框架下，嵌入了很多敏捷实践，并由很强的原则进行约束。开发模式之外，更是一种思想、理念、文化！,10,目录,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：系统、开发、测试、资料在一个团队内，并且全程参与项目 团队之间采用最高效的沟通方式面对面的沟通,2.5.完整团队,16,HSS质量部,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,目录,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可以在需求澄清后直接进入编码。会议简短高效，在座位上召开即可，一般1030分钟。,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问题根因&解决方法：针对TOP35问题，使用头脑风暴进行讨论，并得出措施（可以分组也可以一起讨论）；会后跟踪：解决措施在下轮迭代就应立即实施，努力让本轮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 麻省理工计算机系教材。,谢 谢！,
