三个项目背后的故事

阅读量:

前言

今年3月份团队Scrum Master角色空出来后,我争取到这个角色,并在业务敏捷组担任这个角色近9个月时间。

"纸上得来终觉浅,绝知此事要躬行"。正常研发迭代,SM的工作看起来可有可无,让人觉得繁杂而琐碎。但是在经历了三个跨组项目以后,暴露出很多问题,让我有些措手不及,思考良多。

正文

担任Scrum Master的原因

为什么我主动担任并推荐你尝试去兼任Scrum Master这个角色?原因有以下几点:

1. 过程改进:业务敏捷组很多的线上线下缺陷,是因为开发本身在意识和流程方面不规范产生的,即使有复盘但讨论的action没人跟进落地,导致团队过程改进这一块长期并没有看到改善的趋势。

2. SM资源不足:整个定制有4个大组,但是只有一个新入职的PMO,他的重心放在定制H5的任务协调上,很难同时兼顾其他组的工作。

3. 增强话语权和影响力: 实施过程改进,推动测试理念左移,需要这样的一个身份,让别人认可你做这件事,做到名正言顺,可以减少很多执行层面的阻力。

4. 个人经验和能力的突破: 作为一名测试人员,应该需要具备项目管理经验,对沟通表达能力和组织协商能力,还有冲突抗压能力都将是一种提升。

Scrum Master的职责

在我看来,职责可以分为日常敏捷迭代管理和项目制管理。日常敏捷迭代管理,主要有5个方面:

1. 组织Planning meeting,比如事先提醒产品经理敏捷故事的编写、优先级的安排,以及研发对业务需求的估时和技术债的安排,确保planning meeting之前都已经排好,节省会议上不必要的时间;

2. 发布管理,周二提测时间节点,跟开发确认fix version标签提测任务以及状态的更新;

3. 日常站会;

4. 团队文化建设;

5. 回顾会。

虽然在项目管理方面还不是很专业,但我认为项目管理方面大体可以分为:

1. 项目立项,确认项目的目标、里程碑节点和资源。比如跟产品确认项目商业目标和范围,研发提测和发布时间节点,以及项目需要的开发、测试资源

2. 项目进度把控,定期同步项目状态;

3. 项目风险管理,对于项目过程中导致进度偏差和意外情况的因素,尽早跟大家同步并协商解决;

4. 项目数据度量。

项目数据度量

都说要做一个数据价值驱动的团队,那我们应该从哪些维度数据去分析我们的项目?

在这篇文章我想聊一聊,我对项目数据度量的实践和理解。项目数据对衡量一个项目的成功与否和复盘改进有重要意义。项目数据分为结果数据和过程数据,下面看看我搜集的项目数据:

项目进度

项目1

项目2

项目3

开发者信息

司龄

项目2

项目3

开发估时

项目1

项目2

项目3

bug等级分布

项目1

项目2

项目3

bug时间分布

项目1

项目2

项目3

数据分析

1. 从项目维度分析,项目1在提测和上线的时间节点都出现了延期,经过复盘分析:

提测延期原因是:

(1) 虽然产品事先说明,对于资源不足的情况可以申请加人,但是开发缺少跨组合作经验,对任务估时特别是联调花费的时间过于乐观,认为不需要增加人手,结果出现资源不足导致项目存在赶工的情况;

(2) 两组开发节奏不一致,两个业务组的sprint节奏不一致,业务一组先进入下一个迭代,开始dev design并开始头图研发,但业务二组开始设计和开发后,发现业务一组部分设计不符合需求,导致业务一组部分设计被推翻存在返工,浪费了很多时间;

(3) 对项目进度过于乐观,没有每天都及时同步项目状态,高估了双方团队的自觉性。开始承诺互相提供接口、文档的时间出现延期,因为没能及时修正进度方面的偏差,形成"滚雪球效应",导致提前一周承诺的提测时间都赶不上。

上线延期的原因是:

(1) 因为发现了一个历史遗留的数据同步问题,会影响线上数据,经过跟产品确认,延期一周上线;

(2) 验收时发现,做出来的产品UI跟视觉交互还有产品经理的预期效果有些差距,可以优化的点比较多,考虑延期优化后再上线。这里还是因为对项目的估时联调过于乐观了,需要多留一些缓冲时间。

