前几天,笔者与一位在大型互联网公司从事质量保证的朋友交谈,作为互联网产品质量和测试的负责人,他最近负责的质量管理方面遇到了很多困难。主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到开发团队的认可,离职率非常高;5)质量部门无法收集到数据,不能进行质量度量;6)测试团队也有一批自动化测试专家,但派不上用场…..这些问题可能很多开发团队都会遇到,总结一下,大致是这几个方面:

}        越来越多的企业希望采用,但没有把握

}        习惯于传统的瀑布式产品开发流程已不满足快速发展需要,但大规模改动不现实

}        缺少敏捷软件开发专家和人才

}        技术人员需要观念的转变和方法培训

}        缺乏相应的质量控制方法

}        需要经常的和及时的质量度量、测试、决策

}        自动化测试不能落到实处,每日构建仍是纸上谈兵

在现在行业中,需求变化太快,不管我们怎么努力去做,发现还是不能满足客户的需要,不管需求搞得多么细,到交付产品给客户的事情,总是有这样那样的问题,这个时候就不得不去修改我们的软件,这是目前很多企业尤其是互联网公司面临的一个挑战,如何解决这个问题?

笔者先后在华为、阿里巴巴软件质量部门任职,最近也深入研究了腾讯敏捷开发平台TAPD(腾讯敏捷产品开发)和IGD(集成游戏开发)一些资料,对国内敏捷项目的质量管理有很多独到的见解,结合共创力咨询公司多年的项目经验,总结如下:

1)QA角色的转变

QA要从警察的角色转变到一个教练的角色。在以前,团队实施CMM的时候,QA更多的是一个警察的角色,他整天拿着一个checklist、报告什么的到处去团队里面看,你是否ok,不ok就要怎么怎么样,整天就干这个活,但是引入敏捷之后,QA就觉得有点失落,都敏捷了,我都不知道该怎么下手了,在著名的通信企业华为的做法是将QA转变了一下,将QA更多的充当教练的角色,充当SCRUM Master的角色,他去指导项目团队该如何去开这个站立式会议,该怎么去做迭代的计划等等指导性的工作,这样QA也觉得挺好,这样他能参与到在不同的团队中去,QA的角色更多的偏向于全过程的敏捷活动指导,以提高产品开发效率和质量。QA在这个过程中也能得到一些数据,如代码缺陷率,版本的不良率,上线遗留问题数,团队成员配合度等等。

2)要使敏捷团队整体参与

QA和测试人员也是敏捷团队的一部分,作为敏捷教练,要向他提供支持和训练,以使作们适应开发的快节奏。比如,如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独立定义故事和需求,那你应该主动站出来和团队的其他成员交流,并偿试“三方协作”,即测试人员、开发人员和业务专家。腾讯公司把业务专家称为BA,即

Bussiness Analyst, BA和开发人员DE、测试人员TE组成了敏捷开发团队,这些成员不仅仅把都在忙着最终的交付而努力,他们还乐于收集和分享信息,与客户或者产品负责人协作以帮助他们充分展示自已的需求,从而得到他们的需要的功能,同时向所有人提供项目进展的反馈。

3)              自动化回归测试。敏捷团队没有自动化会成功吗?可能也会成功,但我们所知道的成功团队都依赖于自动化回归测试,如腾讯和支付宝公司的Selenium框架,阿里巴巴和淘宝网的QTP框架。汉捷咨询认为,敏捷开发利用测试来指导开发,为了编写的代码使测试通过,需要快速而简单地运行测试,没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。

4)            提供并获取反馈

反馈是敏捷的核心价值,敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转,测试人员则通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里拿到了预期行为的正确示例?你怎么知道编写的测试用例正确地反映了这些示例?开发人员通过查看测试用例能够理解应该编写什么代码吗?QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求并是否能够指导编码,询问客户是否理解质量标准,应花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。把反馈的结构可表示为如下:

5)            构造核心的敏捷实践活动

软件行业有一名老话是:软件质量是设计出来的。对于敏捷开发也是如此,汉捷咨询认为没有一些基础的实践活动,无法产生出高质量的软件。

