六招吃遍天下用户故事

让你的思维如水一般没有束缚，招式变幻的伟大可以在水中得到启迪。——李小龙

你是不是觉得INVEST，DEEP有点不知所措？人做事情不是通过知识而是通过情绪，如何能把面对用户故事的拆分知识变成与我们情绪相连的一个又一个的技巧？借由情绪与一个个无比落地的技巧就能实现靠谱的用户故事，你不信？下面就是这六个招式：

第一招：状态探针（快速掌握沟通效果）

我们需要快速了解沟通的效果以保证整体的高效性，而不是花费时间讨论我们已经达成共识的内容。

状态探针

• 伸出五个手指头就代表你对这件事非常了解，直接就能制作开工，不需要进一步的解释。
• 一个手指头就是，我就知道这些文字，到底干什么东西我一点都不清楚。
  剩下的代表自己不同的理解程度。
• 说出我们要对哪件事情进行“状态探针”，确认大家准备好伸出手指头。
• 3、2、1统一伸出手指头。
• 大家不同数量的手指头代表的内容进行讨论。

第二招：动物大小（快速掌握故事粒度健康度）

粒度相似的用户故事是健康的用户故事，如果太小就会是一种浪费，如果太大，谁都说不清楚它有多大。

动物大小

• 每人发一张报事贴
• 把所有用户故事摊开，问大家如果这些用户故事工作量的大小用动物的体积来表现的话，最小的动物是什么动物？最大的动物是什么动物？
• 每个人在报事贴上写两个动物的名字，不用写对应的用户故事名称。
• 跟大家说明理想中的用户故事粒度是什么样子的。
• 对粒度大的故事进行拆分，对粒度小的用户故事进行合并。

第三招：大便、石头、钻石（快速归类不同程度的故事）

在不同阶段我们需要不同程度的用户故事，利用比喻一方面可以迅速得到故事的程度分类，另一方面大家会非常清楚对待开发用户故事的期望。

大便、石头、钻石

• 三种类型的含义
• 大便：我根本不知道这故事说的是什么，可能也就知道个大概。
• 石头：我大概知道边界和工作内容，能给出一个估算，但对一些细节不了解。
• 钻石：我非常明白故事里面的验证点和需求边界。离开屋子我就能去开发这个故事。
• 用户故事在不同阶段应该处于不同分类，启动阶段应该是大便，启动阶段之后应该是石头，开发之前都应该是钻石。
• 让开发人员快速对所有用户故事快速归类所有已知的故事。需求人员动嘴不动手，尝试说服开发人员把石头和大便分类下的故事移动到钻石分类。
  最后
• 大便部分的故事：是需求人员未来的任务，需要启动下一次会议，或者推迟这些需求的开发。
• 石头部分的故事：是需要人员接下来的任务，确定模糊的点，争取让开发人员放入钻石部分。
• 钻石部分的故事：全体成员补充讨论之后确认的内容，比如验收条件

第四招：不靠谱标记（快速标记风险）

我在观察一系列用户故事是否健康一般有两个标准：一、是否有大的用户故事。二、是否没有标注风险与假设。

不靠谱标记

• 快速在用户故事卡片上标注，有哪些不靠谱的用户故事，并用不同颜色表示两种不靠谱类型：
• 需求不靠谱：需求没有明确，业务没有想好
• 技术不靠谱：技术的方案没有确定，或存在技术风险。无法给技术人员信心。
• 对两种不靠谱的内容，产生跟进项。
• 需求跟进项由需求人员跟进，并跟踪。
• 技术跟进项产生“技术预研任务”（Spike），并跟踪。请参见第六招式

第五招：我是一名工匠（锁定需求边界）

软件测试或开发人员甚至需求分析人员都是工匠，如果不锁定边界，我们不会获得荣誉感，并持续提升我们的匠艺。

我是一名工匠

• 要较真什么是新需求，什么是缺陷。对于新需求要无情的添加卡片，并给出估算。如果是缺陷，那就按照团队的对缺陷的标准进行修复（强烈建议不给估算）。
• 敏捷软件过程不是每个故事卡片不知道什么时候做完。对于每一个用户故事而言也有传统软件开发的冻结时间。但对于新的需求可以添加新的卡片。
• 一般锁定边界使用验收条件并使用：Given, When, Then的形式
• 提升整体质量必须先提高需求的质量

第六招：问题与时限（面对学习和任务）

软件的过程是一个学习的过程，但单纯的学习或探索不能给软件带来直接的增值。所以我们一般不会形成任务卡片或学习卡片。但如果存在的话，就必须按照下面两项进行要求：解决哪个问题？时间的限制？

问题与时限

• 列出所需要解决的具体问题，比如：我选用的框架是否支持3000人并发？或 是否能在30分钟内添加对框架的测试代码？
• 给出时间限制，比如在两天内完成，或在启动后48小时内完成。
• 如果超过时间的限制，那就创建新的卡片进行探索和学习。
• 除了在启动阶段，建议整个团队在同一时间点上只能有一个探索或技术任务实施中。
• 尽量不要有此类型的任务

这六个招式能不能帮助你一些呢？希望你在使用这些招式之后也多分享你的心得……

如果说还有一些没讲的话，我觉得就还剩下估算和拆分了，敬请关注微信公众号“思维发条”....