2. 从开发的信息,可以发现:

(1) 中台方的开发人员一直在更替,出现换组到换人的现象,即使是同一个中台也是不同的人在对接。这就给双方合作带来很大隐患,每一个新加入开发都需要重新熟悉业务背景和业务需求,特别是在业务背景比较复杂的情况下,极容易产生引入缺陷和修复缺陷引入新的缺陷的情况。

(2) 特别是项目C,开发是刚入职的新人,没有任何业务基础,这就让在有限时间内上线的目标带来很大风险。

3. 从开发任务估时的维度,经过复盘分析,发现存在以下原因:

(1) 开发的跨组经验不足,后端部分任务需要依赖中台方,设计质量不可控,导致花费时间超出自己预期;

(2) 由于开发前,前后端缺乏dev design的详细设计和对接,导致很多问题在联调期间才暴露出来,导致联调时间超出预期。

4. 从bug等级分布来看,前端是bug的重灾区,特别是在项目2中,前端的低级bug占比很高。经过复盘发现:

(1) 当资源出现不足的时候,开发选择自己加加班来解决,而不是通过申请资源增加人手的方式解决;

(2) 由于资源不足,到了提测的截止时间并没有自测,匆忙交付提测,导致出现了很多低级bug

到了项目3中,前端开发在经过详细的资源评估,并做了详细的dev design和对后端接口确认后,无论项目的节奏和质量都超出预期,实现优秀地交付。

备注:低级bug是指影响主流程、冒烟用例不通过、视觉上非常明显的缺陷。提出这个指标,其实就是为了衡量提测质量。

5. 从bug的时间分布上看:

(1) 总体上发现的bug的数量是往下降的;

(2) 中间时间出现前端bug上涨的,是我认为高风险 bug一定是会在后端,所以对后端逻辑测试的优先级是比较高的,视觉交互的验收是其次,但刚好前端又是bug重灾区。

(3) 但是在项目C中,临近发布上线还发现了好几个bug,而且有些还是之前没有发现过的bug。

关于第3点,经过分析,我认为有两点可以说道:

(1) 为什么会出现这么多的bug?开发对业务的不熟悉,改bug引入了新的bug,说明了回归测试很重要。

(2) 为什么会发现新的bug?这就要求在测试的时候,尤其是回归测试的时候,需要开动脑筋,实行探索式测试,尝试从不同的用户场景和分支,避免陷入思维盲区。

6. 本来还有一个指标,千行代码bug率。由于之前做项目的时候,并没有仔细统计代码的提交影响行数,事后统计比较难,开发也不认可这种方式,所以没有在这里介绍。

7. 为什么从这些维度去分析?

数据的统计是为了反馈问题和风险,主要是围绕"人"、“物”和“事”三个角度来统计的。

Scrum Master实践

在担任Scrum Master过程中踩了哪些坑?

简单地总结,可以用内忧外患来形容,主要是以下几点:

1.  过程改进不要害怕冲突,但是可能会受到反噬。

当发现整个团队的质量意识和规范都没有变好的趋势,一定需要有人站出来,指出来哪些地方做的不好,而且是具体到人,否则都无法产生落地的action。但这种做法难免会引发开发的不愉快,他会想办法找回场子的。

例子:在项目1中,项目延期的一个主要原因是数据同步问题。在项目的复盘会议讨论这个问题的时候,开发就直指"我要是自己没问题,还要你测试干什么?"

2. 一定不要高估其他团队的自觉性和责任心。

(1) 在项目1中,并没有采用每天碰头对齐进度的方式,觉得双方都会每天自觉对齐开发进度,但最终实际进度和预期进度相差较大。

(2) 在项目3中,因为有了项目1的教训,并且知道项目中存在的风险,采用每天碰头同步开发进度的方式。虽然业务三组的TO承诺,开发精力将全面集中这个项目中,但是与此同时还给开发安排了很多场面试,已经影响到项目开发投入时间。在这种情况下,申请我们组的PMO出面跟对方TO沟通解决,事后对方通过周末加班的方式赶上了进度。

3. 如何回答产品的灵魂拷问:项目到底能否在xxx时间上线。

