刘华：没有目标的Sprint不是好Scrum

每个Sprint必须有目标

我曾经说过，是否每个迭代都有可上线的交付是评判真假敏捷的唯一标准。

但要做到这一点，有一个前提，就是每个迭代都需要有明确、具体的业务目标。套用到Scrum里面，就是每个Sprint要有目标。

Sprint计划会议，就是召集项目或产品的有关人员，敲定这个Sprint的具体目标，并以此确定与之对应的用户故事。

我接手我们的云平台工程团队后，我发现我们的团队成员每个人都很忙。每日例会半个小时都无法谈完他们手上的用户故事。在Jira的进度版上，满满的都是正在开发中的卡片。

我嗅到的第一个坏味道就是正在开发的用户故事太多了，每个人手上都一堆东西，但迟迟不能完成，每日例会过进度时也费劲，根本过不完。

我要解决的第一个问题就是要根据团队的交付能力，限制在制品。我先用看板的限制在制品原则，和团队约定了同时开发的故事的上限，并把超过上限、优先级较低的故事退回到Backlog中。

通过这个方法，使团队更聚焦，加快了交付速度，提升了每日例会的效率。

但还有一个问题一直没有解决，就是优先级如何确定。由于看板方法没有固定的计划会议，缺乏一个机制对Backlog中的故事进行优先级讨论，并确定某个周期内的焦点。

这个时候，Scrum要上场了。但是怎样有效、高效地开展Sprint计划会议，是一个需要思考的问题。

除了我们负责平台自动化开发的工程团队，在部门里，还有平台架构师、平台产品经理、平台运维，他们都应该参与到我们的Sprint计划会议中。作为为应用团队提供服务的平台，各大部门的应用团队代表也应该作为干系人发声。

但人多口杂，参与会议的人越多，就越难达成共识，这个会议的效率和效果存疑。而且，我们需要一个框架来引导大家聚焦在核心问题上。

和我们工程团队的小伙伴商量后，我们拟定平台的愿景是 为应用团队打造一个 合规 、 安全 、 弹性 、 经济 、 稳健 、 友好 的运行平台。

针对这个愿景，我们的Sprint计划会议要为愿景中的一个或多个维度（即合规、安全、弹性、经济、稳健或友好）确定一个在这个Sprint的主题（即当前要立即解决的一个重要问题）作为目标。确定了这些主题后，我们再圈定有关的用户故事，形成Sprint Backlog。

我们以两周为Sprint的周期，配套设置了Sprint计划会议、用户故事整理会议、每日例会、Sprint评审会议、回顾会议等。

我们也会把Sprint计划会议确定的目标和Sprint实际交付的用户故事发布给各干系人。

在和小伙伴商定这个模式后，我们决定先在团队内部试点，再决定是否把该模式推广到整个部门。

目前我们已经试点了3个Sprint。

在Sprint 1中，我们确定的Sprint目标是：

• 合规方面——继续实施已确定的合规检查自动化

• 稳健方面——开发针对平台API的自动化测试套件，快速检测平台升级质量

• 友好方面——录制平台培训视频，提升应用团队对平台的认识

在Sprint 2中，我们确定的Sprint目标是：

• 合规方面——继续实施确定合规检查自动化；设计违规资源的强制措施

• 安全方面——满足更高安全级别应用的安全需求

• 稳健方面——开发针对平台Terraform Provider的自动化测试套件，快速检测平台升级质量

• 友好方面——继续录制平台培训视频，提升应用团队对平台的认识；提供K8s服务部署的Terraform公用模块。

小伙伴的反馈很好，通过这套机制，我们有了更明确的目标，更加聚焦，在Sprint计划过程中，也顾及了团队的交付能力，每个Sprint都交付了目标内一定的价值。

我们还需要路线图

我们通过拟定平台愿景——为应用团队打造一个合规、安全、弹性、经济、稳健、友好的运行平台。并在Sprint计划会议针对这个愿景中的一个或多个维度确定Sprint的目标。

但我们还缺一张地图，告诉我们要去哪里和我们现在在哪里。要实现我们的愿景，在合规、安全、弹性、经济、稳健、友好这六个维度，都应该要有相应的路线图，才能帮助我们更好地在未来的Sprint计划会议中，确保我们走在正确的方向上。

我的上司也一直问我，怎样度量我们工程团队的效能。

我认为，单纯地以每个Sprint交付了多少用户故事等这样的所谓指标为度量是没有意义的。这也是为什么我没有在Sprint计划会议上让小伙伴对用户故事进行估算，没有用燃尽图等手段，也不要求Sprint结束时必须完成所有用户故事。因为这些都是意义不大的过程指标。我更看重的，是我们是否离愿景和目标更近了。

要度量我们的成就，我们就需要这些路线图，很明确地展示我们如何通过一个个Sprint走向路线图的终点。

回到我们的案例，目前，合规、安全方面，由于还没有从相应部门的拿到完整的要求，所以是走一步算一步的状态，但在友好方面，也是我们工程团队的主要发力点，已经有了一些方向。

比如在平台上，我们已经有多个产品开放给应用团队使用，有哪些产品我们已经提供了自动化脚本，有哪些产品还没有，这就是我们的路线图。在那些已经提供了基础自动化脚本的，能否提供更多场景的支持，也可以作为我们的路线图。

另外，我们每天都会收到来自应用团队的支援请求，目前我们都是人工处理这些请求的。把这些请求一个一个通过自动化手段取代掉，也可以是我们的路线图。

在这里要补充一点，我们的开发比较特殊，由于是在平台上进行“锦上添花”的开发，我们开发的每一个故事，都是独立的。有些比较复杂的故事，不能在一个Sprint里完成的，也可以比较容易地进行拆分。不像一般的项目或产品开发，需要多个用户故事构成MVP才能上线，用户故事间可能会有较复杂的依赖关系。但这并不妨碍我们确定路线图和Sprint目标。

总结

要使Scrum的每个Sprint都有所交代，产品或项目要有路线图，每个Sprint都要基于这个路线图制定具体目标。只有这样，才能通过每个Sprint日拱一卒，逼近愿景。