Scope-Question-Assumption需求讨论会

作者：Jacky Shen 申健

关于需求的讨论

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

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

角色

Product Owner 或业务方
负责讲解需求，回答关于需求细节与优先级的问题。
Scrum Master 或引导者或主持人
负责设计讨论议程，计时、控制场面。

团队

负责提问、评估技术风险、对需求给出建议、澄清细节、给PO提供方案选择、将需求分解为验收条件。

过程

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

大便、石头、钻石

大便：不知道在说什么
石头：需求清楚，但有些测试场景还没想全
钻石：需求100%清楚

产出

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

参考：
需求梳理工作坊引导技术