作为自己在工作的一种记录，因为我一直认为产品经理（Product Manager 简称PM）算是一种新行业、（都说PM始于宝洁，但是也可能更早之前就出现过做着PM做的事，但他是其他职位的人。）进入中国不超过15年。所以需要我们不断的与其他的PM或人进行讨论、实践、总结，再讨论、实践、总结。形成进步学习的闭环。
敏捷开发之用户Story
用户Story也叫用户故事只需要X度一下，全部都是相关的介绍和说明，我这里就不再过多的需求。他们每一篇的内容大致都是说用户故事需要遵守INVEST原则。
INVEST原则
Independent：独立性
用户故事之间应该具有独立性，不应该依赖于其他的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。
Negotiable：可协商
用户故事是由客户或者PO同开发小组的成员共同协商制定的，用户故事代表了一个用户群体的需求，而这个需求是零散的，通过相关人员的沟通，协商经常可以丰富用户故事。
Valuable：有价值
用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
Estimable：可评估
对于一个用户故事的划分需要足够的领域知识，使得在划分故事之时就能大致了解故事开发的周期，为了减少估算的不确定性，故事本身不能太大。
Small：短小
故事应该尽量的短小，当然也不是说越小越好。短小的故事可以减少分解过程中估算的误差，最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。
Testable：可测试
如果一个用户故事无法进行测试，那么也就无法判断该故事是否真的完成。所以，用户故事必须在定义了验收测试通过的标准后才能认为用户故事开发完毕。
下面我就说说我的看法吧。希望对各位和我都起着小黄鸭的作用吧：）。
用户Story
一、用户Story的作用
用户Story，我认为是在我经历过的项目中起一个特殊的地位。在开发中你可以不使用Story，你都可以完成整个流程的开发。这样的结果只是会被“锤脑壳”。。。至于原因嘛Emmmm...
除了减少“挨打”的次数，用户Story还是以简短的话语尽量还原”场景“下的用户需求。用户是在怎样的一个情况下提出这个需求的。
二、用户Story—基本要素
写用户Story的时候我们需要围绕三个基本要素来写。用户（角色）、需求（目的）、原因（好处）三点。
通过一定的需要修饰就组成了我们常见的Story语句。
三、用户Story—用户（角色）
在写用户Story时我们最先写的就是用户（角色），作为Story的开头，用户（角色）十分的重要，因为我们产品出发点都是从用户（角色）出发，不同的用户（角色）他们的需求和原因都是大不相同的。不同用户（角色）之间，都会存在着相互矛盾、相互冲突的需求。（就像在居民楼里休息的上班族与居民楼外广场上跳舞的阿姨，他们就可能存在着冲突）所以我们在”创建用户“时一定要给他附带属性。如：学生、程序员、Coser等或者在这些属性前加上特殊字以便自己更好的确定用户属性。如：秃顶的程序员（疯狂暗示）、没钱的学生、富LuoLi等
来源：@百度 未商用侵必删
四、用户Story—需求（目的）
在前面明确了用户（角色）之后，我们就需要确定他的需求（目的），一方面可以从我们的商业价值来表述。另一方面也可以从用户需求来描述（其实我觉得他俩就是一个，能够解决用户需求的产品，能够解决的方式，方法也是他的商业价值）。
我们在描述需求（目的）的时候，我们需要尽可能地不要直接去描述功能（虽然知道是什么功能）。至于原因，我个人认为是为了更加偏向于”真实需求“。
举个例子：在是古代，人们只能骑马，从西藏到黑龙江需要几十年（瞎掰）。
这个时候有个传令官需要从西藏到黑龙江。这个传令官就是角色那个的需求是什么？按照我们现在的思维的话，他需要的飞机，直接飞过去。几个小时就可以达到。但是这个需求是真实的吗？肯定不是，那他的真实需求是什么？ 他的真实需求可能只是能够更快的到达目的地（黑龙江）罢了。
把时间换成现代，马儿变成车，但是他的需求还是不是飞机这个”功能“还是只是能够更快的到达目的地（黑龙江）罢了。
这样在后期开发就尽量避免出现我只想要个指甲刀，结果你给我一把瑞士军刀，延长了开发周期和资源成本。
来源：@百度
五、用户Story—原因
最后一部分就是用户Story中的原因，是什么样的原因促使前面的用户（角色）产生了前面的需求（目的），是开发没有女朋友吗？是后端的纸片人没有更新吗？更或者是为了治疗秃顶？
原因其实很简单只需要从实际出发，而非凭空想象，即可。
六、常见的Story模板
一、我是（角色），我希望（功能），这样（好处）。
二、作为（角色），我想要（商业价值），以便（原因）。
三、作为（角色），我想（目标），以便（某种原因）。
在写Story的时候我们需要尽可能的保持刚刚好的详细，让用户Story有“笔直性”。避免增加过多的细节要求，让Story变得复杂。
结尾大家也来试试写一些用户Story。
网友评论