经过前面10章内容的描述,我们了解故事、故事卡片,以用户故事推动的项目开发流程。实际开发中,团队往往会先得到巨大的故事(需求)。从产品角度,拆分意味着放弃部分功能,这种放弃引起的损失,会带来更痛苦的感受,难以抉择。从开发角度,拆分是建立在功能低耦合前提下,而这一点,又是基于程序早期合理的架构。但现实却是,研发过程中为了进度而采用速效方法(不会做太多长远考虑,这也是技术债产生的原因),长期的合理性变得不那么重要。基于以上种种,拆分过程就变得十分痛苦和坚辛。
然而,为了及时评估产品和进度,同时满足资源与时间限制、降低成本和实现商业目标的要求,故事拆分都是不二之选。
一、由谁来拆
最近在网上常常见看到嘲讽甲方的段子,怎么会有那么多乙方公司?后来仔细一看,发现很多发段子的“乙方”,和他们嘲讽的甲方都在同一家公司。而这其实就是工作中常会出现的“甲方-乙方反模式”。
甲方-乙方反模式
这一反模式的表现是,团队成员之间是”食客-服务员关系“,即我想要什么,你就要给什么。具体为甲方清楚自己想要什么,并表达给乙方,乙方则倾听理解,并找到解决问题的技术方法。然而,乙方承诺的排期会受各种原因的影响,若不能按时完成,乙方可以找各种理由为延期辩解。而甲方最终拿到功能后,也有可能发现不是自己想要的。最终,围绕解决问题的对话,变成了围绕需求的扯皮,最坏的情况是没有人成为赢家。在这场对话中,真正的核心其实是甲方需要清楚自己遇到的问题,而不是预测什么方法最合适。很显然,这种问题的一方面原因是故事(需求)的解决方案是由单一方决策。那么由多方共同决策是否就可以解决这一问题呢?
一人决策与多人决策方式
在大多数场景下,需求都是由单一方来负责并决策的。而团队成员常常表现为“你来决定,告诉我就好了”、“你要达到的效果是什么?”,对于单一方决策而言,这一场景实在太爽——指挥千军万马,指哪儿打哪儿的快感油然而生。等等,这里是不是存在什么问题?指挥固然爽,然而一旦出问题,那么团队成员也会说“这个是你定的”、“我只是照着你说的做而已”。正所谓成也萧何,败也萧何。让我们来分析一下:
- 用户故事由模糊到具体的过程中,需要展开多次对话,一个人是无法完成的;
- 在流程中的各个环节由各人负责,那么各人也将成为卡住流程的瓶颈;
- 一个人的知识、视野和专业范围是有限的。
既然单一方决策会成为瓶颈,那么多方决策是否会更好?也不尽然,一方面,当资源有限时,参与决策者会倾向于妥协,每个人都无法达成目的;另一方面,当资源无限时,大家倾向于做所有的事情。想想我们开会的时候,没有一个人做最终决策的情况。
探索团队
《用户故事地图》提供了另外一种决策方式——由跨部门、小型团队协作的方式进行,如题,它就是称之为“探索团队”的决策组织。在这个组织中,共有2〜4个人,包括产品负责人、用户体验设计师(设计师)、资深技术人员,所有参与人员必须具有一流的沟通和协作能力。
这个团队应该由一个对业务愿景、战略以及产品服务的市场有深度理解的产品负责人主导。这个核心团队应该有这样的人,他理解用户,可以自如地和用户合作,力求了解他们的工作方式,并且可以开发简单的UI原型。这个团队也应该包括一个来自开发团队的资深工程师。这个人需要理解系统目前的架构,知道哪些新的技术方案可以用来解决目前的难题。
探索团队应从探索阶段就开始介入,终止于“故事工作坊”以完成最后一次讨论。在故事工作坊中,除了探索团队成员之外,还要纳入测试人员等,共同定义最佳的开发和测试用时。探索团队通过用户故事的一系列方式,抽丝剥茧般梳理和评定用户故事,将故事拆分为大小合适的模块。这些模块,将最终流入开发流程中。
二、故事(需求)拆分
探索团队负责拆分故事,比较合适的模块大小是“每个模块开发与测试时间共计1〜3天”。如何做到呢?《用户故事地图》并没有提供具体的执行方法,但有一些思路值得借鉴。打个比方,如果把软件比做大蛋糕,那么切分的结果应该是怎样的?应该是很多纸杯蛋糕(一定有人想到刀子把蛋糕切成一块一块)。每一个纸杯蛋糕可以独立交付,食谱也都类似,都是一点糖、一点面粉、一两个鸡蛋什么的。
那些需要被拆分的故事被称之为“史诗故事”,我们会从三个角度来对它们进行切分:
- 用户角度:可以满足某一需要;
- 开发角度:只需要几天时间就可以完成开发和测试;
- 业务角度:有助于实现业务目标;
此外,还需结合在《用户故事地图(9):开发流程之“研发-评估-交付”阶段》中讲到的研发的三个阶段。对故事(需求)进行拆分,它有些像碎石的过程,无论是怎样的石头,碎石的结果是得到一堆同样的小石头——这明显是一个技术活儿。
三、故事(需求)聚合
有时候,我们的需求池中会充拆大量的小需求,它们细碎而不值得大动干戈,但堆积太多又不知如何处理。此时,我们需要拿起另外一把工具,就是“聚合”——可以将那些细碎的小故事聚合为“主题”。
“主题”用以归类故事——收集需要下个版本发布、同一功能的不同版块、以某种其他方式关联的一堆故事。内容不多时候,我会直接根据需要将一堆小故事聚合在一个卡片中。当然,当这种故事很多时候,也可以采用以下方法:
- 有便签写下所有需求;
- 邀请理解系统的项目成员;
- 寻找一面墙;
- 给每个人分一些故事卡片;
- 大家凭土目水之,把相似的卡片放在一起;
- 过程中,大家安静的做,不要交流;
- 最后沟通不同分类观点的卡片;
- 每每一组一个相对具体的大标题,凝练故事;
以上方式是《用户故事地图》中介绍的方法,看来就是用研中“卡片分类法”的方式。
——end——
全部内容链接:
用户故事地图(1):体验用户故事
用户故事地图(2):作用
用户故事地图(3):故事与卡片
用户故事地图(4):创建方法
用户故事地图(5):开发流程之“机会”阶段
用户故事地图(6):开发流程之“探索”阶段
用户故事地图(7):开发流程之“设计”阶段
用户故事地图(8):开发流程之“故事工作坊”阶段
用户故事地图(9):开发流程之“研发-评估-交付”阶段
用户故事地图(10):开发流程之“回顾”阶段
用户故事地图(11):故事(需求)拆分
用户故事地图(12):后记