痛苦的 Daily Scrum

很多人深有感触，Scrum 里最「难」开的会之一就是早会。

要么成为汇报会，要么成为僵化会，要么成为大家都不想开的痛苦会。

如果你对早会的效果也有不满，不妨看看 Scrum Guide 里对早会 3 个问题的建议，想想它为什么这么建议？

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Sprint 的 Scope 可以修改吗？

十几年来都会持续地听到一个以讹传讹的说法：「一个 Sprint 的 Scope 不能修改；实在不得已时，加一个工作项前必须移除一个工作项。」

我很早以前也是相信这种说法的，直到有一天意识到，这不是跟「敏捷宣言」说的「响应变化高于遵循计划」相违背吗？

我于是又翻了一下 Scrum Guide，发现里面写的很清楚：

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

不能改变的是 Sprint Goal；在此前提下，Scope 可以协商。

被忽略的 Sprint Goal

如果上面两段引用还不足以引起您对 Sprint Goal 的重视，那么我再引用一段：

A Sprint would be cancelled if the Sprint Goal becomes obsolete.

如果 Sprint Goal 过时了，Sprint 可被取消。

这几乎等于在说，没有 Sprint Goal，就没有 Sprint。

所以，不是「两周」就叫 Sprint，两周后需要达到一个目的，才叫 Sprint。

一个成功的故事

有一次我们团队接到一个较为复杂的任务，它对其它 3 个团队都有依赖，必须在 9 周内完成。

我们的做法是：

1. 用了几天做了一个 POC，然后快速做了技术选型。
2. 剩下 8 周多的时间，我们分成 4 个 Sprint，把这个任务分解成了 4 个里程碑，分别作为每个 Sprint 的 Goal。
3. 每天的早会，所有人（我们团队 + 其它 3 个团队各派了一名代表）关注的是这个 Sprint 的 Goal 能不能达成；而 Sprint 内的 Story，则根据每天的进度和学到的东西，不断地调整。

最后的结果，这个任务完成地非常顺利。

这就是 Sprint Goal 的威力：

1. 它承载着项目的里程碑。每个 Sprint 都完成一个里程碑，这就是 Scrum 里 Incremental 的意思。
2. 它对齐了团队每个人的目标，而如何完成这个目标 （做哪些 Story，用什么样的顺序做），则交由团队自行决定和调整。

如何设置 Sprint Goal？

Sprint Goal 不是 Sprint Backlog 本身，而是通过完成 Sprint Backlog，所要达到的目的。

这个目的可以有三种类型：

1. Earn Business Value （实现了什么业务价值？）
2. Earn Architectural Value （实现了什么架构价值？）
3. Learn Something （团队学到了什么？）

所以，「完成 XXX 的开发」，一定不是好的 Sprint Goal。

以上面提到的故事为例，我们的任务是让客户端无感知的前提下，迁移几组共计上百个 API，技术选型是 API Gateway。

而我们第一个 Sprint 的目标是通过把其中 1 个 API Gateway 部署到生产环境，并且完成所有客户端的联调，去证明我们的技术选型是可工作的。

这是很重要的一点。

容易犯的错是：前几个 Spint 的目标都是开发那些 API，但是直到最后一个 Sprint 才部署到生产环境，这就不是增量（Incremental），而是瀑布。

如果一个 Goal 设置下来，上述 3 种目的都没有达到，需要反思一下 Goal 设置得是否合适？

结尾

总结一下，

1. 设置 Sprint Goal，是让团队关注价值，关注里程碑，关注目的；而对手段（User Story 是手段）保留随时更新的选择。
2. 建议草拟往后若干个（而不是 1 个）Sprint 的 Goal，并且每个 Sprint 滚动更新。这是以终为始的思维。
   1. 前面的 1 个或几个 Sprint，往往要关注 RAID （Risk, Assumption, Issue, Dependency）的消除，这就是 Learn；
   2. 后面的 Sprint 才是收获，要么收获业务价值（用户直接得利），要么收获架构价值（架构演进），这就是 Earn。

把 Sprint Goal 用好是让 Scrum 免于僵化的一个突破口，试试吧！