51Testing专访陆颐怡:测试人员应该如何参与敏捷
专访人物
人物简介

         陆怡颐,曾就职于上海航空航天计算机技术研究所,从事火箭、卫星、导弹嵌入式软件测试;担任过华为测试部质量代表,芯片部质量代表,产品线敏捷开发推行负责人,参与过两个大产品的质量工作;

        之后曾任酷宝网络质量经理,建立自动化测试及持续集成;并曾在银硕科技担任质量经理,负责建立测试及OA团队;现任51Testing高级讲师,主攻敏捷测试。

采访内容
了解和认识敏捷

51Testing:您是从何时接触和认识敏捷的呢?

陆怡颐:08年的时候,华为公司开始大规模推行敏捷开发,我有幸参与其中,成为所在产品线敏捷推行的责任人。通过在敏捷能力中心系统学习了敏捷开发,也接触了业内的一些敏捷专家。09年我所在的产品线也正式开始推行敏捷,我带了两个试点项目,开始实践敏捷,过程虽然曲折, 倒是让我认识到了实践敏捷过程中的很多实际问题。[查看原文]

51Testing:在您看来,什么是敏捷开发呢?

陆怡颐:从起源来讲,敏捷其实就是一伙程序员被繁重的过程模型所束缚,为了能跳出来, 而聚到一起发表的一份宣言。其实敏捷开发就是这一份宣言中强调的四条价值观:

● 个体与交互比流程和工具更有价值
● 可用的软件比冗长的文档更有价值
● 与客户的协作比合同谈判更有价值
● 对变化的响应比遵循计划更有价值

我们要正确认识敏捷,就要从这四条价值观触发。切忌把敏捷当做一种超越了瀑布、V&V等传统模型的新模型,只要照着它的流程做就会如何如何。

我从3个层次认识敏捷,首先是理念层次:敏捷是一种思想,帮助我们跳出传统的模型束缚,解决积累的管理问题。当然它并不空洞,有很多具体的操作可供我们参考(敏捷实践)。
我把敏捷的四条价值观总结为3个敏捷理念——聚焦客户价值、加强团队协作、响应变化。

所谓聚焦客户价值,需要做到:
1、标识和消除软件开发中的浪费
2、交付刚刚好的系统
3、随时构建质量,不容忍缺陷
4、及时消除技术债务,持续保持快速响应

所谓加强团队协作,需要做到:
1、认清团队的基本事实
2、敏捷方式下的管理者转变
3、敏捷方式下的团队成员转变[查看原文]

51Testing:不管开发还是测试,对写文档都很头痛,那么敏捷开发中,是不是就可以不用再写文档了呢?

陆怡颐:其实我们不能从这个角度看文档。敏捷创始人之一罗伯特马丁说过他的敏捷12条原则,其中一条就是“除非有必要,否则不需要写文档”。很多人误解了这句话,所以很多公司实践敏捷的时候,就是不写文档了。我把这种项目称为“裸奔”。

罗伯特马丁这条敏捷原则其实是告诉我们,重新去审视文档的作用。文档的作用是什么?我总结为三个词:沟通、承诺、传承。那需求文档举例,需求说明书是干嘛的?是和产品和客户沟通、开发和测试沟通的,同时,也是对客户的一份承诺。这是一份非常重要的文档,所以是无法用口口相传的方式承载的(你不能和客户空口说白话),需求是必须文字化的。但我们不一定按照V&V的需求模板来写,文档格式有时候也是一种负担,我们可以应用更灵活的文字记载需求,比如SCRUM/XP流派都应用的优秀实践——用户故事。[查看原文]

有效实现敏捷开发

51Testing:敏捷开发在公司里面应该怎么推行呢?

陆怡颐:这个话题就大了,简单说,推行敏捷一定要弄清楚,公司目前整个产品开发面临哪 些问题,可以围绕价值、团队、变化这三个核心来分析,获得公司最高层

