敏捷质量管理.pptx

Scrum由来Scrum:scrum的由来Scrum中基本概念Scrum的实施Scrum迭代模型以及Scrum的角色及其作用Scrum的实施.需求以及功能点的管理项目的规划以及backlog的管理项目具体的实施项目测试的管理时间的管理Scrum MeetingDemoScrum的改进总结Scrum的由来—由瀑布等传统开发模型的弊端提出敏捷开发方法瀑布模型是由Royce在1970年提出的,他把大型软件的开发分为分析与编程.瀑布模型的弊端: 1). 强调文档性:导致了往往要到开发的后期,才能看到软件的模样.为软件的开发极大的增加了风险性. 2).没有迭代与反馈:导致了无法应对客户的需求变化. 而在当今ERP盛行的软件市场里面,由于市场带动的软件需求变化和软件初期客户对需求描述的不清楚,都为瀑布模型的使用带来了困难. 3).采用瀑布模型开发的软件,极大的带来了更改的成本结果:我们需要一种能够针对需求变化作出快速有效反馈并且能够让客户在短期内看到软件模型,减少风险的开发方法-------Agile{Scrum}敏捷开发方法的前身是轻量级开发方法(Lightweight methods)—针对传统的重型开发方法(传统的瀑布开发方法)Scrum开发方法是由Jeff Sutherland在1993年创立Scrum的骨架和核心:Scrum的所有实践都围绕一个迭代,增量的过程骨架展开SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个 什么样的开发框架呢？简单说，它由（Meeting），三项工件（Artifact）组成三个角色（Role），三种会议Scrum迭代生命周期项目具体的实施开发按照自己在当前所属的sprint中找到自己需要完成的New Feature以及Defect.通过每天的努力,修改任务状态,包括打开或者关闭,包括实施时间的具体信息Sprint Based Development Cycle需求设计文档不充分测试计划和测试报告不能覆盖项目敏捷测试要求测试员与开发人员、用户充分交流和沟通，面对面的沟通Scrum步骤测试 服务对象改变有顾客转变为开发组（这里我们的项目组需要转变）敏捷测试原则和开发方式1 测试驱动开发(TDD)Junit 单元测试工具2增量版本发布(Incremental Publish)注意里程碑3?FIT（Framework for Integrated Test）TestLink,Concordion 使用4 验收测试seleniumTips提示1、测试工作不仅仅由测试人员担任，其他项目组成员也承担了部分的测试工作。那么对测试的质量度量模式可能就要发生改变了。2、沟通仍然是项目组不变的主题，但是沟通的方式更多地侧重在口头、面对面方式的交流。那么对沟通的质量度量模式可能就要发生改变了。3、迭代、快速发布、重构等软件开发方式对如何进行配置管理的控制提出了新的要求。总结敏捷项目管理代表了一种软件开发思想的回归，软件的本质是为用户提供价值，为用户解决问题。所有软件工程的活动都是围绕这个核心思想来进行的。极限编程、测试驱动、SCRUM等等，都只是为了突现软件活动中的某方面的重要性而提出的，但其核心都一样。个体和交互、能工作的软件、顾客合作、快速响应变化，这些原则毫无疑问会使传统的质量保证工作方式发生改变。很多质量保证的手段和方式可能要发生剧烈的改变，但是至少有一样东西是不变的：质量保证的目的仍然是确保交付产品的质量敏捷开发VS传统开发敏捷项目开发对开发阶段没有什么重要的分割,没有前期的需求阶段,分析阶段,架构设计阶段,编码测试阶段等在项目开始时,每次迭代都会同时进行所有上述阶段工作敏捷开发的多米诺效应敏捷开发的链式反应远远强于传统开发在整个项目开发阶段,必须保证业务人员和开发人员天天在一起工作信息传递发生该改变与传统开发相比,离岸外包大团队一般多使用文档交流,而小团队面对面交流更经济面对面交流的有效性评估有的在面对面交流过程中确实无法表达确切这样补充一定的文档精确描绘问题,问题解决后编写详尽的描述文档,以后备查敏捷可持续开发敏捷提倡可持续软件开发,不赞成抖动(开发节奏不均匀)开发不断关注优秀的技能和好的设计敏捷软件开发-原则，模式与设计Review和Introspect团队会在如何才能更有效的进行工作方面进行反省,然后相应的对自己行为进行调整敏捷是过程关注敏捷带给大家的价值敏捷没有终点我们一直在路上