Question

如何使用用户故事驱动敏捷开发

Answer 1

首先来说什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能。既不是用来替代传统需求，也不是仅仅记录一下用户的需求的，用户故事是用来讨论和跟踪的。使用用户故事，我们的目的是让用户可以自然的讲述需求，这样才能确保信息的真实性。因为任何软件产品都是为了帮助用户完成某种任务，可以说任何的软件产品或者系统都是通过交互来解决问题的，而交互的双方可能是人和系统，也可能是系统和系统，也可能是模块和模块。这样理解的话，任何的需求其实都是某个个体（人，系统或者模块）在和其他个体进行交互的过程中，我们希望的行为方式。
关键点：角色（人：谁要使用这个功能），活动（过程，需要完成什么样的功能）和目的（为什么要这样的功能，有何商业价值）
简单的举个例子：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
用户故事其实就是一个沟通工具，如何编写并不重要，重要的是可以把用户和技术团队联系在一起，让团队里的每个人都知道需要交付的内容。
如何讲用户故事？
第一步：找出故事主角
一般情况下用户是不知道从哪开始讲故事的，不要紧，就按照平时我们跟别人讲故事那样，先从我们的角色讲起，在这个故事中，我们先把角色找出来了，就可以慢慢的丰满
你会发现，当团队开始整理不同的类型的用户的时候，他们已经开始自然的讲述故事，因为要把一个角色说清楚，你就必须考虑他要做的事情，故事自然就出来了。但是在这个阶段，我们切记不要过于发散，明确我们的目的是整理用户画像，只要不同用户类型间的边界清晰了，就可以结束，不要为细节纠缠。另外，在后续的过程中我们也会发现可能有些角色还需要添加进去，那么就到时候说。
第二步：画出故事主线
有了故事主角，我们再来讲故事，在这个阶段主要做的就是帮助团队把故事的每个步骤都想好，通过在看板上进行可视化，我们就可以达到这个目的。这里， 我们可以使用简化版的影响地图，如下图：
标准的影响地图上有4个列，分别是WHY WHO HOW和WHAT，这种结构在进行比较大和模糊的目标讨论的时候，如：战略规划，会很好用，因为HOW和WHAT比较容易区分；
影像地图就是为了可视化，大家可以聚焦在白板前，讨论步骤可以如何细化，如何做的更好。

第三步：使用用户故事地图进行功能分析
之前是做了一个故事的主线，现在用规格化的过程，现一些在故事主线中看不到的技术细节。我们可以使用用户故事地图的方式来进行，团队一起根据故事主线中的每个步骤进行讨论，分析出在产品的特定区域（模块）中的功能点，并使用技术人员容易理解的方式来描述这部分的功能。这整个过程就是从将需求从用户角度的描述转换到技术实现角度描述的过程。

最上面2层是产品的功能区域（模块）
每个模块下面功能点，这些功能点来自于用户故事中的某个步骤的分析
每个功能点的即时贴上标注出用户故事的ID，这样便于我们比对影像地图找到对应的功能点
一些在影响地图中没有明确列出的内容在这张图上被显示出来，比如上图中后台管理和系统功能部分的内容
用户故事的六个特性- INVEST
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

Answer 2

用户故事是敏捷开发中提出来的一个概念，从用户角度来描述用户渴望得到的功能。是一种对需求的描述方式，当我们给研发讲需求时，用户故事可以让研发了解需求的背景，进一步理解需求。

用户故事的格式通常为：

作为一个xxx（某类用户），我要xxx（做一件事），从而达到xxx（某一结果或动机）。

在写用户故事之前，我们可以思考：

（1）这是一群怎样的用户？

（2）在什么场景下，想解决什么问题？

（3）解决问题的过程中碰到了哪些问题？

（4）最后用户想要怎么解决？

另外，我们在写用户故事时，还要注意遵循「INVEST」原则：

独立的 (Independent）：独立原则要求编写的用户故事之问应当是相互独立而不是相互依赖的。用户故事相互独立可以降低需求的优先级排序和迭代计划制定的难度。

可讨论的 (Negotiable）：用户故事是可讨论的，意味着故事描述的需求不是巨细无遗的，它只是对需求的简短描述，更多的细节将在与用户的讨论中产生。

有价值的 (Valuable）：用户故事必须体现出用户关心的价值。

可估计的 (Estimable）：用户故事中的需求描述虽然不够具体详细，但是也必须能够让开发人员对故事的大小和开发的工作量进行估计，否则就无法制定迭代计划。

小的(Small) ：用户故事应尽可能地避免史诗式的巨型故事，小型故事既便于估计，也便于制定迭代计划和跟踪监控。

可测试的 (Testable）：用户故事必须是可测试的，这样才方便验证故事是否完成。