《用户故事与敏捷方法》 笔记

最近想学习下项目管理方面的方法论，找PMO借了一本书《用户故事与敏捷方法》 。两天看完，觉得有些内容还是挺有用的，虽然参与敏捷开发模式有两年多时间，实操和业务流程都会，但再回过头看一些理论，会有一些新的启发。特地做了一下笔记。

2019-8-21

第1章 概览

一个需求可被认为是故事（Story），如果一个故事很大，可称之为史诗故事（Epic）

Epic>Story>Task

 

第2章 编写故事

在这一章中,我们将关注故事编写。 为了构造好的故事,我们关注六个特征。一个优秀的故事应该具备以下特点:

独立的(Independent)

可讨论的(Negotiable)

对用户或客户有价值的(Valuable to Purchasers or Users)

可估计的(Estimatable)

小的(Small)

可测试的(Testable)

《探索极限编程》和《重构工作手册》的作者BillWake,建议用英文缩写 INVEST来代表这六个特征(Wake 2003a).

 

可估计的(Estimatable)：如果故事无法估计会因为开发人员不张我所涉及的技术，可让一个or多个开发区进行极限编程（XP）中所谓的探针实验（spike），探针实验限制一个最大时间量（时间箱，timebox）。

一个不可估的故事变成2个：

1、一个快速的探针故事；

2、一个故事（真正实现功能）

备注这两个尽量放在不同的迭代中

 

小的(Small)：分割故事：史诗故事通常分为：

复合故事（compound story）：由多个小的故事组成的史诗故事

复杂故事（complex story）：其本身很大且不容易分解的故事

 

故事太小可合并故事

 

第3章 用户角色建模

用户角色 角色建模的步骤：

1、头脑风暴，列出初始的用户角色集合；

2、整理最初的角色集合；

3、整合角色；

4、提炼角色

两个额外的技术：

1、虚构人物（最常用的用户）；

2、极端人物（最少用的用户），但投入大量时间不值得

 

第4章 搜集故事

引出和捕捉是不合用的

方法：

1、用户访谈；开放式问题和背景无关问题

2、问卷调查；不建议捕捞故事使用

3、观察；

4、故事编写工作坊

 

第5章 与用户代理合作

用户的经理、开发经理、销售人员、领域专家、市场营销团队、以前的用户、客户、培训师和技术支持、业务分析师或系统分析师、设立客户团队

 

第6章 用户故事验收测试

在写代码之前写测试

客户定义测试

测试是过程的一部分。而不是编码完成后要做的事

测试类型：故事测试主要是功能性测试

1、用户交互测试；

2、可用性测试；

3、性能测试；

4、压力测试

 

第7章 优秀用户故事准则

从目标故事开始

切蛋糕（将大故事分解成小故事）

编写封闭的故事

卡片约束（必须要遵守而不需要直接实现）

根据实现时间来确定故事规模

不要过早涉及用户界面？

有些需求并不是故事

在故事中包含用户角色

只为一个用户编写

以主动语态编写

由客户编写

向故事卡编号说“不”

不要忘记意图

 

第8章 估算用户故事

故事点（story point），NUT（Nebulous Units of Time），一个故事点的工作量作为一个理想日的工作。

小结

用故事点估算故事,故事点是故事复杂度、工作量或工期的相对估算。

应由团队估算故事,估算属于团队而不是个人。

通过和其他估算进行比较来进行三角测量。

团队是否使用结对编程对故事点估算没有影响。结对编程影响的是团队的速率,

不是他们的估算。

 

第9章 发布计划

什么时候发布？发布哪些功能？

排列故事优先级（成本改变优先级，如一个次重要功能需要开发时间较长，则可降低优先级）

混合优先级。如果在确定一个故事的优先级时遇到问题，可能要分割故事

高风险故事

根据架构需要安排优先级

选择迭代长度。迭代长度一般1至4周，如果不确定则尽量选择短迭代，因为长迭代更容易犯错

从故事点到预计工期。初始速率：1、使用历史值；2、执行一轮初始迭代，使用那轮迭代的速率；3、猜测。

创建发布计划

 

第10章 迭代计划

迭代计划概览

