Agile 101: User Story & Prioritization

通常人们会将User Story和Use Case放在一起比较，虽然二者在形式上具有一定相似性，但是究其本质来说，还是天渊之别的。这一点，专业BA李默同学总结的格外准确：“用户故事是可见的商业价值，而不是功能描述”。想要更好的理解这句话，需要了解什么是好的用户故事。好的用户故事，可用INVEST原则来概括：

I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable

我个人觉得，这个总结虽好，但不免分散注意。要我说，想把握好User Story，只用把握两个就够了Negotiable和Valuable。那么首先要确定什么是Negotiable的。User Story有一个流传广泛的书写形式：

As <role>, I'd like to <action>, so that <benifit/value/goal>.

为了更好的获取story还有很多最佳实践，比如personas, 比如business process modeling，其实这些全是糖衣炮弹，As, I'd like to都是噱头，就是为了把用户忽悠晕了，然后图穷匕现直取商业价值和目标。一旦商业价值确定下来，role, action都是可以negotiable。比如李默之前在文章里举的用户登录的例子，输不输用户明密码？可以商量嘛！是不是只有注册用户可以享受个性服务？可以商量嘛！关键是用户想要什么，至于怎么实现这些到头来都是可以商量的，都是Negotiable。只有客户的商业价值是不能商量的，也没的商量。价值没有了，目标不存在了，这个User Story也就没用了，商量啥？重写一张就好了。

因此user story又有另外一个名称，叫requirement placeholder。就是客户价值的"立此存照"。至于具体需求，那么就到iteration plan meeting上是商量吧，看看当时什么样的形式（功能）才是最符合用户需要。到此，其实大家可以看出来了，user story重点就不再How上，而是在Why上的。有了why，且可Negotiable，把握了精神，你就是按用例来写需求又有何妨涅？

有了valuable和negotiable的想法垫底，在看看基于user story的初步计划制定——也就是有名的prioritization——就容易理解多了。用户根据每张卡的价值，自行比较作出决定，大体场景就跟向神仙许愿一样。

神仙：我可以满足你一个愿望。
我：我要荣华富贵！！！
神仙：哦，荣华富贵，那么要不要爱情涅？
我：恩，这个...那我要忠贞的爱情好了！！
神仙：哦，忠贞的爱情，那么要不要健康平安呢？
我：呃....
repeat 无数次，最终我要了一件过冬的皮猴...

这篇文章是我最近看到的最好的一篇，奇怪的是，Rx的另外一篇文章反而更热

可能是因为这篇和developer的工作相距较远。 这是俺的业务范围吖

好帖！

另外，想请教raimundox，上面的E - Estimable 如何理解比较好呢？

Estimatable - 是可以估計的意思

開發人員需要能估計到一個 user story 大概要多少時間去完成.

例如: "求職者能找到工作"...這太大了, 很難估計的.

其他的情況可能會是開發人員對於用戶寫的東西不明白...寫醫療系統時對於醫療用語和運作不明白....又或者是技術上的問題, CORBA, REST, 等技術, 不是每個開發人員都一定會明白的, 更何況要估計呢

PS: to raimundox: 小弟覺得 INVEST 都同樣重要呢.... 特別不要忽視 Testable 的重要性, 用戶要知道開發人員如何測試, 開發人員也要知道如何叫完成任務的呢

raimundox真幽默。
“我”最终还是认清了自我。皮猴也许就是最后的Simple design......