Booknotes-用户故事与敏捷方式

Chapter 1

用户故事应包括：一份书面的故事描述；具体化的故事细节；测试

不要在项目开始前就做一套包罗万象的决策，要把决策分散在项目过程中

故事驱动的项目，最引人注目的是客户和用户在项目整个过程中的全程参与

一个发布由一个或多轮迭代组成

Chapter 2

A good stories' characterics: INVEST

I- indepedent

N- Negotiable

V- Valuable to purchasers or users

E-Estimatable

S- Small

T- Testable

 

Invest

出现故事间依赖，可以通过下列方式绕过依赖：

1. 将相互依赖的故事合并成一个大的，独立的故事

2. 用一个不同的方式去分割故事

Negotiable

Story is negotiable, it’s not signed contract or the must implemented requirements. Story is the brief introduction of requirements, and the details will be discussed in the following development process.

Valuable to purchasers or users

To make sure it’s valuable for users, it’s better to let user to write the stories

Estimatable

It’s important for user to estimate the story point. There are three reasons which may lead to the story unestimatable

1.       Developer lack domain knowledge

2.       Developer lack tech knowledge

3.       The story is too big

Small

复合故事

·         对于复合故事，可以根据“创建”，“编辑”， “删除”这些动作来进行分解

·         也可以根据数据边界来分解

复杂故事

如果一个故事因为不确定性而复杂，可以将它分成两个故事：一个做调研的故事和一个开发的故事

 

Testable

故事必须是可测试的，成功通过测试可以证明开发人员正确的实现了故事。

给故事加上注释的最好方法是给他编写测试用例

 

Chapter 3

用户角色（User Role）是一组属性的集合，这些属性刻画了一群人的特征以及这群人与系统可能的交互

角色建模的步骤

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

·         整理最初的角色集合

·         整合角色

·         提炼角色

 

整理最初的角色集合

角色分组-合并同类项

尽量坚持一个原则：用户角色定义是人，而不是其他外部系统。如果觉得有必要，也可以偶尔确认一个non-human user role

整合角色-梳理角色间关系

提炼角色

整理好角色后通过给每个角色定义一些特征来建立角色模型

1. 用户使用软件的频率

3. 用户在相关领域的知识水平

4. 用户使用计算机和软件的总体水平

5. 用户对当前正在开发的软件的熟悉程度

6. 用户使用该软件的总体目标（便捷？用户体验？）

 

角色建模额外技术：虚构人物， 极端人物

 

Chapter 4 搜集故事

要像“拖网渔船捕捞鱼” 那样来收集需求。

·         不同大小的网用来捕获不同大小的需求

·         拖网表达了另一层含义：需求会像鱼一样，会成长，也可能会死亡（有些需求会变得重要，有些之前重要的现在不重要了）

·         正如在某区域不能捕获所有的鱼，我们也不可能捕捉到所有的需求。也有可能捕获到一些废弃物或残骸，会使需求膨胀

·         技能也是发现需求的一个要素。熟练的需求分析人员知道在哪找需求，而不熟悉的只会用低效的方法在错误的地方浪费时间。

 

敏捷项目承认没有一个理想的方法可以在一个单一阶段获取到所有的用户故事

即使敏捷流程支持需求的后期涌现，依然需要对预期的发布进行展望并开始写下容易发现的故事

故事搜集的有用方法：

• 用户访谈

只询问用户“你们需要什么“是不够的，大部分用户不太善于理解，更难以表达他们的真是需求

要想获得用户的本质需求，最好的技巧是提问。善用开放式问题和背景无关的问题

• 问卷调查

适合收集有关故事优先级信息

不适合作为拖网捕获新故事

• 观察

观察用户实际使用软件的情况

• 故事workshop（开发，用户，产品，客户等共同参加的会议）

通过画原型，梳理逻辑。重数量不是质量

 

Chapter 5  与用户代表合作

我们要考虑潜在用户代理的背景和动机，要认识到差异

用户的经理，开发经理，销售人员，领域专家，市场营销团队，客户，培训师或技术支持，业务分析师或系统分析师等都有自己的盲区，不一定能如实反映最终用户的需求

 

与用户代理合作时需要注意的问题：

能接触到用户但访问受限时

-请求准许启动一个用户顾问团队，顾问团队能提出意见和建议，而用户代理是decision maker

实在不能接触到用户时

-使用多个用户代理

 

Chapter 6  用户故事验收测试

验收测试提供了确认故事是否被完整实现的基本标准

在写代码之前写测试；且验收应有客户而不是开发人员来写

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

 

Chapter 7 优秀用户故事准则

编写封闭的故事，能让用户使用后觉得她完成了某个任务

编写约束卡，尽管约束卡不会像普通卡片那样被安排到迭代中，但它们仍然会有用处

根据实现时间来确定故事规模（基于故事实现的时间跨度，以不同的层次来编写故事）

不要过早设计用户界面

有些需求并不是故事

在故事里包括用户角色

用主动语态编写

由客户编写

用户故事要简短，它们的目的是提醒开发人员和客户进行对话

 

