敏捷转型几年了,在开始的喧嚣过后,怎么持续让团队有质的提升? ——研发经理小A
我的大部分时间都花在开各种会了,一天打 9 小时杂,下班时都不记得自己做了什么。 ——研发主管某乙
做Scrum Master 一段时间了,看外面的 Scrum Master 的职位越来越少,我怎么给自己更多的挑战和成长? ——Scrum Master 小凉
NO.0 去领导,而不是去管理
上面这些困惑在 Scrum Master 和 管理人员中很常见。要解决这些困惑,首先要找准自己的定位:管理只是我们的表面工作,我们的真实身份是一名领导者。
当你一天到晚被事情追着跑,每天约定俗成的做同样的事情时,你就是体制内的管理者;而领导者主动出击,做该做的事,而不是做被告知要做的事。
管理者维护现有系统的运行;领导者演化出新系统。——那个谁
所以领导就是领导持续的变革。具体怎么做呢?今天就说说我实践并总结的一个框架。
为业务价值负责
识别并反思“开发价值流图”
让价值流动
培育团队的心智模式
制造拉动,营造不舒适圈
NO.1 为业务价值负责
首先你自己要为业务价值负责,不管你是什么职位。
现实中大家不会陌生下面的分工:
Scrum Master 的责任是:保证团队在 Scrum 框架下持续交付。
Dev 的责任是:开发出产品经理给的需求。
QA 的责任是:确保系统的质量在一定水准之上。
产品经理的责任是:这个需求很简单,怎么实现我不管。
大家为不同的价值负责,结果就是容易各种撕。
要领导变革,首先要有个共同的目标,为此要识别团队的共同价值,比如
团队的最终价值是:提升业务的运营效率和客户的满意度。
业务价值是唯一的,意味着大家的最终目标是唯一的。它就是团队的北极星。它让我们每个人每天的工作,都有个明确的指向性。
NO.2 识别并反思“开发价值流图”
“开发价值流图”指的是开发团队为了交付业务价值涉及到的所有活动。
因为我的工作和团队的工作最终都指向业务价值,我们就可以对价值流进行分析和反思:
哪些活动是无用的?
哪些活动是缺失的或者不到位的?
哪些活动的顺序是不对的?
举个例子
比如我曾经一个团队的价值流图,以及我的反思,是这样的:
步骤 | 反思/问题 |
---|---|
1. 主 PO 分配项目给团队 | 为什么要等待 PO 分配,而不是我们去挖掘用户的痛点? |
2. BA 做细节的业务分析 | 有没有一个一致的方法去衡量业务价值的大小? |
3. BA 写出 User Story 并跟开发说明 | 怎么确保开发理解了 Story 后面的业务需求? |
4. 开始开发 | 为什么很大的 User Story 没有被拆分? |
5. 开发完毕后QA开始测试 | 自测有没有做?单元测试覆盖率如何? |
6. 开发完毕后 code review | 大的 User Story 少则一周,多则几周。开发完毕后的 code review 面对大量的代码,很费劲。 |
7. 根据code review 的结果重构甚至修改 | 有时候需要修改的代码太多,怕影响进度就放弃了,于是留下技术债。 |
8. 重构之后 QA 重新测试 | 手动测试反复,费时 |
9. 最终发布 | 发布后缺乏对实际产生的业务价值的验证。 |
如上,用精益的眼光去看这个价值流图,它可被改进的空间是非常大的。它让我们有了端到端的全局思维,不再头痛医头脚痛医脚。
顺便说一下:Scrum 是术,精益是道。我认为所有人都应该学习精益。
NO.3 识别系统性瓶颈,让价值流动
识别了价值流,我们的工作就很直接了:让价值流动起来。为此需要不断地识别系统性的瓶颈,并演进“开发价值流图”。
我们都知道 Scrum Master 的一个职责是“移除障碍”,但是,如果不去识别某障碍背后的系统性瓶颈的话,同样的障碍会反复出现。
举个例子
上面说的一个问题,Code Review 费力不讨好,一些代码改起来吧 QA 要重新测试,影响进度;不改吧技术债越来越多。
很多团队都对这个问题感同身受,那怎么办?可以问自己几个问题:
为什么 Story 不拆小一点,拆到 3 天即可完成,这样 一次 Code Review 的代码量就小,要改的话改起来也快。
进一步,就算 Story 要做 3 天或 10 天,为什么不每天 Code Review?
再进一步,既然 Code Review 这么重要,为什么要每天才做?不能每分钟都做吗?(结对编程)
Code Review 出来的问题,有没有去分析和分类?比如,是没有遵循代码规范?还是经常 Review 出 bug?
如果是没有遵循代码规范,是代码规范过时了?还是缺乏工具去静态扫描代码?还是程序员的技能有问题?
如果经常有 bug,是程序员对需求理解有问题?还是缺乏单元测试的覆盖率?
如果是单元测试覆盖率不够,是不是团队对 Story 的各种业务场景理解得不完整?
如果团队对各种业务场景理解得不完整,为什么不在开发前(而不是之后)就把场景列清楚?
这个列表还可以一直问下去。我们看到,一个 Code Review 的问题,非常可能是价值流图里出了系统性的问题,解决问题的第一步就是识别根本性的问题。
NO.4 培育团队的心智模式
前面三步是我的心智模式,或者我“构建”的系统结构。
这些心智模式和系统结构一定不要留在自己的心里,要让它在团队中慢慢生长。
心智模式就是“你相信什么”,所以它会影响团队的行为模式;行为模式就是“遇见什么情况时会默认采取什么样的行为”,它就是团队的文化。
举个例子
代码写好了,QA可以开始测了,是关于测试的心智模式和价值观。
再举一些心智模式的例子:
User Story 是需求,还是方案?
Requirement 和 Need 有什么区别?
小批量和大批量,哪个更节约成本?
软件研发是可以分工的吗?
显然,人们对这些问题的答案越一致,意味着人们的心智模式越一致,他们就越像个团队,而不是团伙。
NO.5 制造拉动,营造不舒适圈
团队的心智模式不应该是静态的,它需要行动和实践的反哺。也就是说,虽然心智模式会影响行为模式,但是往往是先有行动的改变,才会有新的心智模式的形成。
所以,我经常需要做的事情是,设计一个小的实践,微调这个虚拟的系统,让它去拉动更多的实践,去帮助培育和固化团队的心智模式和文化。
说人话,就是“持续改进”。
举个例子
针对手工测试时间长 bug 多这个问题,我们曾经设计了一个小实践:Dev 完成一个 User Story 的开发后,在交给 QA 测试之前,Demo 给 PO 看。
这个实践对很多开发是很不舒适的,他们习惯了写完代码扔给 QA 去测,有 bug 再修。
我们可以看这个实践如何拉动更多的实践:
为了要 Demo (实践一),他们需要做足够的自测(实践二)
自测很烦,就引导他们做更多的单元测试(实践三)
单元测试写起来费劲,就需要把代码写得更可测,SOLID 原则得学起来(实践四)
单元测试的场景覆盖率不够,就得把业务规则的场景先弄清楚,这就可以来个 Spec by Example(实践五)
你都 Spec by Example了,不顺便来个 BDD 吗?(实践六)
当然,这些实践的设计,以及拉动,都需要结合团队的情况,没有标准的套路。
NO.6 留白
以上其实是我对一朋友 Tony 的访谈实录,听下来我觉得他说的有点道理,所以结束的时候我问 Tony:你一研究发型的总监怎么说得这么好?
Tony 微微一笑:哪里哪里,我这是站在三位巨人的肩膀上。
- 一是精益思想
- 二是系统思考
- 三是冰山模型
说完飘然而去,云深不知处。
文档信息
- 本文作者:蔡建斌
- 本文链接:https://johncai.github.io/2020/04/16/save-scrum-master/
- 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)