产品待办列表梳理(PBR)是什么?

本文详细介绍了Scrum框架下的产品待办列表梳理(PBR)活动,包括其目的、内容、参与者及时间安排等内容,并提供了实用的指导原则。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

产品待办列表(PBL)是Scrum框架下最重要的一个工件(Artifact),产品待办列表的梳理(Product backlog Refinement-PBR)也是一个重要的活动,它不同于Scrum的3-3-5-5。仔细阅读Scrum指南,对产品待办列表梳理活动的描述是有限的:

“只有那些Scrum团队可以在一个Sprint中完成的产品待办事项,才能作为Sprint计划会议中的准备就绪事项。这种透明度通常需要通过“产品待办列表梳理”活动来获得。产品待办列表梳理是将产品待办事项进行拆分,并进一步梳理为更小更精确的事项。这是一项持续不断的活动,用来为产品待办事项补充细节,包括细节描述,排序和评估大小等。添加的细节属性通常随工作领域的不同而变化。”

在CSM的培训中,我发现有时学员把PBR活动与Sprint计划会议混为一谈,在Sprint计划会议上做产品待办列表梳理。有时把产品待办列表的梳理说成是Sprint Backlog的梳理。借机来写一篇文章,“梳理”一下产品待办列表梳理活动的概念。结合多年教学咨询的经验,与国际敏捷专家在敏捷社区的切磋,分享我理解的PBR的具体做法和常见误区,对Scrum指南的PBR部分也是一个补充和解读。

1. 为什么要做产品待办列表梳理PBR?(why)

我们承认对于敏捷项目或产品,需求是一个渐进明细的过程,过早的锁定范围和细化需求是不明智的。所以,需求的梳理是一个持续的活动,一个just in time的规划过程。即每个迭代的过程中,开发团队除了围绕Sprint的目标,按照Sprint Backlog(SBL)的计划尽力实现承诺的产品待办条目(Product backlog Item - PBI)之外,还要抽出一部分时间来协助PO梳理需求,确保下一个迭代计划会议的需求是就绪的(ready)。这样做的目的,增加了Sprint计划会议团队承诺的信心指数,大大降低了交付的风险。

那么问题来了,准备多少个PBI和PBI梳理到什么程度算是比较合适呢?一般情况下,我们建议准备1-2个Sprint的需求,最多不要超过3个Sprint的内容, 采取刚刚好(just enough)的策略。试想一下,只准备一个迭代的需求可能不够,另外PBL的优先级可能会发生变化,所以稍微多准备一些。但梳理太多会造成不必要的浪费, 因为情况总是在发生变化。产品待办列表的梳理活动上,团队不会承诺下一个Sprint做多少。

有什么样的原则能够指导PBL梳理就绪?

产品待办列表PBL满足“DEEP”的特征。通常我们用DEEP来体检PBL的健康状态。

D: 需求的颗粒度有不同的层级,优先级高的需求细化。

E: 估算PBI的成本大小。

E: 拥抱需求变化,新的涌现出来的需求,以PBI的形式添加在PBL中。 

P: 排优先级,即排序。

对于PBI的就绪,主要满足大家熟悉的INVEST的原则(见下图对INVEST的解释),Scrum的模式语言Definition of Ready(DoR)对我们的实践指导是有效的,尽管DoR不是Scrum的核心内容,但会帮助我们理解PBR活动的重要性。定义DoR的维度,除了INVEST以外,还考虑:提前识别技术难点(spike);依赖关系;UI/UX的设计工作;合规和法律认证的事宜。一个DoR的例子如下:

2. PBR活动包括什么具体内容(what)

主要包括:

  • 对PBI的业务价值和验收标准的澄清,讨论足够的细节,包括新近加入PBL的优先级高的需求条目。

  • 大的需求(Epic)的拆分(breakdown),注意是对PBI的拆分,不是传统的任务分解(WBS)。如果PBI的优先级很高,要拆到这个PBI能够fit到Sprint中,不同PBI拆分有不同的策略,这里不再叙述。

  • 估算,有时也叫Sizing,总之是估PBI的effort。敏捷推荐相对估算。建议对所有的PBI都要给出估算(如果可能的话),注意这里不是指SBL的条目SBI,任务的估算。 

  • 对PBL的重新排优先级,PO会按自己的价值方法对PBL的排序,在PBR活动中,开发团队协助PO审视PBL优先级的合理性,比如涉及PBI之间的技术依赖或资源约束条件等,重新排优先级。

  • 另一个最重要的动作,看看哪些需求没有价值,不合理,从PBL删除,保证PBL的健康度(good shape),有时用邓巴数(150定律)作为参考PBI的个数。