Chapter 8 估算用户故事

估算故事的最好方法具有如下特征：

·         无论什么时候获得有关故事的新信息，都允许我们改变之前的想法

·         适用于史诗故事和小故事

·         不需要花很多时间

·         提供进度和剩余工作的有用信息

·         不太精确的估算也不会有大问题

·         可以用来制定发布计划

按照故事点估算：

可以定义一个故事点为一个理想工作日；可以为一个理想周的工作；也可以把故事点作为故事复杂度的测量

用理想日估算更好，第一，相较于连续时间估算，更简单；第二，相较于用完全模糊单位，用理想日估算故事点可使我们的估算拥有更好的依据。

估算的主要目的是知道整个项目的工作量，所以最后我们总是要将估算换算成时间的

以团队估算

故事估算属于团队集体有两个主要原因：

第一，  还不确定团队中谁负责这个故事，所以应分配给整个团队；

第二，  第二，团队决定的估算可能比个人估算更有用

估算

1.       所有参与估算的客户和开发聚集一起，客户随机抽取一个故事读给开发，开发根据需求尽可能提问。如果客户不知道，可以猜或者推迟这个估算

2.       如果对故事没疑问，则每人写一个估算值（理想日/周/复杂度）

3.       展示每人估算值。估值高和低的分别解释估算依据，并相互讨论

4.       如果讨论过程中发现问题，客户解释或加注释

5.       讨论完后，开发人员再次将估值写在卡上，并将卡片再次展示给所有人看

三角测量

做几个估算后，根据这个故事与其他一个或多个故事的关系做估算，确保每个估算相对其他估算都是合理的来优化估算。假定一个故事4个故事点，第二个故事为2个故事点。把这两个故事放在一起考虑时，程序员应该都同意4个点的故事大概是2个点的故事两倍

Velocity 代表一个团队在一轮迭代中完成（或期望完成）的故事点数。

估算精度随故事大小增加而降低

故事点越大，精度越差

为了避免这种情况和简化问题，可以约束估算只用一些预定的值：

½  1, 2, 3, 5, 8, 13, 20, 40, 80

Tips

1.       不同团队间对一个故事估算的故事点是不一样的

2.       一个故事分解成一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等

3.       一个故事分解成一些任务，这些任务估算的总和不需要和故事的估算相等

 

Chapter 9 发布计划

理想情况下，开发人员和客户可以谈一个日期范围，而不是一个具体日期

为了计划一个发布，客户必须排列故事的优先级。排列优先级规则（MoSCoW）

必须有（must have）

应该有（should have）

可以有（could have）

这次不会有（won’t have this time）

 

排列故事优先级，可以利用的技术要素：

·         故事不能如期完成的风险

·         推迟实现一个故事时对其他故事的影响

客户对story优先级排序考虑的因素：

·         故事对于广泛用户或客户的重要性

·         故事对于少部分重要用户或客户的重要性

·         故事与其他故事的内聚性

 

对一个项目来说，应该先做最有价值的一部分，而不是优先考虑有风险的部分

选择迭代长度

尽可能坚持固定的迭代长度，这样有利于团队的开发速度

 

初始速率

可以通过下面三种方法获得初始速率：

·         使用历史值

·         执行一轮初始迭代，使用那轮迭代的速率

·         猜测

历史值是最好选择；

猜测速率（考虑干扰因素，把一轮迭代的三分之一到一半的开发日作为预计速率很常见），使用速率将理想日为单位的估算转换为日历日

 

Chapter10 迭代计划

迭代计划会议的一般内容：

·         讨论故事

·         故事中分解任务

·         开发人员承担每个任务的职责

·         讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺

讨论故事

排好优先级的故事集合是迭代会议的输入。

客户从最高优先级的故事开始，读给开发人员

开发人员提问，理解故事，并分解出任务（没必要理解故事的所有细节）

分解任务

将故事分解出更小的任务更符合项目需求：

·         开发人员不止一个，技术人员的专业性不一样，便与工作划分

·         故事是对用户或客户有价值的功能描述，并不是开发人员的to-do list

·         敏捷没有瀑布似的前期设计步骤，故事任务分解是即时设计的一次短脉冲

分解任务准则：

·         故事的某个人物特别难于估算，就把那个任务从故事其余任务中分离出来

·         倘若有些任务可以很容易安排给多名开发人员共同完成，就分割他们

·         若有必要让客户了解故事某一部分的完成情况，可将那部分拿出作为一个单独任务

Chapter 11测量并监控速率

测量速率

最初的速率往往不准确，而且速率再初期的迭代中也很不稳定，可能需要两三轮迭代后才能获得一个长期的，比较稳定的速率

不能将尚未全部完成的故事也计算在速率中

·         无法计算故事已完成的百分比

·         不想使用像43.8这样带小数的值为速率引入错误的精度

·         没完成的故事并不能给用户或客户带来任何价值

·         即使90%完成，最后10%的工作可能非常复杂

大家一起先完成一些故事比所有故事都只完成一部分更有价值

监控进展的方法：

