码迷,mamicode.com
首页 > 其他好文 > 详细

关于敏捷开发Scrum(二)

时间:2020-05-28 23:25:35      阅读:80      评论:0      收藏:0      [点我收藏+]

标签:代码审查   关系   集中   新手   企业   互动   不容易   它的   证明   

敏捷开发团队管理 

本系列会专门从团队管理的角度,一方面将曾经提到过的内容加以贯穿,另一方面则会提及之外的一些未提及的内容,

比如产品团队与开发团队的互动,测试团队与开发团队的关系与工作方式,等等,以供专门从事团队管理的读者借鉴。

 

出发点:结果导向

敏捷开发团队的外在行为是“结果导向”,而内在支撑则是“团队工作”(TeamWork)。

所谓结果导向,就是直指结果,而不拘泥于形式。

可以被拘泥的“形式”各式各样,比如方式、方法、流程、文档、部门、分工、职责……都是形式。

这些形式本来是设立来帮助实现更好的结果的,但是如果拘泥于此,则可能起到反作用。

如果仔细审视敏捷宣言中右侧的内容,就会发现他们都属于形式,而非结果:

  • 个体与交互 重于 过程和工具
  • 可用的软件 重于 完备的文档
  • 客户协作 重于 合同谈判
  • 响应变化 重于 遵循计划

这些形式曾经保证了众多早期军工、航天、航空项目的成功,但若在任何行业任何项目——比如敏捷开发出现时的互联网行业——拘泥于此,就可能导致失败。

可怕的是,左侧的4条,也是形式而非结果。所以对敏捷宣言的正确理解是:在现今的多数行业中,如果以结果导向为出发点,则左侧的形式胜过右侧的形式。

 

支撑点:团队工作

为什么说团队工作利于结果导向的实现?

有一个兄弟射雁的例子可以说明:三个兄弟看着大雁飞过,一个说要射下来烤着吃,一个说要炖着吃,另外一个则要炒着吃,三人争执不下,大雁都飞走了。

比如有一个Bug,人们不去分析怎样改正怎样预防,而是讨论是谁的责任;比如有一个任务,人们不去分析怎样做最快,而是讨论应该谁做;

比如有一个变更,人们不去分析变更前后甲乙方是否有利,而是讨论应该哪些部门走怎样的流程;

比如有一个产品,人们不去分析怎样做才能成功,而是讨论成功后应该怎样考核……就很难直指结果,而陷入部门和个人的纷争之中。

这里倒不是说后者不需要考虑,而是说出发点问题。如果思考问题的第一念头是“我”“我们”“他”“他们”,那么团队协作就建立不起来,敏捷开发也做不好。

 

几个真实案例

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

 

第一个是一个较为大型的团队,约有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万行左右。

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

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

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

 

测试团队的价值

这样看来,敏捷开发的质量保证问题,都被发开团队解决了,测试团队的价值何在?

这个可以从第一个项目组后来的发展来分析。

在整个程序团队大力保证产品质量的同时,项目组也一点点显露出一些问题。

比如每个模块的质量都还不错(有些模块甚至有一些原始的自动单元测试脚本,每次都能对模块进行回归测试),

但是整个产品最终集成后,是否能如期完成业务要求,却是未知的。因为各个模块的测试都集中在各模块的质量上,

对于所有模块凑在一起的工作结果,却无法验证。而且在原来的团队体系下,师徒团队各自负责一个模块,居然没有人为此负责。

所以我们很需要一个人来团队里边,把整体集成及集成后的测试抓起来。这种工作,与其说是传统的面向质量的测试工作,

不如说是一种面向验证的测试工作。就是只要能告诉我们集成在一起是可以工作的,目的就达到了。

 

测试团队的“发展”

这里边有很多戏剧性的过程。

首先过了一段时间,测试经理(虽然测试组当时只有2个人)想招几个人,原因是要写很多介于代码和脚本之间的语言,来仿真业务。

为什么说是仿真?原因是我们的产品之外,还有一个“订户管理系统”,这个系统的数据,是我们的业务。

