使用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. 故事地图提供了一个需求的大图景,可以帮助我们通过看板对业务流程或价值链进行可视化。

2. 建立了大的故事和拆分后的子故事直接的对应关系。

3. 让我们对backlog的完成情况一目了然。

4. 可以帮助我们从一个整体的视角、用户价值的视角来进行优先级排列和发布规划。

用户故事地图包括两个纬度,横向是业务流,纵向是价值顺序。下图是一个示例:

在图-1中,橙色的卡片代表的是粗粒度的用户故事,可以理解为Epic-史诗故事,Jeff Patton称之为用户的活动(User Activity),这些用户的活动代表了产品的骨架,我们从左到右按照时间线来排列这些活动,排列好之后,系统的主要的业务流程就呈现出来了。需要注意的是,为了找出这些用户活动,第一步要做的是做角色建模,把用户角色先提炼出来。在每个史诗故事下面,我们可以拆分出更细粒度的用户故事。这些用户故事加在一起就构成了产品需要做的主要功能,并且已经按照系统骨架组织好了。

在图-1的横向的纬度,我们使用橙色的虚线把这些卡片横切成了3个泳道,每个泳道代表一个发布。所以,从这个故事地图上看,横向代表的是系统的骨架,脉络,纵向代表的是重要性,优先级,发布顺序。

我们需要根据用户的价值来思考在这个业务流程上,哪些是最核心、最重要的,我们可以按照提炼MVP(最小可行产品)的思路把核心场景找出来,放到前面的发布中,把低优先级的放到后面的发布中。这样做的目的是做价值驱动,让我们从用户的视角产品核心价值,并且持续地、增量地交付。

了解了故事地图地思路之后,我们看看如何使用leangoo工具来实现这样地一个故事地图。用户故事地图是2纬的,leangoo看板工具很容易实现,在看板中,我们有列表和泳道的概念,列表代表了纵向的纬度,泳道代表了横向的纬度。所以,在纵向的纬度,我们可以把每个Epic史诗故事作为一个列表,Epic下面的子故事做为列表中的卡片,在横向的纬度,我们通过泳道来代表每一个发布就可以了。Leangoo实现的故事地图示例如下图所示:

另外,在这个看板上我们还看到“发布1”这个泳道里面的卡片都加上了绿色的标签,我们可以使用这种方式来标示已经完成的故事。

通过leangoo看板,我们可以非常方便的通过故事地图把产品的需求全景图展示出来,产品的规划也一目了然,这对于我们持续地关注产品核心价值,更好地进行产品规划非常有帮助。

时间: 2024-08-07 12:31:44

使用Leangoo玩转故事地图的相关文章

怎么用leangoo做需求管理?(用户故事地图)

用户故事是在敏捷开发中表达需求的主要方式,我们在做敏捷开发的时候都有需求池的概念,在Scrum中这个需求池就是产品backlog,需求池里面是条目化的需求,每一条通常是一个用户故事.按照Scrum的定义,产品backlog是一个基于价值强制排序的队列,团队按照价值的高低,顺序地交付需求. 在开发的过程中,团队会逐步的细化产品backlog,为了保证短平快的交付,高优先级的用户故事会被分解为较小的粒度.但是这样带来了一个问题,对于那些规模稍大一些的产品来讲,故事的数量就会很多,故事拆分后通常会有只

用户故事地图对应到Epic及其缺点

??用户故事地图,提供了2维的角度来分析用户故事,直观,更加有利于优先级的表达. 在理解用户故事地图时,需要注意其作者的用词跟一般的用户故事不一致,因此要注意跟普通的用户故事用词之间的对应关系. 推荐一般理解如下: 一幅用户故事地图展现1个史诗Epic User Acitivites(Backbone)行,可以理解为对史诗Epic的一级功能分解 User Tasks(Walking Skeleton)行,可以理解为对史诗Epic的二级功能分解.这里千万注意,这与一般用户故事的任务完全不是一回事,