·         计划速率和实际速率图（监测实际速率和计划速率的偏差）

·         累计计划故事点和实际故事点（每轮迭代完成的故事总数）

·         迭代燃尽图（每轮迭代末剩余的工作量）

·         迭代中燃尽图（迭代内剩余的估算小时）

在迭代中发现一个遗忘的故事，除非这个任务是当前迭代某故事的前置任务才能添加。如果只是想在迭代中加新东西，就不应该加，而应通过下次计划会议通过调整故事优先级把人物排入到某一轮迭代中

 

Chapter 12 用户故事不是什么

需要修改requirement specification 时我们称之为“change of scope”， 这种想法是不正确的。因为不管预想多么全面，我们都无法实现完全定义一个完整的具有相当规模的系统；而且在定义需求和用户早期频繁接触软件之间，有一个有价值的反馈循环；考虑用户的目标比列出方案的特性更重要

用户故事与用例场景类似，但用例往往仍比单个故事要大，更容易包含关于用户界面的嵌入式假设

用例存在于整个开发过程中，用户故事生命周期仅限于开发他们的迭代中

 

Chapter 13 用户故事的优势

用户故事强调口头沟通（更多关注讨论需求而不是写下需求）

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

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

·         用户故事适合迭代开发

·         用户故事鼓励延迟细节

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

·         用户故事鼓励参与式设计

·         用户故事传播隐性知识

 

用户故事的不足：

·         在拥有大量用户故事的大型项目中，故事间的关系可能错综复杂，难以捉摸，难以组织好成千上万的故事

·         开发过程规定要有需求的可追溯性，必然离不开额外的文档

·         尽管面对面沟通可以促进隐形知识的共享，但在大型项目中，单单依赖这种交谈难于实现有效的扩展来完全替代书面文档

 

Chapter14 用户故事不良征兆一览

1.       故事太小（小故事依赖于故事实现顺序，顺序不同，估算值可能差异也会很大）

2.       故事相互依赖（把相互依赖的故事合并成一个故事）

3.       镀金（提高项目组每个人的任务可见性）

4.       细节太多

5.       过早考虑用户界面细节

6.       想的太远（承认事先不可能发现所有需求，好的软件实在不断的迭代中发展而来）

7.       故事划分太过频繁

8.       客户很难为故事安排优先级（客户感到难以安排优先级，一个可能是故事太大，另一个可能是真没体现商业价值，客户无法区分，需要重写）

Chapter 15  Scrum与用户故事

Scrum基础

实施scrum往往采用30天为周期的迭代，一个scrum团队通常由4-7个开发人员组成

Backlog是所有待开发产品功能的列表

Sprint计划会议

参与者包括PO, Scrummaster， scrum team，其他管理人员也可以参加

·         会议前半段PO把待开发高优先级的功能介绍给scrum 团队

·         第二阶段，团队成员针对第一阶段中介绍的每个待开发功能提出问题，如果团队成员有信心完成就从backlog移到sprint backlog

·         下半段，讨论用户故事，决定下一轮迭代能够完成的工作量。

Scrum的主要规则：

·         在sprint开始时召开sprint计划会议

·         每个sprint必须发布可以工作的，经过测试的代码，这些代码能够完成对最终客户有价值的一些功能

·         PO为产品backlog排列优先级

·         团队一起决定一轮迭代完成多少故事

·         在任何时候都可以向产品backlog中添加故事，或者重新排列优先级

·         每天由一个scrum meeting，每个项目成员回答三个问题：我昨天做了什么？我今天打算要做什么？我由什么困难？

·         只有团队成员能在每日scrum meeting上发言，其他人只能旁观

·         在sprint结束时的sprint review meeting上，团队会验收完成 的效果（可工作的软件，而不是幻灯片）

·         准备sprint评审会议的时间不超过2小时

Sprint review meeting

每个sprint都要发布一个“潜在可以交付的产品功能增量”

Daily scrum meeting

尽量只回答三个问题，主要目的时每个人在自己以及同事面前做出承诺，而不是给SM的汇报会。

有时候团队部分成员需要留下来解决手头问题，但注意，不要再每日短会中解决问题。

 

Scrum由三个角色，三种活动，3种交付物组成： 

 

三个角色： 

 

Product Owner 

 

Scrum Master 

 

Scrum Team 

 

三种活动: 

 

the sprint planning meeting 

 

daily scrum meetings 

 

sprint review meetings 

 

3种产物: 

 

the product backlog 

 

the sprint backlog 

 

a burndown chart 

 

Chapter16 其他话题

处理非功能性需求

不是所有东西都必须转化为用户故事，一般都会有一部分需求无法恰当地以故事形式来表达，这些往往是非功能性需求

常见的非功能性需求类型如下：

·         Performance

·         Accuracy

·         Portability

·         Reusability

·         Maintainability

·         Interoperability

·         Availability

·         Usability

·         Security

·         Capacity

处理约束最好的办法是在卡片上写下约束，并将卡片标注为“约束”卡

采用数据字典来表示系统所有变量的大小和类型有不错的效果

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