【在线研讨-现场文字】《敏捷开发用户故事分类与组织结构（二期-1）》2012-07-03

 

回顾及普通用户故事（功能）的写法

 

陈勇-创业-北京(**9107533) 13:02:13
这个讲座分为两期，原因是用户故事在早期和晚期有两种重要功能。
早期，是描述、分解和估算需求的数据；晚期，则是指导开发并反应开发的进度。这是需求条目化的优势。
我们特别提到，要想更贴切地描述和估算需求，FPA也就是功能点的方法显然更具备优势，尤其有数万个统计数据的支撑，所以用户故事应该去借鉴它，而不是尝试独辟蹊径。
但是今天的内容，则和功能点没什么关系了，是关于开发的。

 

二期内容：

1. 回顾一期
2. 有哪些种类的用户故事？哪些决定了产品架构？哪些是细枝末节？不方便写成“作为一个……可以……以便……”的故事该如何描述？
3. 用户故事组织结构：如何“摆放”用户故事才能不失大局？如何才能“一眼看到”10人年开发的成果？
4. 用户故事跟进开发：用户故事后来哪里去了？用例、MVC这些设计实现元素与用户故事这个需求管理元素有什么对应关系？

陈勇-创业-北京(**9107533) 13:04:25
好，现在进入2.

之前提到过，如果用户业务数据+业务操作作为史诗故事+用户故事，则能很好地向用户描述产品的结构，因为符合他们的业务描述方法。但有些故事，却很难说是用户可以理解的，比如：
1. 修改一个缺陷；2. 改变界面的颜色；3. 移动一个按钮的位置；4.吧SQL Server重构成兼容Oracle的。
所以，我们发现除了那些勾勒产品功能轮廓的功能之外，还有一些功能，是“细枝末节（某些不是，后面讲）”。
应该怎样描述这些用户故事呢？这个我自己写了300多个用户故事，仔细斟酌了一下，总结了一些新的语法。

 

首先我们回顾一下用户故事的语法（这里，应该称之为“用户业务操作的语法”）“
作为一个……（某角色），可以……（某功能），以便……（达成某个用户的业务价值）
比如：
查看意向表：作为一个产品经理，可以查看意向表，以便了解当前及前后迭代中规划过哪些用户故事。
先说说这个”意向表“
意向表，是我们开发火星人的时候遇到的一个用户数据
其实就是SprintBacklog的前身。
我们工具中存储着Product Backlog，就是产品的所有待开发项，其中一些，将被在下个迭代中选择为Sprint Backlog，并在下个迭代中做完。
这中间，会有一个过渡状态的东西，就是产品经理从PB中挑选出来了，但还没有经过计划会的估算和讨论，就是这个”意向表“，讨论和估算后被承诺下来的部分，就变成Sprint Backlog了。

 

陈勇-创业-北京(**9107533) 13:12:12
查看意向表：作为一个产品经理，可以查看意向表，以便了解当前及前后迭代中规划过哪些用户故事。
说的就是产品经理，在计划会前准备意向表的故事。
类似的业务操作还很多，比如：

 

加入意向故事
–作为一个产品经理，可以点击丌在意向表中的故事，以便将其快速加入意向表。

 

挪出意向故事
–作为一个产品经理，可以点击一个已经在意向表中的故事，以便将其快速挪出意向表。
……
这些写法有什么好处呢？1. 有角色；2. 有功能 3是重点，有用户价值。因此，这样写出来的东西用户看得懂，而开发人员也不会背离开发的初衷，只埋头于功能（有很多功能，开发出来了，但却”不能用“，就是因为功能不等于价值）