Scope-Question-Assumption需求梳理会(需求澄清预习PK)

SQA-workshop

关于需求的讨论

最近在辅导敏捷团队和教授Scrum课程中,发现团队提出的很多的问题现象可以归结为迭代前需求梳理(Refinement/Grooming)讨论不充分所导致。
根据自己多年亲身实践的敏捷经验,如果在迭代的计划会议上,团队来不及做到澄清和一致理解需求,而是在迭代过程中再进行需求澄清,那么往往导致“迭代紧张、测试不充分、估算不准确、精神面貌不良”等表面现象。
因此,对需求的充分理解应该是迭代的入口条件,应该成为Definition of Done (也有同学喜欢称之DoR, 笔者认为DoR也是DoD的一部分) 的一部分,来确保迭代能够健康地开始。
然后,更深入的根源则是团队不了解如何进行一场高效充分的讨论

敏捷是一种辅助实现交付价值的手段,不应该过于繁重。下面就根据@申导 早年在诺基亚西门子通信工作时所学到的一种简洁讨论法:Scope-Question-Assumption(简称SQA)讨论会。

参与角色

  • Product Owner 产品负责人或业务需求方:负责讲解需求,回答关于需求细节与优先级的问题。
  • Scrum Master 或引导者或主持人:负责设计讨论议程,计时、控制场面。
  • 研发团队(包括BA、程序员、测试人员):负责提问、评估技术风险、对需求给出建议、澄清细节、给PO提供方案选择、将需求分解为验收条件。

过程

  • 找一间开阔的会议室或者讨论区,移除多余的桌椅,便于走动。在墙上事先贴好多张白板纸(大白纸、Flip Chart)。在大白纸上分别写上Scope范围Question疑问Assumption假设。准备足够的报事贴和水性笔。
  • 团队分为3-4人的小组,包含开发与测试。主持人不参与讨论,负责计时和引导过程。讲解需求的人作为自由人在各小组轮流走动。
  • 由PO迅速讲解各个大需求,并根据业务价值做大概的排序(见下文的业务价值矩阵,也可以绘制成用户故事地图的方式。然后每组“抢”一些需求卡片,按照对需求的清晰度来分类。
  • 按顺序针对一个用户故事或需求点进行讨论。在Scope范围纸上记录下要做或者不要做的需求内容,以及分解以后的验收条件。在Assumption假设纸上记录下目前方案基于的假设与依赖,这些可以是当前确定的共识,但将来有可能存在变化的风险。在Question疑问纸上记录下目前PO无法回答的疑问,在会后需要进一步澄清。
  • 每15分钟,每个小组留下最熟悉和最不熟悉的各一个人,其余人按照顺时针移动到下一个小组去提问。每组留下的人负责给其他组移动过来的人讲解目前的讨论结果,解答问题,一起继续讨论。在这个“异花传粉”的过程中,不同人的不同想法会得到碰撞、激发、涌现,形成“杂交优势”,所有人能够“共同进化”。
  • (可选)随后可以根据情况,决定是否进行任务分拆。除了最熟悉和最不熟悉的人,其他人自行决定加入哪组。花20分钟自行分解任务。分解后的粒度希望达到2天左右工作量的大小,并且能够开发、测试及演示,或称满足DoR。
  • 主持人询问大家对结果是否满意,以及为什么不满意。
  • 对于AC特别多的用户故事,引导师可以建议将其分解为更小的用户故事。注意,需求梳理更多关注在what层面,而非涉及how层面的具体技术任务。
  • 任务拆分的清晰度同样可以用“乱麻、砖头、钻石”来分类。并采用动物体积、T-Shirt Size、相对故事点等方式进行估算。
  • 时间盒到期后,停止讨论,对于非常不清楚的用户故事,引导师可以建议推迟到下次。

清晰度

  • 乱麻:不知道在说什么
  • 砖头:基本有轮廓了,但场景还没想全或看不出
  • 钻石:需求100%清晰明了,能完整复述出来

业务价值

  • 白开水:说不出来用途,根本是没人用的伪需求
  • 糖水:能解决一些实际问题,但也有一部分是自嗨
  • 灵芝汤:迫切需要,针对要害,生死攸关

相对估算2.0 (计划扑克®升级版)

  • 引导师首先让大家回顾一下已完成用户故事点的单位基准。
  • 大家围成一圈,先由第一个人选出一个适中大小的故事,贴在中间位置。然后依次挑出一个(只能一个)故事,如果比已有故事小,就贴在左侧,如果比已有故事大,就贴在右侧,形成横轴从大到小的故事泳道。如果差不多大小就贴在并列在同一列。每人都轮过一次后,引导师再问问还有没人愿意移动。没有的话进入第二个循环。
  • 将斐波那契数列卡片(引导师只提供1,2,3,5及∞)或用计划扑克®,仍然大家轮流移动数字,放在认为合适的故事列之上。
  • 对于过大的故事,引导师会建议PO后续分拆、进一步澄清,或是调整优先级。
  • 当所有人都没有意见后,统计总点数,并拍照留待后续整理到电子工具或Wiki。

产出

  • 验收条件(AC),具备实例,最好能够转化为自动化测试。可以借助Given-When-Then的格式来编写。
  • 其他辅助澄清需求的格式,包括流程图、顺序图等图表。
  • 分解后的用户故事。
  • 优先级重排之后的产品待办列表(Product Backlog)