用户故事地图(8):开发流程之“故事工作坊”阶段

入冬许久,今天才刚刚有点凉意,把早早拿出来的卫衣换上。写这篇文章的此时,我和朋友们坐在星巴克,一边感受着久违的闲适,一边懒散的码着字。前两天回顾2018年计划——《用户故事地图》读书笔记是做为年度计划来准备的,看来我早就知这件事情的困难——翻译的书真是太难懂。看看思维导图后面还有很多内容,不知道在12月底之前,是否能把它们全都写完。


从各方收集到的需求(用户故事),经过了机会阶段的初步筛选、探索阶段的设计与开发侧的可行性评估,以及设计方案的实现和验证。接下来,将会进入团队共同参与的故事工作坊(在我看来就是项目需求评审会,以下均称为“评审会”),它也称为最后一次最佳参与的机会。

这一阶段主要讨论细节,其目标有2点:

  1. 基于开发层面拆分需求为小模块,以制定后续开发任务的迭代计划;
  2. 对开发的各个小模块达成一致的验收标准;

准备阶段

首先,在会议开始前要选择粒度合适的故事进入评审,清楚这些需求必要的细节,如有必要可以提供多种方案来进行评估。

提前邀请开发团队、其他利益相关人士等进入会议,例如开发人员、测试人员、体验专家、视觉相关设计师,总数在3〜5为益。为保证会议效率,会议人员不益过多(我们都经历过又臭又长的会议)。然而,在同一场会议中,在不同阶段可能需要不同的人参与。这里介绍一个“金鱼缸协作模式”,可以保证让更多人参与,同时降低人数太多造成的影响。

金鱼缸协作模式

具体如上图。参与讨论的3〜5个人聚集在白板前讨论——他们就是鱼缸里的金鱼。处于鱼缸(上图中的圈)外面的人只能看,不能讲话。鱼缸外的人要想参与讨论,必须与鱼缸里的人互换才行。

待上述内容准备就续后,接下来正式进入评审会。

执行阶段

1、与所有人一起,再次了解故事的大体情况

与前几个阶段一样,会议开始时候我们依然需要讲清楚3W(what、why、who)信息。有时候我们会认为团队成员不关心产品,只完成自己应该做的内容,不会从整体考虑。但我认为真实的原因是,项目并没有创造让成员们关心产品的环境,需求来源往往下意识认为其他人执行即可,不需要了解太多背景信息。同时也为了节省时间,会在评审会时直接讲解需求内容。这恰恰剥夺了成员们了解产品的机会。由此可见,讲清楚每个需求的3W信息(特别是why)非常必要。

在会议中,所有人通过讨论和交流,明确几个内容:

  • 用户是谁?
  • 他们是如何使用产品的?
  • 功能完成后看起来应该是怎样的?
  • 我们要如何开发这些功能,他们的工作原理(业务逻辑、数据等)是怎样的?

在讨论方案过程中,尽量以用户视角来讨论,例如“用户在做什么”、“用户接下来会看到什么”。若遇到产品内部逻辑时候,可以使用“数据是如何输入的”这样的表述方式,更容易被所有人理解。

会议中随时记录大家的想法和点子。非常建议借助一些道具来记录,例如白板、挂图、便利贴等,这样即可以防止信息被蒸发,也可以让大家都看到所有内容。(近期看了一本书《设计冲刺》,同样倡议使用这样的方法)。

2、分组讨论

待所有人了解了功能的大概内容和运行原理之后,接下来要将参与人员分组,尽量保证每个小组有测试人员、开发人员、体验设计师或需求人员。各组用固定时间,制作出这些用户故事的开发计划(估时)。

3、小组间分享计划和估时

每个小组分享他们制定的开发计划(不要讲细节),在此期间,需要指出开发功能的问题和改进点,并估算开发时间。

对很多人来讲,估算开始时间有时候是不太可能的。我猜测主要是对待开发内容和原有产品运行机制不了解导致:未知=不可估。而用户故事地图的过程,可以帮助大家对功能开发内容达成一致性的理解。此外,还可以将相似规模需求的实际开发时间做为样本,以让开发时间估算尽量接近于真实值。而对于这一点,则需要我们对已投入的开发时间进行记录,尽可能将大的计划切分为小的部分,这样就可以获得更多度量的机会。度量越频繁,统计的时间结果越接近于真实值。

会议人员需要对上述开发决策和另外一项内容达成共识。“另外一项内容” 是指,验证功能开发完成的最低标准(换句话说,就是一起评审软件时,应如何展示开发的内容,例如按用户操作流程,保证这个流程可以走通)。对验收标准的讨论,可以揭示如何进行工作分解。我们可以开发分解后得到的故事,并进行及时的检查和调整。

异常情况

用户故事工作坊的效果可能不会理想(开过需求评审会的同学应该深有体会),有几点原因可能会导致这一情况的出现:

  • 不能从功能和技术角度考虑方案,整个会议过程都在务虚;
  • 大家只关注如何完成功能,不关心3W内容;
  • 一言堂,没有人积极参与。如何解决这些问题,那就是会议组织和管理的相关内容,可以自行学习。

除此之外,还有可能在讨论细节和思考开发时间时发现故事太大,无法在规定时间内完成。这个时候就需要进一步分解故事——将“更好”的用户故事,拆解为“正好”的用户故事。

—— end ——

全部内容链接:

用户故事地图(1):体验用户故事
用户故事地图(2):作用
用户故事地图(3):故事与卡片
用户故事地图(4):创建方法
用户故事地图(5):开发流程之“机会”阶段
用户故事地图(6):开发流程之“探索”阶段
用户故事地图(7):开发流程之“设计”阶段
用户故事地图(8):开发流程之“故事工作坊”阶段
用户故事地图(9):开发流程之“研发-评估-交付”阶段
用户故事地图(10):开发流程之“回顾”阶段
用户故事地图(11):故事(需求)拆分
用户故事地图(12):后记

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,835评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,598评论 1 295
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,569评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,159评论 0 213
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,533评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,710评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,923评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,674评论 0 203
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,421评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,622评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,115评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,428评论 2 254
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,114评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,097评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,875评论 0 197
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,753评论 2 276
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,649评论 2 271

推荐阅读更多精彩内容