敏捷模型
前面的那些模型以前非常流行,但现在开发人员在使用的时候会遇到各种问题。主要困难包括在项目开发期间处理来自客户的变更请求,以及合并这些变更所需要的高成本和时间。
- 在实际工作中,一款产品的功能是不断在变化的
所以为了克服这些缺点,就提出了敏捷软件开发模型。在敏捷模型中,需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。
- 敏捷模型主要旨在帮助项目快速适应变更请求。因此,敏捷模型的主要目的是促进项目的快速完成
- 敏捷性是通过是过程适应项目,删除对特定项目可能不是必须的活动来实现的
- 避免任何浪费时间和精力的事情
敏捷模型中有一个非常重要的《敏捷宣言》:
- 个体与交互重于过程和工具(强调高效沟通)
- 可用的软件重于完备的文档(强调轻文档,文档不应该作为工作验收的标准)
- 客户协作重于合同谈判(主动了解当下的需求)
- 响应变化重于遵循计划(能够主动迎接变化)
总结出敏捷模型的四个特点:轻文档、轻流程、重目标、重产出
scrum
敏捷开发有很多种⽅式,其中 Scrum
是⽐较流⾏的⼀种。在 Scrum
模型中,主要有三个角色和五个重要会议
三个角色
product owner
(产品经理)负责整理user story
(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。收集需求,产出软件需求文档scrum master
(项目经理)负责召开各种会议,协调项目,为研发团队服务。team
(研发团队)则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品。
迭代开发
与瀑布不同,Scrum
将产品的开发分为若干个小 sprint
(迭代),其周期从 1 周到 4 周不等。参与的团队一般是 5 到 9 人。每期迭代要完成的 user story
是固定的,每次迭代会产生一定的交付
五个重要会议:
- 产品负责人负责整理
user story
(用户需求),形成product backlog
(需求列表) - 发布计划会议:
product owner
负责讲解user story
,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story
列表,sprint backlog
- 迭代计划会议:项目团队对每一个
story
进行任务分解,分解的标准是完成该story
的所有任务,每个任务都有明确的负责人,并万策划那个工时的初估计 - 每日例会:每天
scrum master
召集站立会议,团队成员回答昨天做了什么,今天计划做什么,有什么问题 - 演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由
po
整理,形成新的story
- 回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,以达到持续改进的效果
敏捷中的测试
轻文档和快速迭代
- 敏捷模型中强调轻文档,所以测试人员不应使用传统的
Excel
填写测试用例的方法,更多的是使用思维导图、探索性测试(强调自由度,设计和执行同时进行,根据测试结果不断调整测试计划)、自动化测试等 - 敏捷讲求合作,在敏捷项目组中,测试人员应主动跟开发人员了解需求、讨论设计、一起研究
bug
出现的原因
测试模型
V 模型
- V 模型中,明确的标注了测试过程中存在的不同类型的测试
- 右边的测试,都需要参考左边对应高度的要求
缺点:
仅仅把测试作为在编码之后的一个阶段,未在需求阶段就介入测试。缺点和瀑布模型一样
W 模型(双 V 模型)
V
模型中未将测试前置的问题在 W
模型中得以解决
- 开发 V 模型并不是单单指编码阶段,而是为产品开发流程而实施的各个阶段
- 测试的对象不仅是程序,需求、设计等同样需要测试,测试与开发时同步的
缺点:
- 去求、设计、编码等活动被视为串行的
- 测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作
- 重流程,无法支持敏捷开发模式。对于当前软件开发复杂多变的情况,W 模型并不能解除测试管理面临着困惑