欢迎来到Scrum就只是3355吗？
222 2023-07-13
01
什么是Scrum的3355？
我们在开始学习Scrum的时候，老司机们经常会语重心长的教导我们：“学Scrum，你只需要掌握3355即可。”
3个角色分别指产品负责人、Scrum Master和团队这三种角色
３个工件分别指产品列表、Sprint列表和潜在可交付产品PSPI
５个活动分别指Sprint计划会、每日站会、Sprint评审会、Sprint回顾会和下迭代需求梳理会
５个价值观分别指勇气、公开、专注、承诺和尊重。
02
Scrum的多层级
Kenneth的Scrum多层级规划覆盖了一个完整的产品开发生命周期，让人们非常清楚的知道产品从无到有的整个过程中Scrum应该如何去支持的。
03
产品组合规划
产品组合规划主要是用来确定要完成什么产品、按照什么顺序完成以及需要持续多长时间。它是考虑不同产品通过最优组合来实现组织利益最大化的过程。一个产品组合包含多个产品。
产品组合规划是永无休止的活动，只要还有产品需要研发和维护，就需要进行。一般活动参与者包括内部利益干系人、产品负责人、高级架构师和技术主管等。
产品组合规划的流程包括输入和输出。输入一般分为两种：
新产品数据：例如成本、时限、价值、风险等
流程中产品数据：例如中间顾客反馈、更新成本、进度安排、范围预估、技术债务状况、产品未来出路的市场相关数据
而输出一般也分为两种：
组合列表：已经确定优先顺序的未来产品具体工作清淡，已经通过批准还没有开始开发
一系列活动的产品：包括已经批准并立即开发的新产品；目前处于生产过程的产品和已经批准可以继续开发的产品
那么在组合规划中到底哪个产品先开发哪个晚开发呢？当然，我们有一些优先级排序的基准。首先要考虑的是产品的生命周期利润，简单来说就是越能挣钱的产品越要优先做。
不过如果一个产品确实是很挣钱，但是确需要5年才能做出来，这时候是不是高优先级呢？不一定！所以我们还需要考虑第二个基准就是延期成本。延期成本等于业务价值+时间紧迫性+降低风险和/或促进机会的成本。一般我们会通过加权最短任务优先WSJF来帮助判断优先级。
所以从一个构想到被批准是否纳入产品组合规划我们可以通过建立一个经济过滤器来帮忙筛选。这个经济过滤器定义了一些经济指标，从而帮助我们更好的判断产品是否需要开发以及开发的优先顺序如何。
0４
产品规划
产品规划主要是获得潜在产品的基本特性并为创建该产品而制定大致计划。一个产品会包括多个版本。产品规划的目标是详细阐述这个想法，描绘潜在产品的精髓，然后建立一个粗略的完成计划。
产品规划的参与者一般是PO会邀请内部利益干系人一起粗略的讨论初步产品设想。如果在这个时候Scrum团队已经组建的话，那当然也需要参与其中。
在产品规划过程中的输入包括有初始想法、规划期、完成日期、预算、资源、信心门槛等；而输出则会包括产品愿景、产品列表和产品路线图。我们需要注意的是，这时的产品列表还是以史诗为主，而这时负责写故事的人包括PO、利益干系人、做好有团队参与。
对于产品路线图，我们主要是把产品的实现分成不同的里程碑，每个里程碑我们会完成什么特性、在市场上如何推广、设计到的架构、还有发布计划如何等。路线图事件跨度要合理，够用就行，比如时间跨度为9个月。
0５
版本规划
版本规划主要是针对产品按版本的增量交付而取得范围、日期和预算之间的平衡。一个版本包括1到多个Sprint。
版本规划不是一次性工作，在构想规划后就开始做版本规划，一般持续一两天。版本计划可以改变的。版本计划修改可以在每次sprint评审时进行，也可以在平时为后续每一个sprint做准备或执行每一个sprint时进行。一般版本规划的参与者包括干系人和整个Scrum团队。
在版本规划过程的输入包括：产品构想、概要产品列表、产品路线图和速率等；而输出则包括：特性范围、Sprint范围、最小可发布特性集、Sprint映射。
最小可发布特性集是指当我们在发布时最低能接受发布的产品特性集，一般是由产品负责人来定义。而最小可发布特性集花的时间应该为占整个版本工作时间的60%-70%为最佳。
0６
Sprint规划与日常规划
Sprint规划在是每个Sprint开始时进行，对团队在本次sprint中做哪些特定的PBI达成一致意见。而日常规划其实就是团队的每日例会，它是Scrum中最详尽具体的计划。这两个规划已经包含在我们上面的3355中，这里就不赘述了。
0７
需求抽象层级
我们再来看看需求的抽象层级结构。在敏捷中，根据需求颗粒度大小以及详细程度的不同，会有不同级别的的需求。为什么呢？
因为我们知道了Scrum的不同层级，如果我们在产品规划或者版本规划时使用的是Sprint级别的故事，则会太小太多。试想一下，如果在产品规划时我们拿着500个Sprint层级的用户故事向高管介绍，这会让他们淹没在大量无关的细节中而迷失了重点。
另外一个例子，如果故事只有一种大小，我们就必须在很早的时候需要把所有需求的细节定义到极小颗粒度的级别，而这个明显是不符合敏捷“刚好够用（Just-in-Time）”原则的。所以在产品或者版本规划时我们是不需要这么细致的需求的，我们需要更少、更不详细、更抽象的条目。
因此根据需求抽象程度的不同，我们把用户需求分成以下几个层级，如下图所示：
史诗：属于最高层级的需求，就像鸿篇巨著一样。一般一个史诗约为一两个到好几个月的大小，可跨越一整个或多个版本。
特性：属于第二级别的需求，通常特性的大小以周为单位。但是对于单个Sprint来说还是有点大。
故事：最小粒度的用户需求。它的大小以天为单位，足够小，必须在一个Sprint内完成。
任务：任务位于故事的下面一级，但是任务不是需求，而是为了完成故事需要做的工作。通常任务是一个人独立完成的工作，或者也有可能两个人结对完成，一般以小时为单位。
主题：一组相关联的需求的总称，通常这些需求有共性或者属于同一功能域。
08
总结
总的来说，Scrum并不只是3355，它所包含的内容非常丰富。也值得我们花时间好好学学习和研究。
相关阅读：
关于作者
-
联系我们
电话：4006 8899 23 邮箱：beining@easycorp.ltd -
融实践库
关于我们 加入我们立即学习
微信号：xdwjack
-
微信公众号
-
微信视频号
-
社区微信群