但由于他们部门的产品也在开发中,所以我们不得不先手工形成一些仿真业务。

这个问题,后来被开发组的人解决了。因为他们编写了一个文本的脚本语言,只需要手工写一些人眼很容易看懂的英文缩写和数字,就能仿真一些业务。

这个脚本语言及其编辑、调试器后来越做越复杂(但因为开发它的开发人员对内部业务很熟悉,所以只花费了前后2周左右的时间),能够自动运行、单步运行、设置断点调试。

有一次,两个测试人员在2天里用脚本编辑器编写了144个测试用例,每个测试用例包含5~128个购买和分组行为,来仿真和测试他们认为可能的各种排列组合。

这些测试用例不是我们常常遇到的写在Word或Excel里边的那种,而是用那个脚本编辑器打开,按F5,就会自动执行并吐出结果的那种。

这个工作如果由人力来完成,无论是编写测试用例,还是执行以查看结果,都是几乎不可想象的。

两个测试人员有一次希望大干一番,以便验证一些不是有意构建的用例是否可以通过测试。

但最终结果是,这个编辑器和调试器后来被发展成能自动生成测试用例,乃至将用例发给真实机顶盒+IC卡系统和一个仿真的机顶盒+IC卡系统(一个友好的可以F5调试的VC++系统),

如果发现区别则自动记录,并继续产生下一个用例。

这段代码因为走的时候没有留下文档而失传了,不过在7年后的一次老同事聚会中了解到,团队在后续的几年中按照这个原理,

把很多不同层次的硬件(数字电视里边的,大约有10种之多,个个都是黑底绿字乃至干脆没有屏幕的,非常难缠)都做了纯软件仿真,

每个模块做好了,都可以扔进去和仿真硬件集成一番,这些工作大大缩减了最后真枪实弹时候经常出现的莫名其妙的问题,大大缩减了集成和测试时间。

这些程序人员的工作成果,保证了在团队有25人的时候(峰值曾经到达30人),只要两个测试人员就能完成整个系统的功能测试,这个团队发展十分“缓慢”;

但是从另外一个角度看,那些为测试团队编写测试代码的人,到底算是开发人员还是测试人员呢?

 

启示

一个优秀的团队,应该受到关注的应该是质量的高低问题、集成的效率问题、功能验证的效率问题……这些有人买单的问题,

而不是开发与测试的分工、如何明确责任、如何对双方进行绩效考核等没人买单的问题。

所以尽管2001年那个时候敏捷开发的概念还不太清晰,但是本着“无我无人”的精神(详见般若敏捷系列之四),很自然地创立了自己的敏捷方法。

这件事情让我回忆起最近正在与很多业界人士合著一本“敏捷开发案例集”,中间有一个讨论时:“到底什么案例是敏捷案例,什么案例不是敏捷案例?”

最后的结论是:“第一个很松:大致有点和敏捷沾边就行;第二个很严:开发方法一定要被证明是优秀的”,换言之如果大家对优秀的开发方法视而不见,而到处找“敏捷开发方法”,就是舍本逐末了。

下一篇,将谈及开发团队的测试团队的组织关系问题,比如专业的测试团队好,还是分散到开发团队中的测试团队好,抑或还存在其他的组织结构等。

整体上有两种测试团队的模型,既然都有存在,自然是各有各的道理。城里城外的人倒不必互相羡慕,只是要观察对面的优点,分析自己的缺点,尝试做点事情补偿一下。

所以,下面多说一点各自的坏处。

 

独立的测试团队:

这个就是著名的与程序团队打架的测试团队。

好处:

独立团队,还是能保证一定的“公正性”的,比如在测试的最终,横竖有人能不屈从于程序团队的要求隐瞒产品质量,而是的确会客观地评价质量。

坏处:

当测试团队完全独立于开发团队的时候,常常有几个误区。

1. 程序团队是用来开发功能的,测试团队是用来查找缺陷的