Scrum框架中设计的持续进行的产品待办列表梳理活动(PBR)是一个落地的“对话”实践。研发和业务人员以对话为核心,采用不同的技术和工具,补充丰富并完善细化PBL。敏捷团队的具体实践有:交互式原型(UI prototype),线框图,视觉模型,流程图(flow chart),Mockup,Wiki Page形式支持文档,简短的讨论文案,包括算法和技术要点等等, 都是进一步细化需求的手段。

有人会问,PBI的大小就绪(ready)有什么特征或指导,这里有三个原则供参考:

  • 1/2原则:一个PBI或用户故事(user story)满足sprinting-able,假如由一个开发人员搞定这个PBI,不应该超过Sprint长度的1/2的时间。   

  • 1/4 原则:一个PBI的大小,团队去实现它,不要超过Sprint长度的1/4时间。 

  • 用户故事点8:大于8个点的用户故事,给我们一个信号,需要拆分。具体实践下来,团队会找到大家认可的基准和公用尺码,比如2个点的用户故事意谓着多大的工作量。 

3. 谁来参加PBR(who)?

我们强调全员都参加(inclusive),即整个Scrum团队,PBR活动会增加成员的参与感(engagement)。工作坊的形式很重要,用户故事卡片会自然引发对话。

不像传统的做法,只有少部分人员或资深的工程师参加。全员参加的好处,保证PO与开发团队面对面沟通,通过对话的形式理解业务需求,信息对称。有时候PO会邀请关键的干系人(key stakeholders)参加;特别是需求的提出方,或是Feature Owner。Scrum鼓励开发团队与用户的直接沟通,而不是所有的信息都要通过PO,PO不是中间人(middle man)。这种对话SM可充当引导者,保证沟通高效,PO或客户直接澄清需求给团队。

这样做,也许会有人担心:

(1)业务担心需求“失控”,开发团队会对客户承诺太多。有时候我们担心研发搞砸(mess-up),嫌麻烦,所以会找个借口,比如开发人员驾驭客户的能力不够,演讲(Presentation)能力不“专业”,不邀请他们参加此种会议或对话,图省事。其实,让真正“干活”的人第一时间理解为什么要做这件事情比如何做更要紧。把团队封闭管控起来,不允许与客户用户直接沟通,潜在的风险更大。把“正确”的需求做“对”,是我们的共同目标,PO可以在这个“对话”过程中充当引导者的角色,便于管理。   

(2)干系人(包括sponsor和管理者)平时很忙,没有时间参加此类PBR的活动。每次PBR的活动,PO有责任邀请相关的干系人参加。具体的做法,PBR活动提前在Scrum日历上固定下来,让需求相关的干系人可以分时段参加PBR,不需要干系人全程都参加PBR。合理分配好时间,通过面对面的对话,对需求的充分理解,是把事情做对的关键一步。

你会发现,Scrum设计的PBR活动,从某种角度解释,它把敏捷原则的第四条“项目过程日常工作中,业务人员与开发人员必须在一起工作”实实在在的落地了,业务和研发的“协作”变成了具体可操作的“动作”。

4. 什么时候做?(when) 做多长时间?(how long)

PBR是一个持续的活动,一个不好的消息是,Scrum没有特别“告诉”你什么时候做PBR。推荐的做法:在Scrum的日历上以工作坊(workshop)的形式把它固定下来,有些团队叫Backlog Grooming,比如一个Scrum团队提早约定好在两周迭代的第二周的周二下午3点到4点半做PBR,届时大家都会出席, 当然PO要做好充分的准备。Scrum建议开发团队在每个迭代过程中投资团队容量(capacity)的5-10%时间协助PO梳理PBL,注意5-10%是一个累加总值,PBR可以在迭代中做多次,有时是估算,有时是拆分,也可能是估算和拆分的混合。    

根据我的观察,PBR的活动分布在Sprint过程中的以下时段:

