读书笔记:《用户故事地图》
Posted Rolei_zl
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了读书笔记:《用户故事地图》相关的知识,希望对你有一定的参考价值。
《用户故事地图 . User Story Mapping》 Jeff Patton 著
如果读过问题分析的金字塔原则,有过架构设计的,可以快速的浏览和理解该书所提供的用户故事分析方法。
从文化、工作方式、思维方式的差异来看,敏捷方法必然有一个本地化的过程。
软件开发的目的:开发可以工作的软件,解决用户问题,实现客户和软件价值。
敏捷的目的是将不确定的内容确定化,降低变更的风险。以一种透明的方式让大家看到业务整体流程、明确当前在忙什么,时间、钱用在了什么地方。
敏捷实现的前提:用户的参与 -- 紧密协作,密切沟通
用户故事,区分大小 和 优先级,层层分解生成用户故事点,目的是达成共识。好的用户故事地图可以有效支持沟通。-- 目的:需求信息传递清晰、准确、无二异性
用户故事地图:一种处理用户故事的方法 -- 个人理解:可见、具像;可视化的、形式化的用户故事展现方式,关注用户故事的全局上、整体框架而非某个用户故事细节
敏捷行动,而向价值,只做对当前业务价值最大化的内容:对用户有用的功能(可以改变用户工作现状),可以给客户和开发者带来价值
敏捷开发和用户故事的初衷:学习。通过迭代不断的完善需求、过程 和 交付物。
质量的体现:代码质量、功能实现、用户体验
所有开发都面向:交付、价值、解决问题、客户需要 -- 持续为业务贡献价值,如何沟通、协作并最终交付好的产品,解决用户问题、体现方案价值
测试:用批判的眼光看待要完成的需求、要求。尽可能早的指出可能有问题的地方。
协同效率、达成共识
最小可行产品集 -- 产品核心功能,最小发布方案
切分后的需求称为“故事”,Story,故事的使用使得软件开发项目的过程进一步可视化。把故事分解成可计划可开发的粒度,可以进行评估和把控进度。
故事地图是一门在需求拆分过程中保持全景图的技术。全景地图可以帮助团队和用户有效的沟通,专注于用户和用户体验。-- 解决客户和用户问题
充分协调好产品设计和软件开发。观察用户的痛点和分析用户使用过程中产生的数据
一致的理解是无形的,无法看出来,共享文档并不代表达成共识(同一份文档,不同的人阅读,得到的信息不一致)。重要的是当我们看到、读到文档时能够想起什么。
用户故事使用文字和图片相结的方式辅助讨论,确认解决方案。确认干系人愿景。
聚焦问题全景的前提下描述用户故事。用户故事地图,就是在讲大故事的同时进行拆分,最终对产品取得共识。
想要开发的功能,总比能负担的时间和金钱多得多。想做的功能,总远远超出你来得及做的。开发不是完成所有功能,而是尽可能少的功能。-- 但要解决用户痛点、问题
聚焦于故事的整体,不要过早陷入细节。-- 活动、步骤、实现细节
从左到右:故事步骤;从上到下:故事细化 (尽可能发现细节中隐藏的问题)-- 识别用户故事 顺序 和 依赖,优先级
为谁服务、达成什么目标是什么,如何达成目标。who、what、why,谁 / 要完成什么功能 / 为什么需要这样的功能。作为<角色>,我想要<功能>,使得<价值>
所有的需求均无法做到一次性取悦于所有人。真正理解用户需求才能进行靠谱的估算。
估算本身就是一种猜测。对开发时间进行记录,称之为度量。
度量越频繁,估算就会越接近于实际值。通过把大的计划切分成小的部分,可以从中获得更多度量的机会。最终达到共识。
功能燃尽图 + 风险燃尽图
迭代意味关重复同样的流程,意味着评估和改变。
3C原则:card 软件特性描述,conversation 沟通和讨论,confirmation 完工条件确认(验收标准)
用户需求描述是什么 + 用户为什么会有这样的需求
用户故事卡:编号、优先级、标题、描述、关联故事、实现状态、提出人、提出时间、规模/大小、度量/验证标准
经常反思产品质量、工作计划和工作方式。保持项目进度和完成质量持续可见。
将大的、模糊的概念转变成小的、具体的、可开发的方案。
大多数原创性解决方案通常出自可以真正洞察业务问题和用户问题的工程师。
机会,可以用来解决问题的所有想法,感受用户,不断的发现用户痛点和可能的操作假设,发现需求遗漏点。-- 之后不断细化,去伪存真。
有效性:可实施性、可行性、紧迫性。
探索过程是学习和了解用户需求和操作习惯,确认业务主要流程和异常分支流程。找到简单、可行的、真正解决用户问题的、更完善的解决方案。
优先级:特定用户、目标、操作 -> 特性和功能
工作坊:核心业务人员组成的需求探索和确认的小团队,让问题得到全面考量,然后将结果宣讲给团队全员并得到对需求理解的共识。
收集、分析、描述(需求、方案、验收标准)
对故事循序渐进进行分解,而不是一次性完成。
软件从来都不会被真正完成。用户想得到的不是软件本身,而是软件投入后可以得到的改变和结果。
O‘Reilly出版的图书中,封面图片上显示的多为濒危物种,它们对全世界很重要。
学习型组织,敏捷过程是一个学习的过程(这似乎与欧美人的工作方式有关,习惯于回顾、总结、改进),因此敏捷更需要建立学习型组织。
什么时学习型组织:是让组织中的每个人学习、进步?似乎并不是,学习型组织应当是组织的学习、改进能力,组织在学习的过程中不断提升对外服务的能力,同时体现在组织中个体能力的提升。
以上是关于读书笔记:《用户故事地图》的主要内容,如果未能解决你的问题,请参考以下文章