有了这个认识,要让两者打架就不难了。

2. 更多的测试人员=更高的质量

很多公司拥有惊人的测试人员比例,程序和测试基本上能到1:1,这个已经接近了造航天飞机的水平(50:80),但是质量……一般缺陷率都能达到航天飞机的一万倍左右。

1和2是互相促进的,一旦拥有了1的认识,程序团队就对质量不太在乎了,因为后面有人负责测试,有Bug漏掉还要承担责任,

所以自己只管按自己的兴趣编写代码就是了;而留下的缺陷越来越多,自然就需要更多的测试人员来解决。

 

分散的测试团队:

好处

每个团队都有测试人员,自然测试活动会被当作家里的事情来看待,有机会在很早的时候就启动测试活动;

由于没有后继的测试活动了,也没有人可扯皮了,所以组内的测试活动的效果会比较好。

坏处

常常有这样几个误区。

1. 人员不能共享,测试人员不足

基本出发点,还是认为这几个测试人员是来帮助解决缺陷问题的,因此他们极有可能成为局部的捡垃圾者。

由于只能调用自己的测试人员,当然逐渐地几个人就不够用了,也需要更多的测试人员。

2. 缺少总体质量的把关者

由于所有测试人员都被当作小组的负责质量的人,产品最终所有模块集成在一起的时候,质量由谁负责,就成了个问题;集成后如何验证整体业务(而非技术),也是个问题。

 

F型测试团队:

这是本人“次喜欢”的一种模型。

如果历史问题已经形成,或者说不可能拆分掉专业测试团队,可以考虑这个形状。

F的两个横线,代表分散的测试团队,就是整体上测试团队的人员在项目成立时,分别被指派到程序团队中,协助在早期就提升质量。

而竖线,则表明他们定期向测试经理报告各小组的的进展,分散到各小组的几个测试人员之间也可以频繁通气,以便做好集成准备;

并在几个小组都完成了内部的工作时,很方便地接管集成和整体测试工作。

好处

是当团队使用敏捷开发的迭代交付的时候,这几个测试人员还是可以进行很好的持续支持的,比如完成一个版本,就测试一个版本。

由于他们长期在项目组内工作,而且定期通气,所以接管系统测试会变得非常顺畅。

坏处

这个模型有些矩阵式的团队的确在用,不过需要很好的管理,确切说是文化,才能做好。

个人感觉在操作这种团队的时候,整个大项目的经理(同时管理开发和测试的),必须要有很强的管理能力,并随时防止程序团队和测试团队分化。

实际上在很多时候,领导的作用都不再是管事,而是管人,就是如何管理好多个团队之间的关系。

 

小型测试团队:

个人感觉最容易驾驭的团队。

比如有20个人,4~5个程序团队外加1个测试团队。

每个程序团队都各自负责自己的质量(不派驻测试人员),而那个测试团队则只负责业务层面的测试或称为验证,不负责质量。

好处

这种团队基本上是前面那个案例1(参考I和II)中的团队模型,由于当年的团队非常成功,所以非常推荐。

这种团队的集成活动是由开发团队和测试团队一起完成的,两者都为此负有责任;但完成集成后,由测试团队自己做系统级的业务测试。

整体上,是一种很“无我”的敏捷团队。

坏处

这种团队只在上面提到的那个公司见过一次,之后的团队似乎都没有采取这个形式的,表明这种形式不容易自然形成。

不过,鉴于当年的效果如此之好,本人一定会在自己未来的团队中采用这个模型。

而实际上每个公司,与其在那些很容易组建但同时很难做好的团队模型中挣扎,不如去尝试一下真正效果好的团队模型。

很多人都很希望找到一种很容易做到,效果又好的模型(以及任何其他东西)。如果这种模型存在,全国人民都别炒房了,都来开软件公司吧。

 

关于敏捷开发Scrum(二)

标签:代码审查   关系   集中   新手   企业   互动   不容易   它的   证明   

原文地址:https://www.cnblogs.com/ZJOE80/p/12787359.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!