①持续集成。持续集成(CI)是一项软件开发实践,其中团队的成员经常集成他们的工作,通常每人每天至少集成一次,每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决,降低缺陷修改成本;将集成工作分散在平时,通过每天生成可部署的软件;避免产品最终集成时爆发大量问题。

②灰度发布。这是互联网产品的一个特点,说白了,就是对用户一个逐步放量的一个过程,而且不要求团队要尽早 的将产品包发布出来,也就是不要求马上发布给所有用户,而是会分批的去发布,比如按号段发布,比如在公司内部先体验。发布的时候也有策略,比如发布时如何放量,对用户有些什么样的实验,技术上怎样做一些后台开关,运营上怎样跟进,怎样保证4小时人员的留守,发布完后怎样收集用户反馈等等都会有一些统一的规则。比方实验室某WEB产品的发布,可以同时有多个版本,1.1版可能会有100%的用户在用,1.2版可能只有1%的用户在用,它们是一个交叉升级的过程,目前腾讯采用了该活动。

③每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。笔者在阿里巴巴工作时,就经历过每日晨会,一般主持人由敏捷团队的成员轮流担任,这个时候可以了解每天发生的问题。

④结对编程:两位程序员在一台电脑前工作,一个负责敲入代码,而另外一个实时检视每一行敲入的代码;操作键盘和鼠标的程序员被称为“驾驶员”,负责实时评审和协助的程序员被称为“领航员”;领航员检视的同时还必须负责考虑下一步的工作方向,比如可能出现的问题以及改进等。有助于提升代码设计质量;研究表明结对生产率比两个单人总和低15%,但缺陷数少15%,考虑修改缺陷工作量和时间都比初始编程大几倍,所以结对编程总体效率更高,同时结对编程能够大幅促进团队能力提升和知识传播。

⑤用户故事。用户故事是站在用户角度描述需求的一种方式;每个用户故事须有对应的验收测试用例;用户故事是分层分级的,在使用过程中逐步分解细化;典型的描述句式为:作为一个XXX客户角色,我需要XXX功能,带来XXX好处。用户故事的好处是:用户故事站在用户视角便于和客户交流,准确描述客户需求;用户故事可独立交付单元、规模小,适于迭代开发,以获得用户快速反馈;用户故事强调编写验收测试用例作为验收标准,能促使需求分析人员准确把握需求,牵引开发人员避免过度设计。

⑥迭代回顾会议。在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步;围绕如下三个问题:本次迭代有哪些做得好?本次迭代我们哪些方面还能做得更好?我们在下次迭代准备在哪些方面改进?会议需要Team全员参加,气氛宽松自由,畅所欲言,头脑风暴发现问题,共同分析根因;会议关注重点是Team共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。

总之,共创力咨询认为,测试和质量是整个敏捷团队的职责,团队中的每一个人都应该关注手边的一个任务或者故事,敏捷模式下的质量管理更具有挑战性,但与传统瀑布模式相比,其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于持交付有价值的软件让一直到客户满意为止。在这个“快鱼吃慢鱼”时代,要想交付好而快的产品,不防用敏捷模式试试。

