如何拆分复杂需求的用户故事？这些必杀技GET

原文摘自http://www.360doc.com/content/17/0213/14/30350201_628677923.shtml

小P说

复杂需求用户故事拆分可遵循3个原则、9种方法。

 

像惠普和中兴通讯这样的大型跨国公司都有规模庞大的研发组织，建立了敏捷教练团队，并在研发组织中广泛推广敏捷项目管理。我曾经在这两家公司参加了敏捷项目的咨询和实施，接触到的不少客户是电信、金融、能源等大型企业。用户需求往往非常复杂，掌握复杂需求用户故事的拆分方法非常关键，这直接影响敏捷项目的成败。具体说来，复杂需求用户故事拆分可遵循3个原则、9种方法。

 

3个原则

 

INVEST原则

 

拆分用户故事要遵循比尔·维克(Bill Wake)的INVEST原则，即一个合适的用户故事应该是独立的(Independent)、有价值的(Valuable)、可讨论的(Negotiable)、小的(Small)、可估算的(Estimable)和可测试验证的(Testable)。

 

二八原则

 

根据帕累托原则也就是二八原则，一个迭代80%的价值可能来自于其中20%的用户故事。假如有两种故事拆分方式，当第一种拆分方式将低价值部分拆分成独立的故事，而另一种拆分方式没有做到时，就意味着后一种方式把浪费隐藏到了每个小故事里。此时，应当选择前一种拆分方式，这样可以把低价值的故事直接作废或推迟实现。

　　

二八原则的验证方法是：在拆分后的一系列故事中，高价值、中价值、低价值的故事要一目了然，要能很明显找到一个实现它可以得到高价值或能降低大部分风险的故事。

 

故事适中原则

 

故事太大不好。故事太大，里面内容庞杂，头绪太多，可能导致无处下手或在一个迭代内无法完成。“小”这一特性要求我们拆分大的故事。但拆分故事时依然要遵循INVEST原则。

　　

故事太小也不好。比如有的敏捷团队太过细分故事：对于数据库建一个故事、对于UI建一个故事等，这样虽可以满足“小”这一特性，但它却不是“独立的”和“有价值的”。

　　

故事应该要多小呢?建议每个迭代6~10个故事，当然故事拆分的颗粒度取决于项目团队的生产效率。对很多团队来讲，当一个用户故事庞大到8个甚至13个故事点的时候就需要进行拆分了。

　　

建议每个迭代内的用户故事的故事点数差别不宜太大，拆分后得到的故事最好规模差不多大。把一个8点的故事拆分成4个2点的故事比拆分成5点和3点的故事更有用，因为PO能更自由地编排优先级。 

 

9种方法

 

理查德·劳伦斯(Richard Lawrence)和他的团队总结出故事拆分的9种经典方法。

 

简单/复杂

 

假如团队正在讨论的某个故事变得越来越大，我们可以停下来并提问：“可以工作的最简单版本是什么?”捕捉这一简单版本作为一个单独故事，然后把所有变体和复杂性拆解到它们各自的故事中。

　　

例如，作为手机用户，我希望在开机状态下系统能尽可能地寻呼到我，以便我不错过任何电话。故事1，……系统能记录我最近活动过的小区进行寻呼……故事2，……系统能记录我最近活动过的三个小区进行寻呼……故事3，……系统能记录我之前所在MSC进行边界寻呼……

 

推迟性能实现

 

不要太早考虑性能要求，我们常常忘了“让它工作，然后让它更快”这个原则。

　　

比如我们会有这样一个用户故事：作为用户，我希望能够在1秒内获取查询结果。可能这个1秒的优化会花去我们很多时间，而且优化后由于其他模块的影响，查询速度可能再次变慢，所以我们可以尝试拆分成以下故事：故事1，作为用户，我希望能够获取查询结果。故事2，作为用户，我希望查询结果能够在1秒内获取。把故事1放入早期迭代，故事2可以尽量晚一些，在交付前完成，以排除其他模块可能带来的影响。

 

基于工作流步骤进行拆分

 