A. PBR在Sprint 1之前的发布(版本)规划中或follow-up session,保证第一个Sprint的需求就绪(ready)。

B. 在Sprint过程中安排每周一次或每个迭代一次的梳理活动,时间固定下来,不需要有专人协调时间。

C. 每日站会结束后,安排单独的小块时间梳理部分需求,特别是分布式团队,PO和团队不在同一地方。考虑到时差和异地的影响因素,不用再单独协调大家PBR时间。

D. Sprint评审会结束之前,留出一部分时间来一起看看未来的1-3个Sprint要做什么,基于评审会的反馈调整PBL,影响到发布计划。好处是干系人正好在现场,不需要单独邀请,节约时间,而且评审会刚刚开完,趁热打铁。不好的地方是离下一个Sprint计划会议太近,有些匆忙,而且评审会已经消耗了能量,需要休整。

最后,期待这篇文章对产品待办列表梳理PBR的困惑有所解答。如果能参加CSM/CSPO课程,你将体验到产品待办列表梳理各项活动:PBI的进一步澄清(业务价值和满意条件),估算,拆分,排优先级的技术和实践。 

Jim Wang王军

写于2022年12月5日

参考资料:

(1) CSPO 教材

(2) Scrum 指南

(3)《Scrum Essential》 By Ken Rubin 

### NPR 与 PBR 的定义与应用 #### 定义 **PBR(Physically Based Rendering)** 是一种基于物理真实光照模型的渲染技术。它通过精确模拟光线在场景中的传播、反射和折射等行为,使得渲染结果更加接近现实世界的效果。PBR的核心在于使用了符合物理规律的光照计算方法,这包括对材质属性(如粗糙度、金属感)以及光源特性的精确建模[^1]。 **NPR(Non-Photorealistic Rendering)**,即非真实感渲染,是一种旨在生成具有艺术风格或抽象表现形式的图像的技术。与追求逼真效果的PBR不同,NPR更注重于模仿手绘、油画、卡通或其他视觉艺术风格的表现方式。它可以自由地打破物理规则,从而创造出富有创意和个性化的视觉体验[^1]。 #### 应用 **PBR的应用领域主要包括:** - **游戏开发**:许多现代视频游戏采用PBR来提升画面的真实感,尤其是在角色模型、环境纹理等方面[^2]。 - **影视特效**:电影工业中广泛使用PBR技术来创建高质量的视觉效果,确保光影交互的真实性。 - **建筑设计可视化**:建筑师利用PBR来进行室内设计预览,帮助客户更好地理解最终成果。 **NPR的应用则更为多样化且偏向艺术创作:** - **动画制作**:卡通风格的角色设计常常借助NPR技术实现独特的外观特征,例如边缘勾勒、色彩简化等效果[^3]。 - **数据可视化**:将复杂的数据集转化为易于理解的艺术化图表时,NPR能够提供更具吸引力的表现形式。 - **教育工具**:教学软件可能会运用NPR来创造更加生动有趣的插图,吸引学生的注意力。 #### 技术结合实例 尽管PBR与NPR看起来是两个截然不同的方向,但在实际项目中它们也可以相互融合。比如,在保持整体场景具有一定卡通感的同时,仍然可以应用部分PBR原理以增强某些细节的真实度;反之亦然,即使是在高度写实的画面里加入少量NPR元素也能为作品增添独特魅力。这种跨界的尝试不仅丰富了视觉语言的表现力,也为创作者提供了更多可能性[^2]。 ```python # 示例代码 - 使用Python绘制一个简单的卡通风格图形 import matplotlib.pyplot as plt from matplotlib.patches import Wedge fig, ax = plt.subplots() # 创建一个圆形作为基础形状 circle = plt.Circle((0.5, 0.5), 0.4, color='yellow') ax.add_artist(circle) # 添加眼睛 eye1 = plt.Circle((0.35, 0.6), 0.05, color='black') eye2 = plt.Circle((0.65, 0.6), 0.05, color='black') ax.add_patch(eye1) ax.add_patch(eye2) # 添加微笑 smile = Wedge(center=(0.5, 0.5), r=0.3, theta1=20, theta2=160, facecolor='none', edgecolor='black', linewidth=2) ax.add_patch(smile) plt.axis('equal') plt.show() ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值