敏捷开发模式下的质量管理相关推荐

  1. 敏捷开发模式下如何更好的进行测试

    最近CTO组建了一个敏捷开发团队,团队人员包括  PM.设计.开发.测试角色,主要由PM来主导团队走向,因为以前并没有参加过敏捷开发的经验,对敏捷开发做了简单理解后,参考了前人的一些意见,总结出在 敏 ...

  2. 敏捷开发模式下如何用 PingCode 这类工具进行版本发布管理

    在软件团队工作中,版本发布要达到好的发布效果,需要在版本发布前做好版本发布的规划,并对发布流程和进度进行管理 准备工作: 您已经创建了一个 PingCode 帐户[快速注册入口] 您创建了一个 Pin ...

  3. 《超越需求:敏捷思维模式下的分析》—第1章 1.1节简介

    本节书摘来自异步社区<超越需求:敏捷思维模式下的分析>一书中的第1章,第1.1节简介,作者[美]Kent J. McDonald(肯特 J. 麦克唐纳),更多章节内容可以访问云栖社区&qu ...

  4. 前后端分离开发模式下后端质量的保证 —— 单元测试

    概述 在今天, 前后端分离已经是首选的一个开发模式.这对于后端团队来说其实是一个好消息,减轻任务并且更专注.在测试方面,就更加依赖于单元测试对于API以及后端业务逻辑的较验.当然单元测试并非在前后端分 ...

  5. ultraedit 运行的是试用模式_单元测试 —— 前后端分离开发模式下后端质量的保证...

    概述 在今天, 前后端分离已经是首选的一个开发模式.这对于后端团队来说其实是一个好消息,减轻任务并且更专注.在测试方面,就更加依赖于单元测试对于API以及后端业务逻辑的较验.当然单元测试并非在前后端分 ...

  6. 瀑布开发模式和敏捷开发模式的区别和思考

    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等. 使用里程碑的方式,严格定义了 ...

  7. CMMI与敏捷开发模式

    1)  CMMI 开发模式 优点是开发流程制度化和重视过程(设计,文档,编码,测试,原因分析),强调项目的可控性( Risk 管理),缺点是开发周期长,灵活性差. CMMI 体系适用范围的特征:产品  ...

  8. 在Scrum开发模式下,为Sprint起名字的艺术

    在过去的几个月中,我们在每个 Sprint 计划会议 上,都会花上几分钟的时间,一起为当前的Sprint起名字,现在回顾一下,还是非常有意思的. ---敏捷精灵 看一下我们为项目A起的Sprint名字 ...

  9. 网上商城代码实现_中国中铁网上商城转型敏捷开发模式,实现快速反应、快速迭代...

    △北研中心的同事给业务部门演示迭代成果中国中铁网上商城成功转型敏捷开发模式,实现快速反应.快速迭代.切实解决公司内部以及合作方的业务需求,更好服务多样化的客户群体.经历了两次每2周为一迭代的短期快速开 ...

  10. 《超越需求:敏捷思维模式下的分析》—第1章 1.2节交付价值

    本节书摘来自异步社区<超越需求:敏捷思维模式下的分析>一书中的第1章,第1.2节交付价值,作者[美]Kent J. McDonald(肯特 J. 麦克唐纳),更多章节内容可以访问云栖社区& ...

最新文章

  1. 找出前50个素数,构成素数表
  2. C标准库和glibc(C运行库)的关系
  3. iOS开发事件分发机制—响应链—手势影响
  4. 服务器网站管理页面打不开解决方法
  5. iOS clang: error: linker command failed with exit code 1 (use -v to see invocation)
  6. CentOS下使用TUN/TAP虚拟网卡的基本教程
  7. 190929每日一句
  8. python界面打开为什么是黑的_Pycharm设置界面全黑的方法
  9. 创意简单html游戏,创意绝佳趣味慢慢的网页互动小游戏
  10. android 仿微信demo————微信顶部操作栏搜索按钮实现(查询通讯录好友功能)
  11. linux 驱动安装带参数,【转】Intel Linux显卡驱动安装指南
  12. Latex中使用thebibliography环境时去除“参考文献”标题方法
  13. mars老师Java教程百度网盘,你一定不能错过
  14. oracle 执行计划耗时,oracle各种执行计划优缺点
  15. R语言把DataFrame的一行变成向量
  16. 1307:【例1.3】高精度乘法
  17. php 和 photoshop,pscc和ps有什么区别
  18. 9.HTML基础——列表标签
  19. 非线性方程求根方法总结附代码(从二分法、试位法到牛顿迭代、二次插值等)
  20. 硬盘函数不正确怎么解决

热门文章

  1. 如何判断电脑已感染“磁碟机”病毒?
  2. Windows桌面软件美化界面:分享著名的VC++ DirectUI/duilib/SOUI/REDM,IMGUI和C#开源界面库
  3. 实时数仓入门训练营:Hologres 数据导入/导出实践
  4. 快解析v6.5.3版本,添加端口映射教程
  5. jane street market prediction 冠军方案 经验分享 (1/3)
  6. m序列产生原理及其性质
  7. VC++即时通+视频会议源码
  8. 雨笋教育干货分享:0day漏洞利用及抓取的姿势
  9. 如何给三线表格(图片)添加标题?
  10. 高校机房建设 云服务器 终端,学校云机房建设使用NComputing微型终端机解决方案...