用例在Scrum中有一席之地吗？

作者 Dan Puckett 译者 石永超 发布于 2010年11月17日

领域

过程 & 实践

主题

需求分析 ,

客户及需求 ,

用例 ,

用户故事 ,

敏捷技术 ,

Scrum ,

敏捷 ,

文档

分享到

在Scrum中，需求通常以用户故事表达。那么在Scrum中可以使用用例吗？如果可以的话，什么情况下我们应该使用用例呢？

Scott Kendrick问到：

用例在Scrum中有一席之地吗？我的直觉是，如果正确编写了用户故事，那就足以驱动讨论和协作了，同时也足以用来制定测试用例了。

首先，Scrum要求我们使用用户故事，而不要使用用例吗？Roy Morien认为不是：

Scrum没有强制任何引发诱导和记录需求的方法，除了推荐面对面的对话、日常的站立会议（当然如果你想坐下也可以）、sprint计划会议、甚至是用户故事分析，Scrum推荐的就只有协作活动和透明性了。根据这些指导原则，我想这取决于你实际想做什么。

鉴于此，在什么情况下你会想使用用户故事呢？Charles Bradley建议：

通常对于新的Scrum团队，在他们转向Scrum的头几个月，我建议他们就使用他们以前的需求搜集方法。学习Scrum时，不去学习一种全新的需求搜集方法会让学习变得非常困难。

同时Charles Bradley认为，“[……]Scrum的指导原则表明大部分Scrum团队应该使用用户故事，而对于那些要求‘任务/生命周期的行为要非常确定’的团队，可以使用用例”。Adam Sroka不同意这种方法：

传统观点认为，“关键”的应用程序需要更多文档。我认为这是不对的。关键应用程序需要的是更多（以及更好）的验证。要做到这一点，就需要详尽的自动化测试，许多做“关键”应用程序的团队都不那么做，这点我不能理解。

但是，在纯粹的功能范围外，用例文档可能会提供价值。Charles Bradley写到：

嗯，我曾经在航空领域工作过一段时间，尽管我没有完备的知识来支持这份工作（比如，什么需求必须具备这个东西），在我们从事文档工作的时候，让我记忆犹新的是，编写文档的目的不是过程审计，而是找出飞机坠毁的起因和责任方（监管部门，诉讼保护）。因此，某些必要的文档有助于（保护公司）那样的工作，而且我认为，在某些时候用例可能会比用户故事更加有助于证实你的案例（避免出错）。

像敏捷方法的所有方面一样，对于用例给组织带来的价值，应该要仔细检查。你从付出的精力中究竟得到了什么？毕竟，就像Ron Jeffreis所说的，“我还没有碰到过很多实际的人，真正善于编写用例。”如果你承认你可能不擅长编写用例，那么有什么事情是你一直在做的，能给你的组织带来更多价值？

查看英文原文：Do Use Case Have a Place In Scrum?

译者 石永超 是Irdeto BSS软件工程师，CSM，敏捷爱好者，《User Stories Applied中文版》译者之一。