分割User Story
分割User Story

分割User Story

今天Craig Larman给大家讲了堂“User Story Splitting”主题的课,从什么是user story,与use case的区别,user story通常的描述形式,分割user story的常用方法等,直到使用公司内真实的案例来模拟splitting的过程。有收获,有证实,也有思维的触动。

其中有举到一个例子,比如用户需要DHCP的服务,那么可以分为fake的stub的DHCP功能,然后还有real internal的,还有real external的等等。但是,真正地管理这些child user story的时候,需要额外的小心,因为它们之间其实是有依赖关系的。不可能先去实现real internal的部分,然后再实现fake、stub的,一是浪费资源,二是可能也无法一次完成real internal,可能正是因为这样才会拆分成两个child user story。也不可能两个或多个团队同时分别实现某个child user story,彼此之间的依赖关系会给产品开发的管理工作带来麻烦。

另一个问题,这次workshop关于如何split user story讲得确实非常清楚,但是其并没有也不会覆盖到做出split选择的部分,也即,我们是否需要split,为什么需要,应该在split过程中使用怎样的策略和方法。split是否有价值,这是必须要思考的问题,我们不能为了split而去split。其中有一个例子,讲述用户需要upload以及download的功能,而download又可以划分为download as file或者as xxx structure方式,这可以作为两个child user story。但是,是否真的需要这样的划分,这样的划分是否真的有其现实意义呢?虽然从用户角度,下载到文件或是某种数据结构,确实是两个不同的child user story,但是从开发的角度看,或许开发的最大开销在于download过程中客户端和服务器段的沟通,或者是设计download算法的部分,而以文件方式或数据结构方式保存反而是非常琐碎简单的任务。那么这样的情况下,你应该如何估计这两个user story的大小呢?如果说download本身是5个故事点,而保存的方式各为1个故事点,你会赋予文件方式6个故事点而数据结构6个,或者是文件1数据结构6,或者是各3.5个故事点,或是其他任何的方式?不论用何种方式,它都给实际的开发工作带来一些依赖关系的管理上的开销。那么,此时,也许反省我们分割user story的方法,或是分割user story的出发点会带来一些启发。

其中产生的另外一个重要思考是,在我们分析用户需求、分割user story的过程中,是否会出现信息失真,太过专注于产品的某些特性,而忽视甚至是根本就不知道用户的需求?比如说user story的描述是“作为<用户方某个角色>,我想要<某个功能,或工具、软件>,因为<原因或收益预期>”,然后我们可以通过介绍的那些方法将其分割成为若干个child user story,然后在实现各个child user story的过程中,我们会侧重于验证其功能,比如说这个功能需要能够创建某些资源、修改、删除等等,但是,在什么时候什么地方我们验证了这个功能是否能够满足用户要此功能的原因或收益预期的出发点呢?

  • 举例来说,用户需要一个工具能够舒服地,随时随地的可以供他记录下自己的思想片段。
  • 在公司的需求分析阶段,认为,一支“笔”应该是能够用来满足客户需求的。通过围绕笔的user story分析,并分割为若干的child user story,可能会在开发过程中,分别开发其书写、擦除、携带等各方面的功能。
  • 而团队在接手任务时,有可能已经丢失掉child user story最重要的成因,团队从自身出发决心要做出最好的“笔”,于是从设计和实现、验证等角度努力提高笔的质量等各方面品质。
  • 最后,我们得到了一支,重200克,使用高质量的墨水,外观精致,用钢琴烤漆制作的笔。

但是,符合用户的需求么?也许用户无非就是需要一支手的握感舒适、轻巧易携带、带有橡皮的铅笔而已。

要管理这些容易被遗漏的需求,以及child user story夹缝中的功能碎片,需要产品负责人或者项目的管理人员来协助做到。我们在现实中遇到的问题就包括,比如将数据包转发的功能按照数据类型分为CS(电路交换)和PS(数据交换)两种,但是偏偏就漏掉了CS和PS混合在一起的测试用例,以及在一种流量尚有部分资源剩余的情况下产生另一种流量的测试用例,导致我们在后期收到上层应用层测试的错误报告。团队对此一般是无能为力的,如果拿到手的product backlog item无需团队进行更多分析的话,情况会更加严重,就会完全仰仗分割user story到product backlog item的人的能力和细致程度,这恐怕是成熟的软件开发所无法接受的吧。

6条评论

Yi 发表评论 取消回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据