【落叶88】“老兵聊测试”之伪敏捷是否敏捷?

【落叶88】“老兵聊测试”之伪敏捷是否敏捷?_第1张图片
文/秋之川

【目录】

这是《落叶》文集里第 88 片落叶,希望你能喜欢,不为别的,只为这份坚持。

很多创业团队或者大公司都把敏捷挂在嘴边,放在门面上,张口闭口都是,我们采用的是敏捷开发,我们早就敏捷了,等等诸如此类。

于是就想多问问,想学习一下,然后就会听到各种介绍:

我们每天都会站会……

我们在项目组旁边立了块白板……

我们一个月发布一个小版本……

我们月初都会花好几个小时开计划会……

我们整个研发团队里,开发都可以做测试,测试也能去写代码……

可他们是真的都敏捷了吗?

每天开站会就算是敏捷了?

一堆人每天跟背书似得,站在一起轮流说昨天做了什么?今天要做什么?还有什么问题。然后就开始各种问题细节讨论了,一站就是半小时以上。开完之后,经常是项目经理(兼任SM)还得挨个问进度,记录问题。

立了块白板做任务墙就算是敏捷了?

项目计划会开完,都用便签纸把自己的任务贴在了白板上,然后就没有然后了,或者就是每天开站会的时候,都带着各自的小纸条,然后贴在了白板上,慢慢地,白板上贴满了纸条,跟天书似的。有些项目经理还会很“负责任”的,根据每个任务进度,去“帮助”团队移动白板上的便签纸。

一个月发布一个小版本就算是敏捷了?

你看我们的发布周期都是一个月一次了,跟冲刺长度的要求一样吧,可再细看一下,每个月里还是1号开始需求评审,10号开发提交可测版本给测试,17号测试完成功能验证测试,代码冻结,31号发布。还是一个小型的瀑布流程,所以还就是一个披着敏捷外衣的瀑布流程。

计划会一开好几个小时就算是敏捷了?

你这个会开的时间长是因为产品负责人和研发团队在这个会上对每个需求都达成了共识吗?还是因为会议前缺乏沟通,在需求的可行性和合理性上有不同意见,所以在会上花了大量的时间去讨论争执。还是因为你邀请了太多“鸡”角色的人员参会,他们会提出一些事先不在PB里的要求,导致整个会议就不停的扯得很远,然后又再拽回来。

开发会测试,测试会写代码就算是敏捷了?

会做跟做的好不好是两个概念,开发会测试,那他是基于代码做单元测试呢?还是仍然做手工测试?如果你们的开发不做结队编程,也不做交叉代码评审,又不做单元测试,那依靠他的手工测试,难道还能比专业的测试人员思路正确吗?反之测试去写代码也是一样,是能看懂代码,去参加代码评审,还是会写代码,去做单元测试?难不成让测试去写某个需求的代码,效率和质量能比开发还要好?

纵观上述几种认为自己就是敏捷的观点,我只能给出一种评价:形似敏捷,神非敏捷

敏捷是一种思想、原则和实践相结合的东西,不能简简单单拿来一个所谓的模型,套用流程和工件,就认为已经敏捷了,敏捷的转型或者实施首先要从思想上理解并认同,再辅以大量的实践,通过实践再深入理解消化,是一个反复锤炼提取的过程。

作者简介:14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵

【目录】

你可能感兴趣的:(【落叶88】“老兵聊测试”之伪敏捷是否敏捷?)