读书笔记：《用户故事与敏捷方法》
《用户故事与敏捷方法》 Mike Cohn 著
用户故事：从客户角度出发描述功能。我作为（角色），相要（功能），以此（商业价值）；
* 独立的、可讨论的、有价值的（客户/用户，商业价值）、可估计的、小的、可测试的（故事描述中的细节和关注点，注释）
* 用户角色定义的是人，因此需要为用户考虑、整合和提炼角色，构建角色模型、行为规范，促成角色定义。因此使用角色定义用户故事（虚构人物，创建数据、操作流程、模拟系统操作、创建业务场影），以抽像到具像，完成用户故事的测试。同时考虑极端用户（个性鲜明、操作独特），以兼容不同的需要。
* 自动化完成验收测试，验收测试的是缺陷，不是覆盖率，有所测重。
用户期望内容，可以、最好以验收测试的的形式被记录下来，传递额外信息。-- 让客户参与进来
高效沟通：组织与客户的高效沟通，组织内部高效沟通；客户与用户在项目整个过程中全程参与。-- 听起来很不错，实际运行时尽量、努力实现吧
实现用户价值：客户、用户，商业价值
明确需求的过程：其实就是不断探寻的过程，不断重复，逐步澄清：需求的业务本身意义；用户需求的真实目的。拆解需求成为不同的故事，对于开发者来讲就是估算和做计划。
计划是展开项目相关活动所依赖的基础 -- 所有的评估最终都要划归到时间限：完成日期、发布日期
故事点是代表时间的模糊单位，表地故事的复杂度、工作量--（无量纲），速率表示单个时间（可能是单位时间或是一个迭代 ）可以完成的故事点数，故事点在同一项目中对比才有意义
成本是确认优先级时应当考虑的内容
评估速率时，只计划已经完成的故事，以确保评估的相对准确性，同时保证评估标准在整个过程的一致性：改变完成速率，而不是评估值
软件需求确实被识别为最常见的痛苦之源。
一目了然，格式一致的用户故事描述用户需求。
产出真正价值的软件，成果可以被审核、验证，交付使用。
如何在难以接触到用户的情况下与充当用户角色的人在一起工作？-- 尽可能与真正的用户工作在一起
不要在项目开始时就做一套包罗万象的决策。-- 项目的决定因素时刻都在有变化，一成不变的决策无法完全应对变化。
EPIC，史诗故事，很大的故事；史诗故事可以分解为多个更小的用户故事。复合故事，复杂故事
商业语言、技术语言。-- 对待不同的人要用对方可以听得懂的话来讲：行话；需求应当用所有利益相关者都能听得懂的语言进行描述。
迭代（iterator）-> 用户故事（user story） -> 故事点数（story point）-> 速率（veloicy，单位时间可以完成的故事点数）
通过优先级（可能是成本原因），对项目运行不断进行评估、调整，以适应新的变化。
保持故事的独立性，避免故事间依赖，分割故事，加入故事细节
故事卡：简单描述 + 必要提醒（验收、测试）；目的是促进对话，促进问题的澄清
如果故事不可估计，可能时因为：缺少领域知识，缺少技术知识，故事太大了
故事必须是可测试的，因此需要定义其验证/验收标准，需要尽可能早的发现问题（使用自动化可能是唯一的方法）
故事澄清过程中需要关注当前发布（时间线，速率，问题），最终目标是长远的终期发布
需求沟通的过程要注意技巧：尽可能减少封闭性问题、有明确指向的问题、有暗示性或导向性的问题；尽可能让问题脱了实际背景，由用户/客户自我意识到真正想要的
快速捕获故事，由草图 -> 模型 -> 规范化，由粗到细，逐步层级化；在开发中由用户故事形成一系列待办事项列表，同时不断求证
用户团队组成应多元化：不同的利益相关者对故事的描述、实现细节有着不同的理解，由于自身位置、利益、习惯的不同，因此对故事的理解会有较大差别
用户故事编写的目的是提醒开发人员和客户进行对话
自动化需要完成验收测试用例
三角测量：评估时，将当前故事与其他几个故事进行对比，确认故事点评估和速率的正确性
迭代：从粗到细，迭代完成结束后项目才完成；增量：针对项目中的某个功能，每次完成一个完整的功能，不断增加项目可实现的内容
避免过早的捕获当下故事还需要的细节，先从高层次、精粒度、抽像的了解和分析故事
不要过早的涉及用户界 -- 也许这就是为什么要强调单元测试的重要性，而将UI层验证放在最末端，一个问题：用户操作的是UI不是逻辑
将用户故事转化为故事点，以评估每个用户故事完成的时间，测试速率，评估进度，调整计划
控制节奏，确认发布时间，确认优先级，确认发布内容，交付价值
DSDM，故事优先级排列方法，称为MoSCoW莫斯科规则：must必须有，should应当有，could可以有，won't不会有
迭代数 = 故事点 / 速率
迭代计划会议：讨论故事，分解任务，确认承担者
Scenario场景 -> Use Case用例 -> User Story用户故事 -> Story Point故事点，由大到小
SCRUM是迭代和递增的过程。
以使用为中心的设计usage centered design，任务案例 task case
交付周期、迭代周期、速率
XP：沟通、简单、反馈、勇气，communication, simplicicy, feedback, courage
读书笔记：《用户故事与敏捷方法》相关推荐
- 读书笔记 | 墨菲定律
1. 有些事,你现在不做,永远也不会去做. 2. 能轻易实现的梦想都不叫梦想. 3.所有的事都会比你预计的时间长.(做事要有耐心,要经得起前期的枯燥.) 4. 当我们的才华还撑不起梦想时,更要耐下心来 ...
- 读书笔记 | 墨菲定律（一）
1. 有些事,你现在不做,永远也不会去做. 2. 能轻易实现的梦想都不叫梦想. 3.所有的事都会比你预计的时间长.(做事要有耐心,要经得起前期的枯燥.) 4. 当我们的才华还撑不起梦想时,更要耐下心来 ...
- 洛克菲勒的38封信pdf下载_《洛克菲勒写给孩子的38封信》读书笔记
<洛克菲勒写给孩子的38封信>读书笔记 洛克菲勒写给孩子的38封信 第1封信:起点不决定终点 人人生而平等,但这种平等是权利与法律意义上的平等,与经济和文化优势无关 第2封信:运气靠策划 ...
- 股神大家了解多少？深度剖析股神巴菲特
股神巴菲特是金融界里的传奇,大家是否都对股神巴菲特感兴趣呢?大家对股神了解多少?小编最近在QR社区发现了<阿尔法狗与巴菲特>,里面记载了许多股神巴菲特的人生经历,今天小编简单说一说关于股神 ...
- 2014巴菲特股东大会及巴菲特创业分享
沃伦·巴菲特,这位传奇人物.在美国,巴菲特被称为"先知".在中国,他更多的被喻为"股神",巴菲特在11岁时第一次购买股票以来,白手起家缔造了一个千亿规模的 ...
- 《成为沃伦·巴菲特》笔记与感想
本文首发于微信公众帐号: 一界码农(The_hard_the_luckier) 无需授权即可转载: 甚至无需保留以上版权声明-- 沃伦·巴菲特传记的纪录片 http://www.bilibili.co ...
- 读书笔记002：托尼.巴赞之快速阅读
读书笔记002:托尼.巴赞之快速阅读 托尼.巴赞是放射性思维与思维导图的提倡者.读完他的<快速阅读>之后,我们就可以可以快速提高阅读速度,保持并改善理解嗯嗯管理,通过增进了解眼睛和大脑功能 ...
- 读书笔记001：托尼.巴赞之开动大脑
读书笔记001:托尼.巴赞之开动大脑 托尼.巴赞是放射性思维与思维导图的提倡者.读完他的<开动大脑>之后,我们就可以对我们的大脑有更多的了解:大脑可以进行比我们预期多得多的工作:我们可以最 ...
- 读书笔记003：托尼.巴赞之思维导图
读书笔记003:托尼.巴赞之思维导图 托尼.巴赞的<思维导图>一书,详细的介绍了思维发展的新概念--放射性思维:如何利用思维导图实施你的放射性思维,实现你的创造性思维,从而给出一种深刻的智 ...
- 产品读书《滚雪球：巴菲特和他的财富人生》
作者简介 艾丽斯.施罗德,曾经担任世界知名投行摩根士丹利的董事总经理,因为撰写研究报告与巴菲特相识.业务上的往来使得施罗德有更多的机会与巴菲特亲密接触,她不仅是巴菲特别的忘年交,她也是第一个向巴菲特建 ...
最新文章
- C语言assert的用法
- 普通用户程序使用保留端口 error while loading shared libraries
- 成功解决Ubuntu下的make: gcc: Command not found Makefile:85: recipe for target 'obj/gemm.o' failed make: **
- python anaconda下载包_【Python开发】anaconda3 安装python包
- java判断字符串有中文_JAVA入门之正则表达式判断字符串包含中文
- JUnit3 结合一个除法的单元测试说明Assert.fail()的用法
- 覃超-算法训练营 学习方法分享[1] 如何精通一个领域
- 辗转相除法 求最大公约数和最小公倍数
- 改进你的代码-扩展了一下IEnumerableT
- java redis set list_RedisTemplate的各种操作（set、hash、list、string）_lichuangcsdn的博客-CSDN博客...
- 后端ajaxPost请求传给前端的显示乱码问题
- centos服务器 常用命令
- WPF DataGrid 导出Excel
- 22. PHP 日期和时间
- Matlab求解点到直线距离
- iTunes更改备份保存路径
- join left 大数据_left join 大数据
- 快速简单对接【短信验证码】API接口
- assign和weak的区别
- MPLAB 安装 mmc 报错需要安装web相关插件