敏捷开发团队管理.docx
- 文档编号:26754169
- 上传时间:2023-06-22
- 格式:DOCX
- 页数:11
- 大小:22.73KB
敏捷开发团队管理.docx
《敏捷开发团队管理.docx》由会员分享,可在线阅读,更多相关《敏捷开发团队管理.docx(11页珍藏版)》请在冰豆网上搜索。
敏捷开发团队管理
敏捷开发团队管理
本系列会专门从团队管理的角度,一方面将曾经提到过的内容加以贯穿,另一方面则会提及之外的一些未提及的内容,比如产品团队与开发团队的互动,测试团队与开发团队的关系与工作方式,等等,以供专门从事团队管理的读者借鉴。
出发点:
结果导向
可以被拘泥的“形式”各式各样,比如方式、方法、流程、文档、部门、分工、职责都是形式。
这些形式本来是设立来帮助实现更好的结果的,但是如果拘泥于此,则可能起到反作用。
如果仔细审视敏捷宣言中右侧的内容,就会发现他们都属于形式,而非结果:
个体与交互重于过程和工具可用的软件重于完备的文档客户协作重于合同谈判响应变化重于遵循计划
这些形式曾经保证了众多早期军工、航天、航空项目的成功,但若在任何行业任何项目——比如敏捷开发出现时的互联网行业——拘泥于此,就可能导致失败。
可怕的是,左侧的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或E某cel里边的那种,而是用那个脚本编辑器打开,按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)中的团队模型,由于当年的团队非常成功,所以非常推荐。
这种团队的集成活动是由开发团队和测试团队一起完成的,两者都为此负有责任;但完成集成后,由测试团队自己做系统级的业务测试。
整体上,是一种很“无我”的敏捷团队。
坏处
这种团队只在上面提到的那个公司见过一次,之后的团队似乎都没有采取这个形式的,表明这种形式不容易自然形成。
不过,鉴于当年的效果如此之好,本人一定会在自己未来的团队中采用这个模型。
而实际上每个公司,与其在那些很容易组建但同时很难做好的团队模型中挣扎,不如去尝试一下真正效果好的团队模型。
很多人都很希望找到一种很容易做到,效果又好的模型(以及任何其他东西)。
如果这种模型存在,全国人民都别炒房了,都来开软件公司吧。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 开发 团队 管理
![提示](https://static.bdocx.com/images/bang_tan.gif)