Luna记 | Scrum Master 半年实践小结
0. 前言
我担任 Platform Scrum Master 大约有半年多了，虽然做 Scrum Master 之前看了 PSM-I 的证书，但是在实际的实践中，偶尔还是会对自己的决策和理念产生自我怀疑（我这么做是对的吗？我这么想是正常的吗？我要做哪些改变？我如何验证自己的决策？）。
于是我这几天重温了一遍 Scrum Guide，也看了一些文章，结合我的实践经历，做了一些思考。
1. Scrum Guide 笔记
角色
Scrum Team 包含三个角色：
- Product Owner
- Scrum Master
- Development Team
Scrum 价值观
Commitment, Focus, Openness, Respect, and Courage。
Scrum Team 做的决定需要强化这些价值观，构建团队的信任感。
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.
分工与职责
- Product Owner 的职责是讲清楚 Why 以及 Sprint Goal 的价值，具体的任务分解、预估、实现方式都是由 developer 来定的，Product Owner 决定 PBI 的优先级顺序；
- Scrum 强调每个团队成员的专业性和「自组织性」（Self-Organizing Team），所以 Scrum Master 的职责是 Facilitate，而不是 Control；
- Scrum Master 需要保护团队，防止 over-commit, scope creep 和 burnout；
- Scrum Master 的角色是团队的服务者和 Scrum 理念的布道者，目标是提升 Scrum Team 的效率；
PO 和 Scrum Master 会有一些分歧，因为 PO 希望完成目标（关注点是 Why 和 What），而 Scrum Master 更多的是在管理流程和团队的日常活动（关注点是 How），也可以理解为「规划大脑」和「执行大脑」的区别。
Backlog Refinement - 任务细化
Backlog Refinement 的目的是 Gain enough benefits from the activity while minimizing the potential waste。
- Team 需要在 Refinement 的实践中动态调整，找到一个平衡点，回答「How much of your Product Backlog do you want to be “Ready” before a Sprint? What does “Ready” mean to you?」这个问题。
- Refinement 是动态的，即使是同一个项目，也要根据大家对项目的熟悉程度来调整细化的程度。
Estimation & Planning - 预估和计划
Scrum 追求的不是 estimation 的准确性，因为 estimation 和 up-front planning 永远不是完美的、100% 准确的，Scrum 追求的是目标的明确性（大家都知道这个 Sprint 最重要的事情是什么）。
所以，Scrum Guide 里面没有推荐使用 Burndown chart 之类的工具，它强调的是团队协作的效率、产出结果的质量、以及与 business value 的契合度。
Scrum Master 的职责之一是帮团队扫清障碍，让 developer 能够专注于他们擅长的事情上。
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.
强调适应能力和学习能力
每个 Sprint 的任务都是不同的，有些任务简单，有些复杂。Scrum Guide 强调拥抱不确定性，Learn by doing。
Scrum 的计划其实是每天根据实际情况来调整迭代的，大家的核心关注点是如何实现目标，通过团队协作和沟通来制定方案。因为越是复杂的任务，越难制定出准确的计划，越难去预测可能遇到的问题。
但是 Sprint 也必须限定任务的 scope，一开始要和 Product Owner 讨论清楚需求，把大的目标分解成可以在一个 Sprint 里面完成的小目标。
2. 我的 Scrum 实践
做的好的地方
- Self-Organizing & Focus：减少 management overhead，在固定的时间和场合跟进进度（而不是每隔三分钟就问一次），通过 Dashboard 和 Automation 来把日常的管理任务流程化，只关注关键节点，而非所有的细节；
- Openness & Transparent：鼓励团队成员公开讨论问题，进行观点的碰撞，了解 trade-off，提高决策能力（每天下午都有一个 tech huddle 来做知识分享和问题解决）；
- Trust：每个团队成员可以根据自己的预估来给出任务完成时间，给予足够的空间、时间和机会让他们提升能力；
- Learn by doing：整个团队都能够做到拥抱不确定性，给大家犯错和学习的机会；
- Adaptation & Iteration：每次的 retro 我都会根据 sprint 的具体情况来设置一些问题，每次的 action item 都会跟进，用行动解决大家遇到的实际困难；
- Definition of Done：我把「做完」的定义清晰地写在了 board 上面，确保交付的质量；
- Servant Leader：我在 Scrum Team 里面的主要职责就是帮大家扫清障碍，让大家能把时间花在能创造价值的事情上；
做的不够的地方
- Backlog Prioritization：由于人事方面的变动，我们很长一段时间是没有人担任 PO 这个角色的，我不得不兼任了 PO 和 Scrum Master 的角色，但是我最近意识到这样的做法不能长期保持下去，因为我缺少 business 那边的 context，无法最终决定 priority order；
- 解决方案：跟其他 team 进行合作，把这块的责任交给合适的人选；
- Requirement Gathering：我们有很多 PBI 的需求没有写清楚，导致做事情的 dev 无从下手，浪费了很多时间；
- 解决方案：每次 sprint planning 的时候跟团队过一遍需求，跟需求方进行沟通，只有需求明确的任务才能开始做（dev 可以讨论实现方法，但是需求这块我们没法凭空想象）；
- Sprint Review：这个环节由于种种原因我们一直没有去推行，可能明年要考虑一下是否要加进去；
- 现状：每次 Sprint 结束我都会发一条跟 Sprint goal 相关的总结，我们每两周也会发布 product release note；
正在尝试的部分
Planning
我们团队的新人比较多，所以不是每个人都能做每个任务，而且还有一些人不是全职上班，基于这个现状，我会根据每个人的情况和任务的复杂度来分配任务，确保我可以最大效率地用好手头的资源来完成任务。
我希望达成的目标是把这些新人培养起来，每个人都能上手大部分的任务，这样大家可以直接在 backlog 里面根据优先级来做任务。
到了那个阶段，我只需要在 sprint planning 的时候看一下我们上几个 sprint 完成了多少 effort，这个新的 sprint 准备做多少 effort，就够了。
Progress Tracking
我没有用 burndown 来管理团队的进度，因为我们团队的人很多，在同时进行的项目也很多，假如要求每个人每天去 update burndown，管理的 overhead 太大了，所以我关注的是 cycle time，比如 effort 1、2、3 的 PBI 需要几天的时间完成。
这个管理方式的「弊端」在于：你不知道每个人每天完成了多少的工作量，更多的是关注一个大的趋势，而不是每个人的工作情况。
我做这个决策的原因在于我不太关心每个人具体的产出（也管不过来），我更关心的是团队的协作情况和总体完成的任务量。
不过我每次 sprint 结束的时候会看一下之前分配给每个 dev 的任务的完成情况，假如我认为 A 在这两周可以完成 5 个 effort，但 TA 只做完了 3 个，那我基本上就知道 TA 在团队里面的产出情况了。
3. 结语
Scrum Guide 里面说到，这个 Guide 只是提供了一些准则和理念，而不是具体的执行方式，因为不同的 team 适用的方法是不同的，Scrum Master 要根据公司业务、团队的现状和能力来找到一套适合这个团队运作的方式，并且要不断地优化和迭代。
Scrum Master 所做的一切，目标都是提升团队协作效率和自主性，达成 Sprint Goal。
Scrum Master 自评
重温了 Scrum Guide 之后，感觉心中很多的疑问和纠结都有了答案，如果根据 Scrum Guide 的标准来给自己这半年的 Scrum Master 实践打个分，我觉得自己应该能到 80 分。
原因：达成了一些重要的里程碑，多线程管理（客户相关的工作+内部工具开发），圣诞节前的交付任务都完成了，团队人数几乎翻倍，整个团队的氛围很不错，大家都有动力、有事做、有所期待。
我最大的优势是：愿意帮助别人成长，愿意通过行动来改进现状，同时也不害怕暴露问题（如果有团队成员做的不够好，我会给出及时的反馈；如果我做了错误的决策，我也会跟团队分享我的思考和经验）。
综上所述，我还是挺满意的~
Talk to Luna
Support Luna
