敏捷实践的误区和陷阱的七个方面
上一篇 / 下一篇 2012-09-03 13:44:20 / 个人分类:敏捷测试
!]:Feg8|;^+?e!nS0 我们认为敏捷实践经历的误区和陷阱大致可以分成如下七个方面:特性团队、人、浪费、局部优化、软件质量、测试自动化、流程。
Z!] n'Ou\09Rv?0uq U0 特性团队(Feature Team)
2e*B0E+f8QX5G051Testing软件测试网]G,r7o$B}~q rY"D在组织中想要达到真正的Feature Team是一个很漫长的过程,当在组织中实现局部的端到端的组的时候,更大的端到端的组的演变要求就会出现,因为这时组织中新的瓶颈会展现出来,这也是为什么敏捷虽不能解决问题,但却使问题更显现地表现出来的原因之一。51Testing软件测试网%^vb"fZ
ii$K(F.d.c cf6p0 在组织的转型中,产品有非常庞大的老代码:51Testing软件测试网 ]b:_4K)M0Td X
4p0s)MWnT0 1、通常早期的Feature Team所包括的功能性测试不完全,外部的测试对于这些Feature Team所起到的保护作用还是相当重要的;
H^j)QI0$[8IZ Vj2N|/SL[0 随着时间的推移,Feature Team对于自己feature自动化测试加强以及测试能力的提高,发布给外部的产品质量会大大提高;51Testing软件测试网f6HR-]? ]2j N V)D
51Testing软件测试网m3IrF;fn(L.\2、对于外部其他组的依赖接口会很多,特别是组在不同国家的时候,沟通、交接和等待的浪费会很大;
CmSH N-v Q051Testing软件测试网AI P;i.j IGw3、当产品中开发部门和开发部门的依赖减少后,开发和测试的瓶颈会更突出;51Testing软件测试网 @v ? myccn
51Testing软件测试网z NK^.O_;Y6n_o4、当产品中各个功能部门的依赖减少的时候,产品和产品间的瓶颈会凸显。51Testing软件测试网 q"_+l`SHY8h[/R)d
51Testing软件测试网.v.qk3AJMl0S3uQ想象一下从客户提需求到最终提交功能需要经过多少个过程,特别是大型组织中的产品,端到端意味着几十个过程甚至更多,Feature Team中能容纳多少个这样的过程就意味着这个Feature Team的灵活度有多高,本质上敏捷就是为了减少相互的依赖、等待和传递所带来的消耗。51Testing软件测试网C4L*^ ^'B%Jx@)j {#@
C6[z'XsE r0 一个组织是一个庞大的系统,Feature Team的转变过程意味着减少整个系统中的Limitation。
pm9DP%?!t&~3{o051Testing软件测试网+CL}#@?f在向Feature Team演变的过程,在相对比较短的时间把原先十几或者几十Component Team打破组成新的Feature Team,这中间的风险在于:51Testing软件测试网3l2d&fak)o
51Testing软件测试网lf l.e){1\!\!S1、组的成熟度:成熟度需要时间,也需要一些错误的代价;
mq4tz:xq0a8Qig)TA[0g0 2、组的长期成长和短期项目计划:由于为了项目的进度而把对某领域很熟悉的组移出去做不熟悉的领域;51Testing软件测试网Yc I*|4n
'\u8m^zL XB:Q0 3、组织的产出效率:怎样合理的利用现有的有经验人员和新人,建立新结构所需要的基础会使组织整体的产出效率减低;
t%g5G)Fh-v s7J0D(lM9G(kE:t^0 4、不可控和无序:怎样让这些组高质量的发布产品在转变过程变的不可控。
o1A8y.Jb B6I051Testing软件测试网!w'} U9S9M0zSi6Z理想和现实中的平衡是Feature Team所面对一个问题,剧烈的变动意味着剧烈的阵痛。51Testing软件测试网$~;Uc0y&R)F{
H`6YI$zaC0 人
k,^4]Yul0V/@4X/c s0 我们的转变是基于Scrum+XP的方式,转变的影响巨大,之前存在的许多职位、头衔都会面临变化甚至消失的可能。例如将不再会有项目经理来集中处理项目管理的工作,对于产品需求研发顺序的管理也由以往的项目经理手中转为产品负责人来负责。就算是最基层的开发人员和测试人员,他们的日常工作方式以及职责范围也面临着极大变化。这也意味着转变可能会遇到非常大的阻力,人天性会抗拒未知的变化。
.JU+q;?4cN051Testing软件测试网FTR@3{#n某平台部门的转变尤其特殊,研发的老大意志坚定,在初期Pilot成功后,就大刀阔斧地进行组织架构改革,仿佛一夜之间所有的项目经理全部消失。而以往 围绕功能模块所组建的分散的测试团队以及开发团队也被重组,每一个Scrum团队都拥有好几名来自不同功能模块领域的开发和测试人员,从某种角度来看,这 是我们所倡导的跨功能特性团队的雏形。51Testing软件测试网W H#V D1j U[T,[
(?Q$}$Di0 各种形式的人员流失造成很大的困难,有人因为个人或家庭的原因离开公司,也有人在新成立的产品线 谋得职位,也有人被提升。但这一切都造成原来位置上的熟手损失殆尽,尤其是测试相关人员的流动,曾是很大的隐患。在以往的研发模式中,测试被严格划分为多 个层级,由不同的测试部门执行,彼此之间通过高级别工程师以及文档和流程体系来沟通,确保各个层级的测试得到执行。新的组织架构中,除了Scrum团队 后,就是系统测试团队,而Scrum团队测试和系统测试之间的衔接则出现了灰色地带,原因就是彼此对对方的职责各有不同假设,却未能发现及解决。51Testing软件测试网O!jN/MOL
51Testing软件测试网Z])v!D:rP3\当时拥护及反对“敏捷”的各有人在。很有意思的是,在内部论坛上,我们属于敏捷的坚定支持者,又喜欢说话或者说辩论,所以可谓是当时论坛里的焦 点,矛头所向。和大家进行了很多很多的辩论,当然多数都是无疾而终。我认为这些讨论,以及发生在工作场合里的许多讨论,同事间私下的交流都非常好,在变革 之际,能够帮助大家去理解这场变革(就算是纯粹的抱怨也并非一无是处)。
5q6^2r2sXz]a7]0c H u ?*p(tFx x0 组织变革的关键还是在于充分沟通,以及切实执行。有不同的声音不要紧,关键是要去澄清和解决他们的疑问,因为没有大家的理解和认同,变革也很难取得实际的效果。51Testing软件测试网9dr7EA^D-b!\
51Testing软件测试网A qk#AQ.G qZ3e'h浪费51Testing软件测试网8[@?[%Z0F!H*p.J
3{&qW;C$r9F8xW@0 加班加点赶进度的情形相信大家并不少见,但如果这么辛苦做出来的东西并没有真正地或是及时地派上用场,恐怕就更加可惜了。该平台部门曾经很辛苦 地去兑现某一个重要发布的最后期限,而根据客户提交的缺陷报告来看,其中有一些功能客户并没有在拿到这个重要发布后就去使用,而是在拿到后续的发布后才有 使用到这些特定的功能。
/sc#QE ts051Testing软件测试网z{L|_5Xa"M d该平台部门并非是直接面向终端客户,还需要结合上层的网元应用才能真正地产生效果。常规的模式都是网元有一系列客户需求(具有非常大的粒度)中 分割出对系统平台的需求后,传递到平台部门的项目进行管理。出现过的情形是,平台部门赶出来递交的功能特性,由于网元应用没能及时开发出来,而无法递交给 客户使用。51Testing软件测试网L7BI;rYI+M
F(\2Hmo`#UVo0 对此,大家有很多疑惑,我们是否在做该做的事情(功能特性),其中到底有多少浪费。Scrum的主张就是对用户需求进行优先级排序,但其中有一 些关键的点必须要重视,否则很容易流于形式而无法从中获益,第一,要将需求分割到合适的细粒度,团队才有可能持续地递交高优先级的功能特性,需求粒度不够 小,假设Product Backlog里就只有一个条目,那么不管是PO还是销售还是客户都没有办法取舍;第二,要逐渐达到以真正端到端级别的需求为单位进行开发、管理;第三, 开发团队和PO(能够和终端客户、用户交流更好)之间有频繁地交流、功能成品展示,从而可以利用反馈来改进、提高后续功能的开发。51Testing软件测试网(K7sAp3?vM`:{)kt
51Testing软件测试网:w)\+c5tk$_\M局部优化51Testing软件测试网"V tFDZ5_o$f5u*@
3RR xl'j+s8n$w-\{0 有话说“不怕神一样的敌人,就怕猪一样的队友”,其实做软件也是,怕的就是劲不往一处使。但说回来还真不是大家不努力,而是对这个“一处”的看 法各有不同。关注于各自目标的达成,并不能保证这些努力叠加起来能够实现那个 “共同的”目标,对局部进行的优化可能会反过来扯集体的后腿。这样的现象,组织各个层面都有。团队内、团队之间、产品线之间,都存在着这样的情况。51Testing软件测试网yx8Qv\.l$q(b
51Testing软件测试网9?8A_0f&xt)y例如团队内部,由于不习惯转型过程中新的特性团队的工作方式,团队内部也还是颇有些泾渭分明的开发、测试各一拨人,自个选自个的工作,迭代开始 的时候,各自就把自己的任务选走,然后整个迭代就盯着自己的一亩三分地拼命干。但问题是,团队需要负责、承诺的是最终可以运作的软件增量,而这样的模式无 法保证迭代结束时的交付。51Testing软件测试网j\#p-{:O/S
51Testing软件测试网M;vjY|团队之间也是如此,为了让自己的团队工作预期更稳定、工作中能更专心,团队也都要求确定他们的工作领域,迭代中则有些简单粗暴的拒绝许多协助进行缺陷分析的请求。结果就是导致缺陷分析、修复的工作变得非常难以开展,而且有很多尚未查明的潜在缺陷被放弃追踪和申报。51Testing软件测试网M;TDC3bk?.?
51Testing软件测试网/} `z O'o4n)?7{更大范围内来看,我们完成了传输平台的开发还不够,要能够产生客户价值,还少不了上层的应用软件系统。但我们的系统工程师团队、Scrum团 队、系统领域测试团队等,以及上层的开发团队、功能测试团队、版本测试团队、系统测试团队等一干团队,尽管都在努力改进自己的工作绩效,可问题是,这些局 部的、片面的优化,在组织层面观察,对终端客户产生的影响微乎其微,甚至是副作用。51Testing软件测试网xeN/zZc$s4~g y
51Testing软件测试网/I r'D%f:[!k-[/F!?E)t敏捷、精益的要点正在于此 —— 关注于产生的价值,移除不必要的浪费。不恰当的局部优化也是一种浪费,我们要具备系统思考的能力,从整体上看问题,然后改进绩效。组建特性团队就是开始。
"L%c\Z.R1Dy @00r Qf6_:u+i0 软件质量51Testing软件测试网DH#dh'x {6xW4b,@
M:yN$CH]0 软件质量是很多组织都有的一些共性问题,任何变化都意味着质量降低然后恢复到当初,然后再变得比以前好的循环,在我们组织中还是不可避免经历这样的循环。
s3jbG9I\051Testing软件测试网i0Jiq@O Z7KrEE3E在敏捷的转型中,如果没有很好的考虑这些质量的风险,那么最终它所带给组织的将是未来很长一段时间的“痛”,背负的“债”需要很大的代价来偿还,所导致的结果将对客户的满意度和信任都会产生很大的影响。
aL/| H1EvVO-gr0