今天爱学习的阿汪分享他对于user story及story point的理解，阿汪说：“story point表面看是估算工作量，但背后其实是反映了任务的不确定性。估10以内的时候，通常都是心里有数知道怎么做。一旦估到13，20，说明这个任务有点复杂，有些实现还不太确定。所以我宁愿看到5和8两个story，也不愿意看到一个13的story。” Bingo！阿汪理解story point的真谛了。在story point的概念里，5+8 并不等于13。 当user story估算成13时，意味着实际可能是13，15或者其他。当user story估算成20时，意味着实际可能是21，25或者其他。point越大估算多几点或者少几点越没那么重要，反正越大越不确定，怎么估都是不准的。
但阿光又被资深开发阿当问到一个直击灵魂的问题：“user story为什么一定要拆小？”
阿当举了个简单的例子 “一个需求：要求从公司到天津站取一箱呀土豆，并在一定时间返回公司。能拆分成我到西南角几个point，从西南角到公司再几个point吗？有些功能就是一个整体，只有把所有功能都完成，才可以有交付，那还用那么多时间去拆干嘛。”
其实这里有两个问题： 1 user story为什么要拆？ 2 一个整体功能怎么拆？
我们先说第一个问题：“反正一个迭代内可以交付，为什么还要花那个精力去拆story？“ 就拿这个例子：”一个需求：要求从公司到天津站取一箱呀土豆，并在一定时间返回公司。“ 如果不拆...
场景一：
迭代结束，开发信心满满地做完给PO验收。
PO：“嗯？你为什么要到西南角坐地铁？我觉得应该是打车啊？”
阿当：“那你需求没写清楚啊。” 不欢而散。 ---- 需求不明确
场景二：
迭代期间，这次开发了解到PO希望打车到天津站。
不过开发发现打出租车太难，需要下载滴滴打车，但需要拿身份证实名认证，可惜身份证在老家，家里现在又没人，严重影响开发进度。
迭代结束没有完成commitment，不欢而散。 ---- 未识别出依赖
场景三：
开发这次知道PO要求打车到天津站，并且sprint开始前已经把身份证准备好。
不过开发过程中，到了天津站取呀土豆时才发现忘了带订单，订单在公司财务处，还需要返回公司拿到订单再去取，开发进度严重滞后。
迭代结束没有完成commitment，不欢而散。 ---- 设计没做好，估算不准确
看吧，story太大，至少可能会发生：需求不明确，未识别出依赖，估算不准确 这些问题。这些都可能导致团队在迭代结束无法完成最初的commitment，虽然这是团队和PO都不希望看到的结果。
再说下一个问题：一个整体功能怎么拆？ 这就得看user story的价值了。每个user story都应该是对用户或客户有价值的。所以想必敏捷专家们看我上面的例子肯定有想打人的冲动，因为上面的例子没有体现出业务价值。 一个典型的user story格式应该是： As ...， I want ... ， so that ... 比如：As老板，I want让公司某同事去天津站帮我取一箱呀土豆，当天下午带回公司并分享给全组成员，so that提升团队幸福感，忠诚度。 那么这个story该怎么拆？
看起来这是一个完整的流程每个步骤缺一不可，既然价值为导向，可不可以换个思路，比如切分成：
1 As老板，I want 让公司某同事今天去天津站帮我取一箱呀土豆， so that 为分享给全组成员提升团队幸福感做准备。
2 As老板，I want 让公司另一同事通知全体成员即将分发呀土豆，敬请期待， so that团队成员对即将到来的零食充满期待，延迟满足感，增加茶余饭后闲聊话题，顺便达到宣传效果。
3 As老板，I want 让公司同事把呀土豆带回公司并分给同事， so that提升团队幸福感，忠诚度。
或者也许团队会根据业务价值及研发成本直接建议修改story成：
As老板，I want 让快递公司今天帮我取一份呀土豆回公司分享，so that 提升团队幸福感，忠诚度。
或者修改成：
As老板，I want 从京东买箱呀土豆快递到公司，so that 提升团队幸福感，忠诚度。
或者PO及团队共同讨论出大家共同认为最有效提升业务价值的方式：
As老板，I want 请大家今晚在公司附近吃顿大餐，so that 提升团队幸福感，忠诚度。（坏笑的表情）
希望这些小例子可以有所启发，不过User story怎么拆是一个很大的话题，有很多拆分的种类，我们慢慢来共同学习，敬请期待下回分解！
网友评论