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

上图是基于敏捷故事的一个看板或者说敏捷流程中的一种,没有什么比亲身投入的效果更好。用户、组员需求方通过自身的投入、表达以便于让团队成员更加了解其想法和统一组员的想法。用户故事是一种思维,通即故事思维,运用故事的元素进行思考和设计,解决问题、达到某种效果。用户故事设计中核心是通过故事传递信息,引起共鸣,决绝问题。

讲故事不是一个简单工作,需要优秀的组织能力,清晰的表达方式,达到听众清晰明了我们想表达的。这里笔者建议,如果平时和人交流的时间太少,可以通过书写博客等方式,组织自己的中心思想,让听众知道我们要表达什么。

产品在设计中,容易偏向几个极端:1.领域专家;2.用户、需求方,3.偏向研发方。偏向领域专家那么产品的使用门槛太高,无法普及,偏向需求、用户产品过于算乱,没有聚焦性(用户有可能不知道自己到底想要什么);偏向研发方产品可能会出现水土不服。

这时,就需要一群人:客户、专家、用户、研发等在一起,定义和提问,产品要面对的场景是什么?通过产品可以解决那些问题?产品能给公司带来的回报率有多高?为用户带来什么价值?产品的开发,用户的需求会很多、很多,像是一个庞大的地图,而”用户故事“擅长聚焦构建晓得特性,专注小的细节,通过上节课的例子就可以看出,不同的公户故事块容易出现不相匹配的产品部分,所用,有一种新的方法”用户故事地图“出现了;

通过地图可以解决以下问题:

  1. 让我们更容易看清pro backlog的全貌;
  2. 为新功能筛选和规划优先级提供了更好的工具,帮助我们决策那些backlog放入TODO;
  3. 便于使用头脑风暴和其他协作的方式产生用户故事,即如何在故事作坊中更有效的产出;
  4. 帮助我们更好的进行增量式的迭代开发,还记不记得,上节课中”必须有、应该有、可能有、不会有“这几个概念?
  5. 为传统的项目计划提供了一个更好的替代工具,从被动到主动参与的转变;
  6. 允许我们从不同的维度进行项目规划,并确保不遗漏每个不同的想法,避免独裁式。

如何创建故事?

1.前期准备:

召集几名产品核心人员,最好是奇数,方便做决定。从用户、产品经理、业务分析师、架构师等组成,因为每个头衔都代表了项目项目中主要角色的看法,所以创建的故事地图后,来以后的全体计划中可以避免许多不必要的辩论。准备白班、电子手写板、各种贴纸、胶带、咖啡、烟、打火机和一个相对独立的办公室。

2.整理创意框架

定义和提问,产品要面对的场景是什么?通过产品可以解决那些问题?产品能给公司带来的回报率有多高?为用户带来什么价值?

统一答案,把明确的目标写在便利贴上,按照优先级排好顺序。*这一步很重要,一定要让每个人都回答;笔者经历过,调研一款产品时,所谓的需求方(公司内部人员),专家给的答复是不知道,你自己想办法搞定。产品上线后,马后炮的人们就来了,集团会之中这些”专家“的建议就来了.....相当的苦恼,还好几个大客户比较认可,总算啪啪啪打了某些人的脸,出口恶气。

3.刻画用户画像

参照之前写的文章,不过多介绍;

4.从最重要的用户入手,编写大故事,注意不是史诗类型的。

5.深挖、深挖细节:从用户画像的角度入手,例之前的”叶海龙“厂长,他系统中,基于某个流程,他会最什么?是否还有其他的选择?符不符合他的使用习惯?问题出现时,他希望、他会如何处理?

6.划分MVP发布计划:为什么要划分MVP?思考一下。

原文地址:https://www.cnblogs.com/atun/p/12088658.html

时间: 2024-10-20 12:39:29

21天敏捷打卡-用户故事地图的相关文章

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

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

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

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

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

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

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

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

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

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

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

在远古时代,文字没有出现之前.知识的传承靠口口相传,不管隔了多少代,其准确性很高.文字出现后,我们大脑中的这种技能反而逐步衰退.于是各种软件.各种方法充斥着我们,左右着我们.各位是否也有相同的想法?试想一下,上节课我们讲了什么?每次应允别人的承诺,我们转过头就忘记?比如忘记约会,忘记洗车.忘记写日报? “要想知道栗子的味道,你得咬一口”这个真理朴实,正确.当用户提出一款软件时,我们不要只想着从技术的角度,认为用户不专业,他的需求是错误的.如果他专业,就没我们啥事了.用户大脑中的需求是离散的,不可

21天敏捷打卡-敏捷估计与规划

通过之前的章节,我们可以清楚的知道,估算交付时间.交付成本.可获得利润,对项目是否可以落地有重要的影响. 敏捷估算的基础: 为什么要估算:估算可以让团队了解项目规格计算ROI和IRR,形成可执行许可的基础,有了估算,市场也可以提前的为后期产品上市做准备: 谁执行估算?:产品负责人.敏捷教练: 会议什么时候进行?自然是越快越好,在整个项目进行之间,同样随着逐步完善更多的信息,估算也要持续进行.敏捷提倡:拥抱改变,那既然拥抱改变,估算也要做调整,该加人手就要加人手.不要一味指望加班来压缩成本,随着9

21天敏捷打卡-看板

看板在我们生活中随处可见,”课程表.餐厅的餐牌.加油站的今日油价等等“,其作用便于所有人了解点前的状态,例如通过课程表,可以让我们知道接下来课程的安排,做出有计划的复习.和课前准备. 在制造业中看板运用的价值更为突出,通过生产看板,可以及时了解到当前的生产状况.物料信息.品质信息,便于整个车间\小组都能理解当前的生产状态,并以一种自发的.有动力的相互协作的方式完成今日的目标.上图是一个我在开发中常用到的看板,通过”待处理.开发中.评审中.集成测试中等“几个状态,组员可以清晰的知道当前的工作进度,

21天敏捷打卡--敏捷方法实现

常用的敏捷实践包含:精益.看板.Scrum.XP极限编程.水晶.DSDM动态系统开发.FDD功能驱动开发.AUP敏捷统一过程.OpenUP. <敏捷实践指南>将敏捷方法和看板方法是为精益方法的子集.因为他们都符合精益思想的具体实例,都反映了“关注价值”.“小批量”.“消除浪费”. 精益软件开发LSD TPS 面对场景 解说 原则 解说 过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费 违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小