资深的敏捷实践者都会知道，敏捷过程中最困难的部分之一就是如何正确地编写用户故事。最近， Pat Kua 解答了一个核心问题：故事里应该放入多少细节？
用户故事是敏捷项目中轻量级需求的表达形式，用来取代传统项目中长长的用例。面面俱到的用例并不易于适应客户需求的变更。而作为替代，用户故事提供 了恰好够用的信息来开始开发人员与产品拥有者（Product Owner）之间的对话。它同时也是可以为最终用户提供价值的最小的功能片段。下面是来自 Mike Cohn 的用户故事表述需求的 27 条优势一文中的几个例子：
- 用户可以在网站上张贴简历。
- 用户可以搜索工作机会。
- 公司可以发布新的工作机会。
- 用户可以限定谁可以看到她的简历。
用 Bill Wake 发明的助记词来形容就是，我们为优秀的故事投入时间和精力（INVEST）：它们是独立的（ Independent），可以磋商的（Negotiable），有价值的（Valuable），可以估算的（Estimable），短小（Small）而且可以测试（Testable）。
按照 Patrick 的说法，知道故事里需要编写多少细节、何时编写这些细节以后，就掌握了编写用户故事的诀窍。如果像用例那样早早就写下太多细节，一个故事在被实现之前就会被重写很多次了。如果写的细节太少，那开发人员就无从计划、无从下手实现。 Patrick 说道：
对于那些需要被立刻实现的故事，你就应该提供足够的信息以供开发人员和测试人员明晰需求所用。因为没有足够的细节而造成的浪费肯定会在后续的活动中不断地重现。
……对那些在遥远的将来才会被实现的故事，就不需要同样丰富的细节了。在早期捕获过多细节所造成的浪费必将在分析层面上持续上演。
所以，答案就是视情况而定：故事离你越远，它的细节就应该越少。只有那些即将进行处理的故事才应该拥有测试用例和相关细节。
在 Pat Kua 的站点上有故事里应该放入多少细节这篇文章的全文。
查看英文原文： Right-Size Your User Stories
评论