推行敏捷并不是一、两个部门的事情,而是牵一发动全身的,它会涉及到业务部门的工作方式的变化、产品需求设计的变化、组织结构的变化、绩效引导的变化、文化的牵引,这是系统工程。需要自上而下的力量。

其实从我个人角度讲,公司一下子就要全面推行敏捷开发,风险是很大的。倒不如先“低调”行事,只考虑公司产品开发面临的问题,然后借助一些有效的敏捷实践来进行改进[查看原文]

51Testing:您觉得众多敏捷实践中,哪些实践最容易看到正面效果呢?

陆怡颐:这个不好回答,因为这和公司的具体情况有关系。还是那句话,敏捷是思想,它是解决问题的。如果硬要回答,那么这么来说吧,我把敏捷实践大致分为两大类,分别是管理类实践,比如每日站会、状态墙、迭代验收、回顾会议等等,以及技术类实践,比如持续集成、测试 驱动开发、重构等等。很多公司喜欢优先考虑做管理类实践,觉得容易实现。

但是我却觉得,优先做管理类实践虽然好做,但是能看到的效果很有限。敏捷开发,它毕竟是一群程序员想出来的,所以更加偏技术一些。如果看过马丁那本《敏捷软件开发:原则、模式与实践》的,应该还有印象吧,他大量的篇幅都是讲的技术实践,这是最根本的东西,缺了这个, 上层就站不住脚。公司不妨优先尝试测试驱动开发和持续集成。[查看原文]

51Testing:很多公司这几年都在推行敏捷开发,但是从效果来看,收效甚微,您认为原因是什么呢?

陆怡颐:原因当然是多方面的,但是我觉得最根本的是东西方价值观的差异。敏捷是国外一群研发人员搞出来的,所以带有很多西方特色。举个例子,关于敏捷的团队概念,在一个敏捷团队中,并不设置leader,而主张团队自运作自管理,团队依靠设置团队规则运作,产品负责人仅 仅设置团队目标。国内可能很难理解,团队没有leader不就全乱套了吗,他们会不会偷懒?其实这是典型的y理论管理原则。这里可以简单谈一下道格拉斯·麦克里戈的著作《企业的人性面》一书中提出的xy理论。

所谓x理论,或者说x假设,说的是:
1、多数人天生是懒惰的,他们都尽可能逃避工作;
2、多数人都没有雄心大志,不愿负任何责任,而心甘情愿受别人的指导;
3、多数人的个人目标都是与组织的目标相矛盾的,必须用强制、惩罚的办法,才能迫使他们为实现组织目标而工作;
4、在人群中广泛存在着高度的想象力、智谋和解决组织中问题的创造性;
5、在现代工业条件下,一般人的潜力只利用了一部分。

国外的管理理论一直以y假设为主,而国内我们习惯了以x假设来指导企业管理。我们的领导都习惯了事无巨细的管理,用绩效考核鞭策员工。员工也习惯了被动接受任务的指派。[查看原文]

51Testing:测试人员应该如何参与敏捷呢?

陆怡颐:敏捷开发本身没有对测试人员有明确的定位,从用户故事、结对编程、测试驱动开发、持续集成、迭代验收这些实践来看,测试人员可以参与用户故事中关于定义完成的部分,为了能够做到持续集成,测试人员在开发进行编程的同时,可以进行自动化测试用例的设计和实现,如果有一定编程能力,也可以参与结对编程。最后也可以主持迭代验收。但是不管从什么角度讲,测试人员要参与敏捷,都需要有比较过硬的技术才行。

举个例子,敏捷开发的迭代节奏非常快,而且持续集成要求测试必须可以反复的执行,所以测试自动化的要求诉求非常大,但是在敏捷开发过程中,我们不能采用录制回放的方式进行自动化测试,录制回放是回归测试的做法,必须等待可测软件编码已完成,但这种做法对快节奏的迭代来说太没效率了,会拖长迭代周期。测试的自动化用例实现必须和被测软件编码是同步进行的,这样才能在持续集成中每天都有新集成[查看原文]