创建用户故事地图(User Story Mapping)的8个步骤

[小编]上周六了解了用户故事地图后,小编又查阅了一些资料,找到了以下这篇关于如何组织用户故事地图规划的文章,分享给大家.也希望大家如果有好的实践,也可以留言一起交流. 原文地址:http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html 感谢Jeff Patton和其他人的大力推广,用户故事地图已经成为敏捷需求规划中的一个流行方法.用户故事地图可以将你的backlog变成一张二维地图,而不是传统的简单列

用户故事地图(User Story Mapping)之初体验

北京这几日的天儿真是好的出奇,白天风和日丽,晚上繁星漫天:在这样一个周六的下午,小编参加了一次北京敏捷社区(微信号:Agile1001)组织的活动:<用户故事地图User Story Mapping 实战工坊>,虽然对用户故事地图是第一次接触,但也有一些小小的体会,回到家中是在按捺不住想写下来分享给大家. 今天的活动由<百度方法+>发起人,软件工程团队负责人李涛引领大家进行实战体验,他也是<用户故事地图>这本书中文版的译者. <用户故事地图>这本书的原作者 

每周一书《用户故事地图》分享!设计、产品、开发必读!

内容简介用户故事地图作为一种有效的需求工具,越来越广泛地应用于开发实践中.本书以用户故事地图为主题,强调以合作沟通的方式来全面理解用户需求,涉及的主题包括怎么以故事地图的方式来讲用户需求,如何分解和优化需求,如果通过团队协同工作的方式来积极吸取经验教训,从中洞察用户的需求,开发真正有价值的.小而美的产品和服务.本书适合产品经理.用户体验设计师.产品负责人.业务分析师.IT项目经理.敏捷教练和精益教练阅读和参考,也更适合用作企业培训手册,打造高效能的团队协作能力. 作者介绍Jeff Patton在

21天敏捷打卡-用户故事地图

上图是基于敏捷故事的一个看板或者说敏捷流程中的一种,没有什么比亲身投入的效果更好.用户.组员需求方通过自身的投入.表达以便于让团队成员更加了解其想法和统一组员的想法.用户故事是一种思维,通即故事思维,运用故事的元素进行思考和设计,解决问题.达到某种效果.用户故事设计中核心是通过故事传递信息,引起共鸣,决绝问题. 讲故事不是一个简单工作,需要优秀的组织能力,清晰的表达方式,达到听众清晰明了我们想表达的.这里笔者建议,如果平时和人交流的时间太少,可以通过书写博客等方式,组织自己的中心思想,让听众知道

Android玩转百度地图Sha1获取正确姿势?

场景一 由于近期项目钟要用到定位功能因此肯定须要用到地图以及地位功能,相信大家也知道眼下国内比較出名的地图像百度.高德.腾讯等这些还是用到比較多的.于是思考了一下决定还是用百度,相信老司机们都知道的哈! 第一步到百度开发人员平台注冊一个账号通常是手机号或者短信动态验证码登录我注冊了所以这里不再赘述 第二步就是创建一个应用程序这个名字通常是任意取的这个不用太在意例如以下图所看到的 watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMTU5NTAzMj

用leangoo怎么做需求管理及规划?(产品Backlog、用户故事)

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

3.PO如何给开发团队讲好故事

敏捷开发系列文章目录 讲出符合开发团队味口的故事. 上一章说了敏捷开发团队的构成与迭代过程,本章重点说一下迭代第一天的计划会议.熟话说“好的开始就成功了一半”,一个迭代的计划会议做得好不好确实直接注定着迭代的成功与失败.迭代开始之前,PO肯定都已经提前准备好了本次迭代的所有故事,并且提前都发给了团队熟悉,后来我们一般都会在前一个迭代快要完成的时候开一个下个迭代的熟悉会议,组织大家一起熟悉下个迭代的故事,一开始并没有这么做,是在过去的多个迭代中,发现每个迭代计划会议都会拖得很长,有时候会开整整一天