迭代计划会议一般内容：

1、讨论故事；

2、从故事中分解出任务；

3、开发人员承担每个任务的职责；（一旦确定故事的所有任务，需要所有团队成员自愿执行任务，认领。迭代期间可以调整）

4、讨论过所有故事，并接受所有任务后，开发人员单独估计他们承担的任务。

估算并确认

 

第11章 测量并监控速率

测量速率

计划速率和实际速率

迭代燃尽图（每日燃尽图反映的是剩余工作量，而不是在一个故事或任务上所花费的工作量）

小结

计算速率时只考虑那些已完成的故事,即通过验收测试的故事。 不要计算迭代中团队未全部完成的故事。

为每轮迭代计划和实际完成的故事点数画图是监测实际和计划速率区别的好方法。

不要在一两轮迭代后就忙着预测速率趋势。

完成一个任务或故事所花费的实际小时数对速率没有影响。

在大家都能看到的公共区域贴一些大而可见的图。

累计故事点图很有用,因为我们可以从中看出每轮迭代中完成的故事点。

迭代燃尽图展示了用完成的故事点表示的进度和剩余故事的改变。

每日燃尽图在迭代中十分有用,它展示了迭代中每天剩余的小时数。

设计及检测一个平均每个故事点出现的缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。

 

第12章 故事不是什么

故事区别于其他三种常见的需求方法：用例（use case）、IEEE830软件需求规格、交互设计场景

用户故事和应用里场景类似，但用例往往比单个故事要大

 

第13章 用户故事的优势

有那么多各种各样的处理需求的方法,为什么我们要选择用户故事?本章我们会看看与其他方式方法相比，使用用户故事到底能带来哪些好处.

用户故事强调口头沟通。

人人都可以理解用户故事。

用户故事的大小适合做计划。

用户故事适合于迭代开发。

用户故事鼓励延迟细节。

用户故事支持随机应变的开发。

用户故事鼓励参与性设计。

用户故事传播隐性知识。

 

讨论完用户故事的种种好处之后,本章结束时会给出用户故事几个潜在的不足：

1、在大型项目中，故事之间关系可能错综复杂；

2、开发过程规定要有需求的可追溯性，离不开额外的文档；

3、不适用于特大规模多团队的结构

 

第14章 用户故事不良症兆一览

小结

在本章中,我们了解了以下一些不良症兆:

故事太小

故事互相依赖

镀金

故事中包含太多的细节

过早包含用户界面细节

想得太远

故事划分太过频繁

很难为故事安排优先级

客户不愿意写用户故事,为故事安排优先级

 

第15章 Scrum与用户故事

Scrum 是一种迭代和递增的过程。

Scrum每30天一轮迭代,称为Sprinto晴公珍黛 品气课馆画食外必类人

ScrumMaster相当于传统的项目经理,但更像是领导者和组织者,而不是经理。

一般的Scrum团队包括4~7个开发人员。

产品 Backlog 是一个待开发的功能需求列表,里面的条目要么还没有实现到产

品中,要么还没有计划在当前 Sprint 中开发。

Sprint Backlog是一个团队承诺在当前Sprint完成的任务列表。

在极限编程里面的客户角色,在Scrum 中称为产品负责人。

产品负责人负责给产品Backlog排列优先级。

在Sprint开始，团队从产品Backlog中选择下一个Sprint要完成的任务。

在每日Scrum简会中，每个团队成员需要回答三个问题：我昨天完成了什么？今天我要做什么？我碰到了哪些问题？

每个Sprint都要完成一部分可以潜在交付的产品功能增量。

在Sprint结束时，团队在Sprint评审会议上演示所完成的功能。

 

第16章 其他话题

处理非功能性需求

纸质还是软件？看具体情况

用户故事和用户界面

保留故事（卡片）

把小的缺陷报告用一个封面故事卡装订在一起，并把他们当成一个单一故事

 

第IV部分 一个完整的实例

第17-21章 举了一个购物网站的项目例子
————————————————
版权声明：本文为CSDN博主「崔大发啦」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/bfqs1988/article/details/100031679

转载于:https://www.cnblogs.com/cuidafa/p/11398428.html