敏捷开发团队管理系列之二:程序与测试团队I

 

这是敏捷开发团队管理系列的第二篇。(之一之二之三之四

几个真实案例

这几个团队都是我自己亲身经历的团队,从质量的角度来分析敏捷团队的工作方式。

第一个是一个较为大型的团队,约有25~30人,研发一个单一产品。

这个团队在一年半的时间里边,从5个人成长为25人,其中有一半人员来自刚毕业不到半年的本科或硕士(在2001年,还很难找到“有10年经验的编程人员”);在这个团队拥有25名成员的时候,只有1~2个测试人员。

按一般的常理而言,这个产品应该面临很大的质量问题,因为这些新来者应该编写大量的缺陷,而测试人员又严重不足,不足以发现这些缺陷。

但实际情况是,这个产品是我后来经历的所有大型团队中最好的一个,包括后来拥有众多测试人员的团队;此产品运行于CCTV,属于高度实时性和可靠性的产品;此产品在上市7年左右的时候占有市场的60%份额(之后数据不详)……

第二团队个可以说是个团队,也可以说是个个人,是我之后为某家军工企业开发的一个小软件。

“无损检测系统”项目历时3.5个月,涉及步进电机、超声波扫描卡等各种软硬件,尽管就这么多人工,最后甲方说做了个“国内领先的无损检测系统”(只能说可见国内行业底子之差)。

一个人开发,当然只能自己开发自己测试,但是质量却是有史以来最好的,整个项目的测试期只有几天,而交付后一年中客户没有发现过缺陷,只在更换硬件平台后发现一个水土不服的时序问题。

这两个软件,是我自己亲自或近距离参与的项目中质量最好的两个,但奇怪的是他们都没有专业测试人员。

编程人员的降低缺陷的方法

这里先不分析编程人员与测试人员的分工、合作问题,先看看编程人员除了被“测试”之外,自己有哪些方法可以提高质量。

第一个项目的经验

在第一个团队中,由于团队很年轻扩张又很快,所以推行了代码审查的方法,简单而言,就是高手/老手要看新手的代码,后期的制度则是每个人的代码必须有人看过之后,才能提交。在这些提交过程中,很多可能带来日后维护困难或缺陷的代码都被踢了回去。

在这个团队扩张的后期,这种审查制度被凝结在师徒制度中,以把原来“帮忙”做审查变成“审查义务”。这一变化的原因是中间曾经发生过一次“不负责任”的审查,造成一大段两个月的代码未经充分审查就进入代码库,酿成后来的一次现场故障。这种“不负责任”来自于本来就没有设定责任,只是帮忙,所以才发生了组织结构的变化。

在建立师徒制度后,师傅们将对小组的成败包括质量负责。实际上,新人的流动率很高,如果留下垃圾代码,还是要师傅来维护,所以师傅“被迫”很尽责。师傅们普遍的做法是不只在最后才审查代码——因为那时候肯定面临一个烂摊子——而是在前期就指导徒弟编出良好的代码,乃至在更早的时间点介入,做出良好的设计。

这些制度后来演化成松结对编程方法

第二个项目的经验

第二个项目则是本人做度量最仔细的一个项目。

原因是在离开上一家公司后,我去了一个测试人员众多的企业,但其产品质量却奇差无比,甚至导致后来一个产品被放弃,40人因此离职。所以萌生了一个念头,就是仔细度量一下缺陷是怎么来的,又是怎样被发现的。

针对这个项目有一个100多个检查项的代码检查表,每天对代码进行30~60分钟的代码检查。在整个项目过程中一共有240多个缺陷,不过只有6个发现于系统测试期,9个发现于与硬件的集成测试,63个来自于调试(就是完成编译到按下F5调试成功中发现的问题,一般大家都是不记录的,但这个项目中也被记录下来),剩下的有112+53个来自于“看代码”(有自查和后查两种形式),这个项目没有单元测试活动。

大致结论是只有微乎其微的缺陷是由测试活动发现的,而剩下的缺陷则是由开发活动发现的

这个项目的数据还揭示出一些有价值的信息:

1. 开发人员可以有效地降低总缺陷率

在为期27天的编码期(这个项目是瀑布式开发)中,千行代码的总缺陷率趋势从第一天的130/千行降低到最后一天的60/千行,说明若开发人员能潜心消除缺陷,那么在很短的时间里就能大幅降低自己代码的总缺陷率;极少有测试活动能做到类似的效果。

2. “所有缺陷无需测试活动即可消除”

下面是当时的“过程效益”分析,所谓过程效益,就是某个过程对消除缺陷的能力。比如如果说“调试”的过程效益是40%,就是说如果有100个缺陷到达调试环节,调试中会发现其中40个,而60个会被漏到后面去。图中的蓝线就是“调试”的过程效益,注意前期的调试缺陷经常很低,表明“调试起来一切正常,但是一测试就发现很多问题”;后期的调试效益经常是100%,这个意思是说在完成调试(就是F5)后,之后再也没有任何人、任何活动从这天编写的代码中发现任何缺陷。

确切说系统测试的6个缺陷,全部发现于前13天的代码中;换一种说法:如果全程都能像后13天一样编写代码,系统测试的缺陷将为0。

“所有缺陷无需测试活动即可消除”这句话被打上引号,是因为它是一种很理想的状态。但是与“所有缺陷可以被某种测试活动消除”相比,我更相信前者。

3. 编程人员可以训练出行之有效的排除缺陷的手段

“自查”的过程效益始终没有达到100%,但是它与调试的作用越来越互补。比如在初期自查+调试后,还有大量缺陷被发现(所以调试的效益很低);但如果每天仔细分析自己自查发现的缺陷和调试发现的缺陷,就可能在短短一个半月的时间内大幅度提升自身发现缺陷的能力,乃至于到达不把缺陷留给测试环节,更不会留给客户的程度。

从上面图中的数据可以看出来,这个项目的质量不是由一个“能力很强的人”保证的,因为刚开始调试后还是有很多缺陷会留给测试活动发现,只是后来的训练导致了能力的增强。因此人的因素有,但是不是绝对的。

总结

这些项目揭示出来的规律是:程序员应该负责产品质量,他们有能力,也有时间。

第一个项目并没有因为“程序员还要负责质量”而耽误进度或造成功能“太少”影响到市场竞争力;第二个项目甲方后来坦然说“原定计划一年,没想到三个半月就结束了”(此前他们自己曾经尝试2个人研发过一年,此外也了解另外两家竞争对手投入的情况)。

很多人一定认为上述经验有很大的局限性,比如对个人能力的要求很高,其实不然。第一个项目中,那些刚毕业的本科生和研究生与今天动辄工作5、6年乃至10年的程序员的水平不可同日而语;第二个项目中我本人当时工作经验也只有8年,其中做职业程序员的时间则只有4~5年左右,编码量仅在2万行左右。

所以关键还是方法,而不是人;或者说是“使用正确方法的人”就足够了,“使用正确方法的正确的人”不是一个强制条件

在后续的章节中,会谈到如何在一般情况下,推行这些方法。

此外还会提到,在这种方法大行其道的时候,专业的测试团队是否还有必要存在,以及还有“什么用”,以及应该如何工作。

转载于:https://www.cnblogs.com/JPAORM/archive/2011/12/13/2510383.html

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值