分享到社交媒体:

本文首发于「BY林子」,转载请参考版权声明


「质量三人行」播客在3月发布的一期《那些在需求评审和迭代计划会议中容易忽视的质量问题》,其中有个关于需求梳理会的问题:

问:周期为两周的迭代,团队的需求梳理会要花1-2天时间,这是合适的吗?
答:不合适,这个梳理会太重了!

有朋友听完播客给我们留言说他们现在就是这么做的,觉得2天是可以接受的。

因此,本文就这个话题跟大家聊聊。

01 什么是需求梳理会?

需求梳理会也称为Product Backlog Grooming Meeting,通常指的是团队定期进行的一系列活动,以确保产品需求列表(Product Backlog)中的所有需求都足够明确、可操作、可测量,并为团队的开发工作提供足够的指导。

在Grooming过程中,团队成员将一起审查、讨论和精炼产品需求列表中的用户故事(User Story),以确保它们已经足够详细、具体,并与其他用户故事之间形成逻辑关系。

02 每次需求梳理会的理想时长是多少?

我想先问下大家:

如果一个团队在一起讨论需求,你觉得多长时间是你能坐得住并能高效参与讨论的?

就我个人而言,一个小时内我能高效参与,再长到两个小时我还能接受,两个小时以上我的脑子可能就不转了,也没有耐心参与讨论了。

其实,2周一个迭代的敏捷开发模式,每次需求梳理会在1-2个小时比较合适,最多也不要超过半天。整个团队坐在一起开太长时间的会,那真的是非常痛苦也非常低效。

03 每个迭代的需求梳理会需要开两天是合适的吗?

不要对任何别的团队实践妄下结论,需要具体情况具体分析。如果迭代周期为两周,有的团队每个迭代要开两天的需求梳理会,而团队自己觉得是合适和必要的。我首先愿意相信那应该是基于团队现状所采取的最佳实践。

那么,是不是自己团队觉得每个迭代用两天来梳理需求,就可以保持现状呢?答案当然是否定的。

毕竟,每个迭代要花20%的时间痛苦而低效地讨论需求,真的是很不健康的状态。如果你的团队正好是这样的,我建议团队花点时间来分析一下,找出需要这么长时间的原因。

04 导致需求梳理会时间很长的因素有哪些?

通常,根据我的经验,需求梳理会的时间长短可能会受以下几个因素的影响:

1. 业务需求或系统架构相关

业务需求和系统架构可能是一个非常关键的影响因素,常见的相关问题有:

  • 对于新产品、非常复杂的产品需求或者复杂的系统架构,都可能需要更多时间去讨论和澄清;
  • 需求拆分不合理,团队间依赖较强,也可能会有影响;
  • 前期没有对需求进行必要的分析,直接拉上团队所有人来梳理,这也不太可能做到高效。
2. 团队现状相关

团队本身的情况也是影响会议时长的重要因素,通常可能有如下两种情况:

  • 团队成员间的沟通和协作情况,如果沟通不畅或协作意识不强,需求梳理会上的讨论就很难顺利进行。团队规模太大,组织架构过于复杂,或者团队在形成初期,都有可能会出现沟通协作不顺利的情况。
  • 团队成员的技术水平和经验:团队成员的技术水平和经验差异较大时,确保每个人对需求的理解达成共识可能需要更多时间。
3. 会议相关

会议是否高效,跟会议召开情况也是密切相关。比如:

  • 缺乏清晰的目标和计划:需求梳理会和任何会议一样,如果没有明确的目标和计划,很可能会讨论过于发散,导致低效、耗时长。
  • 会前准备不充分:除了前面提到的需要会前对需求进行初步的分析,会前还需要相应的角色对系统架构、系统相关代码实现情况、系统其他相似功能被用户使用的情况等进行调研。如果没有做足会前准备,这些调研可能需要在需求梳理会上来进行,肯定会影响需求梳理的效率。

04 需求梳理会时间过长怎么优化?

基于前面对影响因素的分析,我们不难逐个找出优化方案。这里我基于个人项目经验,总结如下建议:

1. 控制每次会议上需要梳理的需求量

过于复杂的需求要先进行拆分,并且按价值和开发依赖关系排列优先级,将小块需求分批次进行梳理,不要在一次需求梳理会上讨论复杂的大块需求。每个迭代的需求梳理会不一定是一次性活动,可以/应该持续地进行。

2. 纵向切分需求,减少依赖

不要将需求横向切分(有的是将需求横向切分给不同的团队),这样不同需求模块之间的依赖过强,没法独立交付,自然梳理过程也就更加复杂,因为需要增加很多依赖的处理。纵向切分的需求相对更容易独立开发和交付,分析起来也会更加顺畅。

3. 提前做足功课,减少团队大规模讨论的时长

在召开全组的需求梳理会之前,业务分析师需要整理尽可能多的业务需求相关信息,技术人员同步对系统架构和系统代码实现情况进行调研,思考技术方案;还需要测试人员对系统其它相关功能的使用情况、现有缺陷数据进行了解。

我之前项目经历是在进行这些分析和调研之后,业务分析师、技术负责人和测试负责人会一起对业务实现方案进行讨论和梳理,然后才是全组人员参与的需求梳理会,那个时候需求基本定型了,主要是跟团队进行更新以及讨论前期可能遗漏/遗留的问题,时间不会太长。

4. 控制团队规模

开发团队的规模不要太大,如果业务需求实在无法再次拆分给更小的团队,也可以按照需求模块来分批次进行需求梳理会,参考结合前面第1、3两点来处理。

5. 增强团队的沟通和协作

对于团队沟通和协作方面存在的问题,得从团队管理和建设的角度去寻求解决方案,之前有相关文章讨论过类似的场景,比如:

6. 掌握会议原则,提高召开效率

如果是会议本身效率不高的问题,可能需要参考《高效会议的13条军规》来调整和优化。

05 写在最后

本文是由需求梳理会的时长问题引发的讨论,分析下来我们发现这不一定某一方面的问题,需要系统性地从全局来看,找出关键的根因,才有可能从本质上解决问题。

任何实践都不能生搬硬套,适合自己的才更有价值。别人家的优秀实践可以参考,但要结合自身情况进行调整和定制化。此外,需要定期回顾总结并持续改进,以确保该实践始终符合自身现状。

06 推荐阅读


本文首发于「BY林子」,转载请参考版权声明

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注