上两篇阐释了Why：为什么使用户故事，而不是详尽的文档？

What、How、Who：什么是用户故事，怎么写，谁来写，谁使用？

这一篇阐释When，在Scrum流程的各个环节如何使用用户故事：

When：什么时机，如何使用用户故事？

终于来到敏捷的流程上。

用户故事几乎是贯穿于整个敏捷开发流程。在每个环节都有其重要做用。任何一个环节如果没有很好的执行和使用，就难以发挥用户故事的作用，造成团队转而对详尽的文档的再度依赖。

用户故事与敏捷方法在流程中的应用

用Scrum为例子，Scrum的5大活动：

-- Sprint计划会议（Sprint Planning Meeting）

-- 每日站会（Daily Scrum Meeting）

-- Sprint评审会议（Sprint Review Meeting）

-- Sprint回顾会议（Sprint Retrospective Meeting）

-- 产品Backlog梳理会议（ Product Backlog Refinement）

要用好用户故事，需要进行如下活动：

1、用户故事估算

2、优先级排序

3、用户故事拆分

4、任务拆分和估算（与用户故事估算区分）

5、发布计划

6、迭代计划

7、测量和监控速率

用户故事估算：

Why为什么要进行用户故事估算？

作用一：客户团队参考用于排优先级。比如：一个业务价值高的故事估算出来要4周完成，1个或者多个业务价值中等的用户故事只需要1天就可以完成。客户团队可能会将业务价值中等的这个故事排出更高的优先级，先做。

作用二：为后续的发布计划提供必要的数据参考，以便得出发布周期和范围，允许±2个迭代的误差。

作用三：（附加作用）此过程让团队充分沟通，客户团队和开发团队达成共识，需求的讨论存在于大家共同的脑海里。

What什么是用户故事估算？

粗粒度的用户故事，还没有排入迭代的产品特性或者已拆分的独立故事。团队共同预估和猜测这个用户故事的大小，以粗略估计其工作量。

How如何进行用户故事估算？

扑克牌

经验（猜测）、理想周、小于一个理想周的工作量用斐波那契数列计算（1、2、3、5、8、13、21、34、55、89）以团队7人为例。

Who谁来进行用户故事估算？

理论上是团队共同决定，开发人员参加的越多越好。现实中，团队重要人员参与，根据实际情况。

1、客户团队：不能主动对估点发表意见，不参与估点。只能尽其所能的回答开发团队的问题（不知道答案，先猜猜看）。

2、开发团队：尽可能多的问问题。通过扑克牌进行估点，经过几轮（一般不超过3论）讨论，最终达成一致。

When什么时候进行用户故事估算，多久一次？

产品Backlog梳理会议。根据发布频率决定，比如三个月一次发布，每三个月进行一次用户故事估算。举例，如果三个月一次发布，每次发布之间留一个星期进行产品Backlog梳理，这个期间是最好的进行下一次发布用户故事估算的时间。

失败因素：

1、客户团队和开发团队关系不融洽。

2、客户团队和开发团队任何一方都太过于强势，无法平等沟通。

3、存在不平等的关系，造成并非每个人都参与其中，存在一部分人只是看重要人物的决定而跟风。

任务拆分和任务估算：

Why为什么要进行拆分和估算？

1、拆分便于多人共同协作于一个用户故事。

2、估算便于合理安排一个迭代可完成的任务量。

What什么是任务拆分和估算？

按照优先级排列，准备放入当前迭代的用户故事，进行任务拆分，便于团队共同协作于一个用户故事。并由任务完成者对这个任务进行工作量的预估。

How如何进行任务拆分和估算？

拆分可以根据开发团队的特定技术专长来进行。比如：一个用户故事需要后端开发，前端开发，测试，就可以拆分为三个任务卡。

拆分可以根据任务的逻辑流程的先后顺序来进行。比如：一个用户故事需要先新增一条数据，然后对数据进行读取、计算并修改数据，最后删除数据，可以拆分为三个任务卡。

用理想天的方式进行估算。

Who谁来进行任务拆分和估算？

团队一起决定用何种方式拆分，由任务完成者主力进行该任务的估算。

When什么时候进行任务拆分和估算？

迭代计划会议的时候

失败因素：

过于纠缠于细节

优先级排序：

Why为什么要进行优先级排序？

为了计划一个发布，PO和客户团队必须排列一个故事的优先级。

What什么是优先级排序？

