一个成功敏捷团队的失败历程
作者:Gu-dong 咕咚老王
昨天通过微信沙龙,分享到了一个案例,讲述的是从成功到失败的过程。
非常多人可能疑惑。非常多案例都是从失败到成功,这个怎么反了。
非常多成功背后都有其原因,可能非常励志。但从失败中我们可以获取很多其它。毕竟我们的知识大多源于失败而非成功。
故事是这种(括号里的是笔者的情绪表达 :)):
(在非常久非常久以前……)某公司成立了一个团队。开发一款全新的产品。
产品的开发模式是产品需求获取和开发同步进行,团队构成为:项目经理带领开发和測试两个子团队,每一个子团队各有一名Leader。产品经理在開始仅提出最基本需求,依据内部用户的反馈,不断改进需求。(哇噢,非常酷!
)。
这就导致了持续公布的需求。开发流程选用了Scrum。(用到敏捷啦*_*)。开发測试同步进行,最早几个Sprint,採用纯手工測试,仅限功能測试。
(噢~。会成功么?)。纯手工的问题立马暴露:无法回归。
(出现故障了吧~)。形式所迫,引入自己主动化測试。(还好,纠正的及时 :))。项目经理非常权威,立马决定实施自己主动化測试,同一时候保留部分新功能的手工測试。但问题依旧存在。当开发者不參与測试。測试相对于开发的滞后是必定的。
这个gap无法逾越。
项目经理同意測试落后开发一个Sprint。(看来要违反敏捷中“完毕”原则了。
)測试project师们经过努力,达到了这个标准,中国team表示非常惬意;但美国老大不惬意,要求开发測试必须同步。(看来老大还是理解敏捷的。
)于是制定强制要求,要求开发者必须写单元測试,由此引入了TDD。(哇!
原来这个神器是被老大逼迫使用的。)同一时候測试架设CI,并引入測试覆盖率统计工具,假设新功能的測试代码覆盖率低于阈值,则不同意checkin代码。
(持续集成也有啦。手舞足蹈中~)。项目经理进一步要求,开发者必须參与集成測试Case的编写,这一点事实上并没有非常好的执行。但靠着项目经理个人的权威和測试project师的努力。产品就这样公布了。反馈非常不错。Bug非常少,且没有不论什么致命的Bug。
(耶~成功啦~,此处掌声如雷。)。总结经验,感觉产品的质量非常高,能到达这个质量,与开发和測试同步进行有直接关系。所以此产品1.0公布之后的开发中,希望敏捷过程更加推进了一步。
成功公布了一个产品后。团队又接受了开发另外一个新产品的任务,类型与前者相似。
团队将敏捷推进到了第二阶段:全功能团队,Scrum+pair programming+TDD。(此处可以有掌声!
)(满眼都是羡慕的小星星,结对都用上啦。)。
开发測试不分,前后端不分。全部project师都一律结对编程。由于招聘时对測试人员的要求高。因此Coding技能并不比开发者差。
这时没有QA和Dev的区别了,两个人之间会自由交换角色。
团队终于从半敏捷转为全敏捷!
(事实上前面已经非常敏捷啦~)。
可是从这时起,一个负能量的变化却在暗流涌动:项目经理和測试Leader因升职或其它原因而调离团队,整个团队中没有人再关心质量。可是问题并没有立马暴露,由于前一个项目中遗留的资产(Test frame work、Test case等)还能继续使用。另一点就是美国团队引入了一位精力充沛的Architect。这位老兄每天20小时盯着项目,还会自己手动的去进行測试。(美国牛仔?)。他成了项目中唯一一个关心质量的人。不断的督促团队成员去写測试Case。到这个阶段,整个项目依赖着前一个项目的积累和Architect的个人英雄主义推行着。
依赖着这套貌似非常酷的“敏捷”,项目坚持到了产品的公布,但大家都知道这个项目的质量是无法和前一个产品相比的。(我这时问了一个问题:团队中是否有敏捷教练或相似的角色?回答是没有。
)故事还没有结束,原測试人员的顶头上司(測试部门经理)转变了职能。但团队中QA engineer的report line并没有改变。
至此,团队内外,已经没有人关心质量了。之后持续了一段时间的结对编程,可是TDD已经被放弃了。(神器被首先抛弃了。)。
CI尽管还在执行,但每次执行时执行的Test Case已经非常久没有添加过新的,旧的则无人维护以致被关掉了。
(測试通只是怎么办?不測试即可了呗 :))。之后所谓的敏捷团队,就是产品经理的Story。以及团队成员每天去完毕这些Story。
他们觉得已经“完毕”了,就Checkin。整个团队陷入了噩梦的状态。假设产品经理不去确认。没有人知道这些程序是否可以执行起来。
终于的结果是。以前开发新产品Bug不超过两位数的团队。如今沦落到一个新的功能完毕后,都没有人去測试一下的状态。
(呜呜呜~,大哭!)。
是什么导致了这种结果?以下是笔者的一点感受:
- 前一个产品开发阶段的敏捷。是权威下的“敏捷”。之所以成功。不是形成了真正敏捷的自组织团队,而是在项目管理人员的个人权威之下。实施了真正的敏捷实践。
当权威不再存在时。实践也就无法坚持下去了。
- 敏捷团队中没有敏捷教练/Scrum Master。很多人觉得这个角色在国内的公司内是无法得到认同的,由于他既不开发也不測试,对产品没有贡献。而这个案例恰恰对此作了非常好的凝视。我们是关心一个人的成本被“浪费”?还是坐视一个团队的成本被浪费?之前的那个项目经理这个角色是否是“浪费”?(关于此点当时有所讨论,分享者觉得项目经理与敏捷教练是不同的,项目经理的责任很多其它。而敏捷教练则非常少。笔者觉得这是一个误解,项目经理的责任,包含权利被整个团队继承和分担了。当中项目总体管理这个责任的一部分就放到了敏捷教练身上。同一时候,敏捷教练也承担了很多其它其它敏捷相关的责任。笔者个人觉得:当团队成员都对敏捷有了极致的理解,敏捷文化高度盛行的时候,敏捷教练也就不须要了。也就是说,敏捷教练一定要做自己的掘墓人。
)
敏捷教练的角色之所以重要,就是由于TA在引导大家遵循敏捷实践的原则和价值观,遵守敏捷的纪律。终于促使团队走向成功。
缺少了敏捷教练,就没有人关注团队中那些偏差和障碍,甚至当这些问题摆在面前时,大家也是熟视无睹。比方案例中:对TDD的抛弃、对“完毕”定义的抛弃。 - 没有敏捷教练的角色,带来的另外一个弊端就是没有人宣扬和传输敏捷的价值观和文化。没有人对团队成员进行敏捷教育。从而使得团队仅仅是一个权威下的“敏捷”团队。而非终于形成一个自组织的敏捷团队。
9/28日更新:
刚刚看完Ken Schwaber和Jeff Sutherland合著的《30天软件开发 告别瀑布拥抱敏捷》,当中在第8章——“在企业中应用Scrum”——中有这么一段话,对此类案例做了精辟的总结:我们已经见过太多样例,在企业内的其它人还没有真正懂得怎样用新的方法思考和工作,转型还没有在企业内扎根时。发起人就由于晋升或离职离开了原来的岗位。
当发起人高官离开之后,之前取得的进步将灰飞烟灭。而刚被淹埋却没有根除的旧文化又会卷土重来。
之前取得的优势和持续改进的习惯也会随着时间的推移渐渐减弱。
欢迎大家板砖侍奉!
原文链接 http://www.cnblogs.com/Wangyong-Wen/p/3976805.html