BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

正确设定用户故事的大小

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 李剑 关注 1 他的粉丝 发布于 2008年2月12日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
资深的敏捷实践者都会知道,敏捷过程中最困难的部分之一就是如何正确地编写用户故事。最近,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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

太棒了 by Tong James

这一直是我想不明白的一个问题

Re: 太棒了 by Jacky Li

在ScrumAlliance上还有一篇佳文:
www.scrumalliance.org/articles/87-writing-the-p...

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT