前言
今年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. 沟通的细节和技巧需要进一步磨炼，特别是一些表达和信息的收集方面(需要再三确认)。有时候会发现自己表达出来的意思，和别人理解的意思相去甚远，由此可见表达方面还需要进一步锻炼。
关注我们
酷家乐质量效能团队热衷于技术的成长和分享，几乎每个月都会举办技术分享活动（海星日），每半年举办一次技术专题竞赛分享（火星日），并将优秀内容写成技术文章。
我们尽可能保障分享到社区的内容，是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章，请您关注我们的微信公众号"酷家乐技术质量"。
