扫码阅读
手机扫码阅读

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

133 2024-04-10

如何通过每个Sprint日拱一卒,逼近愿景?

我曾经说过,不是用了Scrum你就敏捷了。在很多时候,形式上运用Scrum的团队其实是在实施所谓Water-Scrum-Fall的假敏捷。迭代只发生在开发阶段,每个迭代只是不断输出不能上线的半成品。

我们说实施敏捷不应该陷入形式主义,要回到敏捷的目标——更好、更快地实现业务价值,我们该怎么做呢?

01

每个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都交付了目标内一定的价值。

02

我们还需要路线图

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

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


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


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


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

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

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

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

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

03

总结

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzI1MjQ3NzE2Mw==&mid=2247485041&idx=1&sn=a7f2ad6df344054b7c8a24187fa2ba7d&chksm=e9e26df5de95e4e3cbd0fcca2c1f5892bce42bf1309e2deb92e9ca4bb5cd8aae5998cdbdd837#rd