使用Leangoo玩转故事地图
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了使用Leangoo玩转故事地图相关的知识,希望对你有一定的参考价值。
用户故事是在敏捷开发中表达需求的主要方式,我们在做敏捷开发的时候都有需求池的概念,在Scrum中这个需求池就是产品Backlog,需求池里面是条目化的需求,每一条通常是一个用户故事。按照Scrum的定义,产品backlog是一个基于价值强制排序的队列,团队按照价值的高低,顺序地交付需求。
在开发的过程中,团队会逐步的细化产品backlog,为了保证短平快的交付,高优先级的用户故事会被分解为较小的粒度。但是这样带来了一个问题,对于那些规模稍大一些的产品来讲,故事的数量就会很多,故事拆分后通常会有只见树木不见森林的感觉。用户故事地图是Jeff Patton发明的一种组织和管理用户故事的方法,可以很好的解决这个问题。 Jeff Patton还写了一本书《用户故事地图》来帮助我们更好地学习故事地图,这本书地中译本(百度李涛翻译)今年三月份会在国内上市。
本文将介绍如何使用leangoo看板来实现故事地图,以帮助我们更好的进行需求的管理和可视化。
在介绍故事地图之前,我们先回顾一下用户故事的基本概念。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:
1. 角色:谁要使用这个功能。
2. 活动:需要完成什么样的功能。
3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达:
英文:
As a <Role>, I want to <Activity>, so that <Business Value>.
中文:
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例:
作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。
用户故事地图是一种对用户故事进行组织和优先级排序的方法。用户故事地图可以带来如下的一些好处:
用户故事地图包括两个纬度,横向是业务流,纵向是价值顺序。下图是一个示例:
在图-1中,橙色的卡片代表的是粗粒度的用户故事,可以理解为Epic-史诗故事,Jeff Patton称之为用户的活动(User Activity),这些用户的活动代表了产品的骨架,我们从左到右按照时间线来排列这些活动,排列好之后,系统的主要的业务流程就呈现出来了。需要注意的是,为了找出这些用户活动,第一步要做的是做角色建模,把用户角色先提炼出来。在每个史诗故事下面,我们可以拆分出更细粒度的用户故事。这些用户故事加在一起就构成了产品需要做的主要功能,并且已经按照系统骨架组织好了。
在图-1的横向的纬度,我们使用橙色的虚线把这些卡片横切成了3个泳道,每个泳道代表一个发布。所以,从这个故事地图上看,横向代表的是系统的骨架,脉络,纵向代表的是重要性,优先级,发布顺序。
我们需要根据用户的价值来思考在这个业务流程上,哪些是最核心、最重要的,我们可以按照提炼MVP(最小可行产品)的思路把核心场景找出来,放到前面的发布中,把低优先级的放到后面的发布中。这样做的目的是做价值驱动,让我们从用户的视角产品核心价值,并且持续地、增量地交付。
了解了故事地图地思路之后,我们看看如何使用leangoo工具来实现这样地一个故事地图。用户故事地图是2纬的,leangoo看板工具很容易实现,在看板中,我们有列表和泳道的概念,列表代表了纵向的纬度,泳道代表了横向的纬度。所以,在纵向的纬度,我们可以把每个Epic史诗故事作为一个列表,Epic下面的子故事做为列表中的卡片,在横向的纬度,我们通过泳道来代表每一个发布就可以了。Leangoo实现的故事地图示例如下图所示:
另外,在这个看板上我们还看到“发布1”这个泳道里面的卡片都加上了绿色的标签,我们可以使用这种方式来标示已经完成的故事。
通过leangoo看板,我们可以非常方便的通过故事地图把产品的需求全景图展示出来,产品的规划也一目了然,这对于我们持续地关注产品核心价值,更好地进行产品规划非常有帮助。
以上是关于使用Leangoo玩转故事地图的主要内容,如果未能解决你的问题,请参考以下文章