需求梳理工作坊引导技术

个人经常在辅导客户团队时,引导召开需求梳理工作坊。这里是一些自己的心得。

参加的人员一般有产品负责人(PO),团队所有人,包括开发职能和测试职能。这里我故意淡化开发人员和测试人员的概念,因为scrum团队追求的是跨职能的组合,职能可以有分工,但职位没有分别。
一般需求梳理工作坊发生的时间是提前1~2个迭代(sprint) 之前滚动式进行,目的是留出足够的时间来准备。越长的sprint就需要越早做准备。需求梳理活动占用整个sprint时间的5%~10%。
PO与团队代表可以随时沟通,而全体人员参加的工作坊则代价较高,但好处是每个成员都有机会了解整个团队的状况,有助于知识和经验的传播,及跨职能的培养。另外,每个人也都有机会面对面与PO互动和发挥创造性,结果是提高沟通效率并且集思广益。

准备

选择大型会议室作为开放空间,将所有待梳理的用户故事写在报事贴或卡片,并有序地贴在墙上。相隔一定距离便于走动和讨论。另外准备一些活动挂图(Flip Chart)供团队写写画画辅助讨论。还可以将已做完的用户故事及其估算贴出来,作为估算的参考基准。

第一部分,集体讨论

根据团队人数可以选择分成小组。PO简单介绍用户故事的内容(团队成员最好事先有所了解,以提高会议效率)。然后设定时间盒(Time-box),各小组针对面前的用户故事墙讨论范围(Scope)定义明确的验收条件(Acceptance Criteria,简称AC)。每张报事贴或卡片上写一个AC。推荐使用Given-When-Then的形式,好处是辅助思考并且便于后续转化为自动化测试。明确的验收条件将作为PO在sprint review时验收的非黑即白的标准,”When you play the game of scrum you done or you fail. There is no middle ground.”
有任何疑问(Question)假设(Assumption)随时与PO澄清;如果当场没有答案,则记录在Flip Chart上,指定负责人会后跟进。
对于AC特别多的用户故事,引导师可以建议将其分解为更小的用户故事。
注意,需求梳理更多关注在what层面,而非涉及how层面的具体技术任务。
时间盒到期后,停止讨论,对于非常不清楚的用户故事,引导师可以建议推迟到下次。

可选地,引导师考虑增加一些时间盒继续讨论。
可选地,让不同小组巡游到其他小组交换想法,同样需要时间盒。

第二部分,相对估算

使用man-hour的缺点在于每个人的技能水平不同,因此估算很难达成一致,或变成领任务者的自娱自乐,极端的情况下会造成不信任。
相对估算是将任务工作量(包括风险和不确定性)与个人分离开,因为不论谁来做,任务之间的相对比例是不变的。

引导师首先让大家回顾一下已完成用户故事点的单位基准。
大家围成一圈,先由第一个人选出一个适中大小的故事,贴在中间位置。然后依次挑出一个(只能一个)故事,如果比已有故事小,就贴在左侧,如果比已有故事大,就贴在右侧,形成横轴从大到小的故事泳道。如果差不多大小就贴在并列在同一列。每人都轮过一次后,引导师再问问还有没人愿意移动。没有的话进入第二个循环。
将斐波那契数列卡片(引导师只提供1,2,3,5及∞)或用计划扑克®,仍然大家轮流移动数字,放在认为合适的故事列之上。

对于过大的故事,引导师会建议PO后续分拆、进一步澄清,或是调整优先级。
当所有人都没有意见后,统计总点数,并拍照留待后续整理到电子工具或Wiki。


觉得本文有帮助,长按二维码进行微信打赏