识别出用户为完成具体工作流采取的特定步骤，然后通过一些增量阶段实现工作流。如果已经能画出具体场景的流程，则可以先从工作流程拆分。该方法也叫作最简路径法，即先拆出最简路径，再基于最简路径添加步骤，直到覆盖完整路径。

 

接口可变性

 

对于需求中业务流程和逻辑规则相同，仅涉及接口不同，也就是获取数据的渠道和方式不同，我们可以基于接口的差异进行故事拆分。

　　

例如，作为微信用户，我可以添加好友以便扩大朋友圈。故事1，……我可以通过摇一摇方式添加好友……故事2，……我可以通过扫二维码方式添加好友……故事3，……我可以通过手写输入方式添加好友……

 

主要投入

 

根据主要投入或工作量来拆分故事。有时一个故事可以分为几部分,大部分的工作将用于实现第一个故事。

　　

例如，一张信用卡处理的故事：作为一个用户,我可以用维萨、万事达、大来卡或美国运通支付航班费用。这个故事可以分成四个故事，每个卡型作为一个故事。但是首先实现第一种信用卡付费的工作量最大。一旦第一种信用卡能付费，再增加其他信用卡，其工作量就小很多。所以信用卡处理基础设施应该以支持第一个故事为目的进行构建，在以后添加更多的功能则相对简单。

　　

我们只需要拆为两个用户故事：故事1，……我可以使用一种信用卡付费(维萨、万事达或美国运通中的一种)……故事2，……我可以使用所有三种信用卡付费(假定其中一种已经支持了)……这两个新的故事仍然不是独立的，但要比为每个卡型写一个故事依赖关系更清晰。

 

业务规则可变性

 

针对需求中固定的流程加载不同业务规则的情形，我们按照业务规则拆分故事。

　　

例如，作为网站用户，我希望A网站能提供热门推荐以便我可以更快找到感兴趣的内容。故事1，……能根据帖子数量给出热门频道推荐……故事2，……能根据发帖数给出热门作者推荐……故事3，……能根据回帖数量给出最多评论推荐……

 

业务操作

 

有些用户故事使用了“管理”、“控制”等词汇，它掩盖了对故事执行的多种操作，大的用户故事可以基于不同类型的操作进行故事拆分。

　　

例如，作为系统管理员，我希望能够管理使用系统的用户。通过与系统管理员沟通，了解到他希望能够增加使用系统的用户，也能够将不再使用系统的用户(如离职、更换部门等)删除，那么我们可以将用户故事拆分成下面几个更小的故事：故事1，作为系统管理员，我希望能够添加新用户，使其能够使用系统。故事2，作为系统管理员，我希望能够查询当前系统都有哪些用户。故事3，作为系统管理员，我希望能够修改用户的信息，方便我管理用户。故事4，作为系统管理员，我希望能够删除用户，保证只有必要的人在使用系统。

 

数据多样性

 

我们可以根据数据类别进行拆分。比如我的用户故事是：作为用户，我希望能够查看系统的警告通知。我们系统警告通知有很多类型，各种警告的内容差别很大，那么我们可以把这个大故事拆分成以下几个小故事：故事1，作为用户，我希望能够查看系统的异常流量警告通知;故事2，作为用户，我希望能够查看系统的恶意代码警告通知;故事3，作为用户，我希望能够查看系统的僵尸网络警告通知。

 

故事穿刺

 

故事穿刺其实就是摸着石头过河。一个故事比较大不一定因为它复杂，而是由于我们对实施知之甚少。在这种情况下,再多的讨论也不能让我们知道如何拆分它。我们可以在一定时间内针对怎么实施，先做个探针试验。试验过后，知道了深浅，揭开了面纱，我们往往就可以知道如何拆分它了。　

例如，作为用户，我可以用信用卡支付。然后，把它分成：故事1，调查信用卡数据处理机制;故事2，实施信用卡处理。

探针模式放在最后，因为它应该是你的最后手段，所以在采取探针模式之前尽量去使用前八种方式。 

 

结语

 

需要强调的是，面对庞杂的用户需求，我们在拆分用户故事时不能单纯使用一种方法，而是应该综合运用上述技巧。这些拆分方法需要多练多用，才能熟能生巧，运用之妙，存乎一心，最终达到庖丁解牛的境界。