在面对产品灵魂拷问的时候,一定要避免自己直接回答,因为自己不是开发,即使是开发自己也没法确保之前预期的时间可以上线。因此将这个问题转换为任务估时和风险分析,告诉他目前我们需要多少时间有哪些困难和风险,如果能解决这些风险将会怎么样怎么样。。。

在这里附上一份项目管理风险管理checkList:风险管理

4. 发信息同步邮件或者消息的时候,一定要跟各个关系人事先确认,如果是按照自己想当然的理解或者信息落后,就会被打脸受到质疑,后续的话语权会受到挑战。

在担任Scrum Master过程中有什么BP?

1.  PMO+测试联合担任Scrum Master

(1) 组内的沟通协调和进度推进,由测试来承担,因为测试对业务需求和设计方面比较了解,沟通起来会稍微顺畅,将测试左移的理念融于到项目过程中。

(2) 跨组沟通和协调由PMO出面解,利用他们专业的沟通和项目经验,保障双方利益的一致。

这样既可以让我们减轻沟通的一些"累活",又可以发挥自己的专长,产生足够的影响力,实践一把"测试左移"。

2. 如何开好复盘会议?

开好复盘会议,对实行过程改进无疑是最重要的一个环节。开复盘会议的宗旨是既要把重要的问题暴露出来,形成可落地的action,又不能伤了团队之间的和气。这就很考验Scrum Master对复盘会议的掌控引导能力。

有些PMO担任Scrum Master喜欢做和事佬,会给犯了错误的同事找一些理由开脱,目的是为了维护团队内和平共处的氛围,但我认为这样的后果可能就是开发的错误一犯再犯,最终难受的还是测试。因此,测试在担任Scrum Master的时候决不能"心慈手软",该抛出来的问题一定要抛。那么,我们该如何来引导呢?

(1) 首先,抛出的问题应该是具有共性的问题。大家都容易出的问题,或者是某个人出了好几次的问题。某些一次性的问题,可能是因为状态不好,或者是之后都不会出现的特殊问题,可以不必抛出来。既难以形成action,又容易给人造成“鸡毛蒜皮”等细节都抓的感觉,容易引来反感。其实这是没有必要的。

(2) 其次,抛出的问题一定是需要有案例支撑的,不能用"印象中"或者"好像"这些词来表达,不然观点很容易受到质疑,站不住脚。

(3) 然后,不能一直盯着大家犯的错误,对于做的好地方也需要记录提出表扬,甚至做到"欲抑先扬"。

(4) 最后,也不能总是批评别人,对于自己做的不好的地方,也应该主动在复盘会上站出来进行反省。这样让大家才会觉得你是一个比较客观的人,你的观点也会比较容易接受。

另外,要想让大家都认可复盘会议的结论,真正落地执行action,需要经营好团队文化建设,比如通过团建或者提高私下关系等等方式,这是题外话了。

相关复盘会议:

大运河主动授权内部复盘会

3. 跟大家确认任务估时,提醒大家需要给自己留一些buffer时间,确保自己的节奏不会影响下游。特别有些开发责任心爆棚,觉得自己加加班就可以完成,但是实际上质量往往不会太好,反而给测试带来压力。

三个项目的背后学到什么

1. 这三个项目中最严重的质量问题是数据同步的问题,在Dev design和测试评估时,都忽视了数据质量。

2. FO制度的启用。

FO是feature owner的缩写,是一个敏捷故事的负责人,对整个故事的进度和质量负责,通常在跨组项目的时候才需要引入。

启用FO的背景是:在做第一个项目的时候,就开始关注开发任务的拆分和估时,当时前端需要分别跟定制和其他组的后端去沟通接口的设计,而且后端之间还互相依赖,前端很难掌握变更的情况和进度,难以对任务拆分和估时。我在站会上的时候,提过希望定制后端的开发去梳理接口,但是他说他不做,于是只能不断地去push前端和后端自己去沟通跟进。直到在一次retrospect meeting,有人在会上提出希望有人最好能将所有接口梳理出来,并推进开发进度和掌控提测质量。

3. 沟通的细节和技巧需要进一步磨炼,特别是一些表达和信息的收集方面(需要再三确认)。有时候会发现自己表达出来的意思,和别人理解的意思相去甚远,由此可见表达方面还需要进一步锻炼。


comments powered by Disqus