每个用户故事都是独立的可测试的完整可发布使用的功能。PO按照优先级排列，确认哪些先做和后做。团队按照优先级从高到低在承诺时间内优先完成优先级高的任务。

基本优先级排序：

-- 高优先级 High

-- 中优先级 Mediem

-- 低优先级 Low

为了避免无休止的对优先级的争论，可以使用DSDM方法

-- 必须有（High）

-- 应该有（High）

-- 可以有（Mediem）

-- 这次不会有（Low）

为了避免并列存在并列高优先级无法取舍，可以使用序列法

-- 1、2、3、4、5

How如何进行优先级排序？

优先级排序分风险驱动和价值驱动。

敏捷模式下，是价值驱动高于风险驱动。先做高价值的用户故事，风险也许会随着时间推移而消失。但是如果随着时间推移，风险并未消失，甚至有增无减，仍然要考虑先处理风险高的任务。

优先级排序要考虑的因素，包括但不限于以下几种：

-- 用户故事的价值

-- 用户故事的规模

-- 用户故事的风险

Who谁来进行优先级排序？

PO和客户团队，也可以参考开发团队的意见

When什么时候进行优先级排序？

任何时候，已经进入迭代并开始冲刺的用户故事除外。

取决于团队的灵活机动性，灵活性高的话，计划会议时候是最好的优先级排序和调整的时机。

团队速率：

How如何计算团队速率？

初始速率：第一个迭代的速率估计，历史经验、猜测

例子：6人团队，2周一个迭代10天，团队的理想天是6*10=60天，这仅仅是理想天，因此要根据情况减半，或者1/3。由此算出的第一个迭代的初始速率为20或者30。

团队速率：通过6个月的持续反馈和改进，团队的速率接近一个稳定的值，这个值就是团队的速率。

Who谁来计算团队速率？

SM

When什么时候计算团队速率？

一个迭代完成，或者开始。

发布计划：

Why为什么要制定发布计划？

即便敏捷开发是不断顺应市场变化而变化的，仍然是需要一个预期和发布时间预估，只是无法精准到天，允许±2个迭代的误差。（传统瀑布流的开发模式也无法精确到天，事实上传统模式下的开发总会比计划的发布日期拖延几个月到半年交付）

敏捷项目三角

What什么是发布计划？

根据产品路线图，规划发布。以做出一个合理的预测，完成符合用户期望的发布需要多少轮迭代。

发布计划需要包含以下要素：

1、粗粒度故事，不包含很多细节。

2、对这些故事的用户故事估点，和优先级排序。

3、选择一个固定的迭代长度。（1周、2周、4周，长度越长风险越大，因为反馈周期变长，反思和修正的机会变少）

4、团队的速率

How如何将用户故事估算转换为开发速率和发布时间预估？

用理想周进行估算的例子：

通过SM、PO、客户团队达成一致，本次发布计划预计包括用户故事： A、B、C、D、E

A用户故事的估算是一个理想周（5天），团队总共7人。总共任务点数=5天*7人=35点。

B用户故事的估算是两个理想周（10天），团队总共7人。总共任务点数=10*7=70点。

C用户故事估算是斐波那契数列8点

D用户故事估算是4个理想周（20天），团队总共7人。总共任务点数=20*7=140点。

E用户故事估算是斐波那契数列21点

总计 故事点数为 35+70+8+140+21=274

若团队速率为62，则开发时间为274/62=4.4个迭代±2个迭代。

因此可以估计发布时间点为6~7个迭代后。团队经过6~7个迭代可以发布A、B、C、D、E五个用户故事所构成的交付产品。

Who谁来制定发布计划

团队

When什么时候制定发布计划

按照发布周期，2~6个月，发布完成后，休整一个星期。这个星期进行backlog梳理，需求澄清会，发布计划会，等等。

迭代计划：

Why为什么要做迭代计划？

对粗粒度的用户故事进行更加细致的讨论，但仍然避免过于纠缠于细节。目的是确定团队这个迭代做什么，排列优先级，并从高优先级的用户故事开始选取。

What什么是迭代计划？

每个迭代开始的第一天，团队共同讨论做什么，如何做，谁来做。

How如何进行迭代计划？

-- 优先级排序

-- 任务拆分

-- 任务估点

Who谁来做迭代计划?

团队

When什么时候做迭代计划？

每个迭代开始的第一天

读书笔记用户故事与敏捷方法----流程篇就更新到这里，后续继续更新用户故事与敏捷方法-----产品篇。

谢谢！

欢迎添加QQ讨论：26988505