提示：本文共有 3895 个字，阅读大概需要 8 分钟。
User stories emphasize verbal communication. Written language is often very imprecise, and there’s no guarantee that a customer and developer will interpret a statement in the same way... We act as though written words are precise, yet they often aren’t.a. 用户故事比用例更适合口头交流？Cohn 说由于用户故事更强调口头交流，所以比用例更有优势？这个理由其实并不充分。根据我十多年的行业企业用例教学经验，其实用例文本能够比故事更好地促进用户和开发者之间的沟通。我们应该拿什么、怎么去和客户沟通需求？是用一种简单的只有寥寥几笔的故事卡片好呢，还是用有更多书面细节和生动图形展示的用例模型更好？用例提供了规范的需求模板和编写规则，有了这些结构化的、详细的模板字段、规则和技巧建议，开发者和客户就能有的放矢，更加系统地、更好地进行沟通，达成一致意见，消除需求的模糊性，促进需求的尽快稳定和收敛。相反，在促进需求沟通方面，故事所能提供的建议内容太少。事实是，有了更加完善的需求模板和需求脚本的支持，用例比用户故事能更加有效地提高口头交流需求的质量和效率。b. 口头交流比文字描述需求更准确？Cohn 说，文本语言往往很不准确，我们无法永远保证客户和开发者对一个句子有相同的理解。的确，文本描述很可能不准确，存在多义性。所以，需求文本需要用户评审，需要通过测试和实际使用来验证。可是难道口头交流就比文本描述更准确？意思表达不准确的问题，其实口头交流也存在。事实上，软件工程的实践表明，口头约定比文本约定的问题更大，文字交流比口头交流更可靠。造成需求描述不准确的原因，其实主要并不在于沟通形式是口头还是文字，关键是因为人们采用了自然语言！人类自然语言的天生缺陷，造成表意不精准，存在多义性，这是一种客观现象。如何才能尽量避免用自然语言描述需求的天生缺点？答案是：只能用更加科学、系统和规范的办法，比如形式化方法。显然，形式化或半形式化的需求描述方法比口头交流需求更精准。而用例模板语言正是一种介于完全形式化和非结构化自然语言之间的一种半形式方法，在需求语义的精准性和可读性之间作出了很好的权衡。俗话说：细节决定成败。用户故事不留详细的书面需求文档，只提倡口头沟通和完备测试，对于国内外的许多项目而言其实是一个很大的风险和质量缺陷。小结事实是，文本用例需求比强调口头交流的用户故事内容更准确、更丰富，能更好地促进与客户沟通需求，并能有效提高测试编写的效率和质量。2、用户故事更便于项目计划A second advantage of user stories is that they can be used readily in project planning. User stories are written so that each can be given an estimate of how difficult or time–consuming it will be to develop; use cases, on the other hand, are generally too large to be given useful estimates. Also, a story is implemented all in a single iteration of an agile project, while it’s common to split a use case across multiple iterations even though those iterations are usually longer than on a story–driven project.a. 用例不适合项目计划和估算？Cohn 认为用户故事通常比用例的粒度更小，可以在一个迭代中实现，所以做项目计划时用故事来估算、排序更方便。那么，是否用例就不适合做项目计划和估算了？非也。用例与故事的关系，其实就像一棵树与树枝，或树干与树叶的关系。用例充当容器把各种琐碎的用户故事拼接起来，可以让我们看到整个系统需求的全貌。每一个用例是对用户真正有价值的需求单元，粒度通常比故事大，导致用例需求的总数比故事的数量少，这样更便于我们在做项目计划时把握系统的全局，而不是只见树叶不见森林。Cohn 说“use cases are generally too large to be given useful estimates.” 因为用例太大了，所以通常不能给出有用的估算？非也。Cohn 忽略了用例的切分。用例估算的正确做法是，分而治之，把用例分解为更小的需求单元进行估算。用例的分解可以有多种方式，既可以分解为用户故事，也可以分解为情节（Scenario）、块（Block）、特性（Feature）等等。把一个用例所含所有需求块的估算结果累加起来，就可以得到用例估算。在利用粒度更小的需求单元做估算这点上，用例估算与用户故事估算这两种方法的主张其实是一致的。区别主要在于，在需求细节的内容描述上，用例比故事的要求更多。用例模板提供了更多的需求细节（基本流、扩展流等），便于我们得出比故事更准确的估算。b. 故事更适合估算？Cohn 说“User stories are written so that each can be given an estimate of how difficult or time–consuming it will be to develop”。他的意思是，针对每个故事，（相比用例）我们更容易估算出它的开发难度和用时。然而，仅靠如此简单的一张故事卡片，书面信息太少，这样的估算可靠吗？估算的一个基本规律是，掌握的有效信息越多，估算的准确性通常就越高。故事估算的主要缺点在于，由于故事卡片本身缺少大量的需求细节信息，缺乏需求的完整性，很容易让人忽视各种潜在的技术风险，造成估算不准，预测的结果往往偏乐观。有人可能会辩解说，故事估算当然不是仅仅靠故事卡片，提高故事估算可靠性的办法是：与用户口头交流，以及针对每个故事编写全面的测试，三者结合（即 3C）就能获得可靠的估算。这有一定道理。但前面我们讨论过，其实借助文本用例模板更有利于需求的口头交流，同时有了大量需求扩展流、特殊情况等重要信息的书面记载，也便于我们写出更好更完善的测例（Test Cases）。从需求用例到测例，是一个很自然的思考分析过程。在故事估算的过程中，适当编写每个关键故事所对应的文本用例，反而更有利于提高估算的整体可靠性。一个有趣的问题是，用户故事方法为什么始终要回避强调书面记录重要的需求细节这件事情呢？小结事实是，用例比用户故事更适合做项目计划和估算。故事的粒度通常比用例小，这其实并不是优势，因为用例同样可以分解成更小的合适单元以用于项目计划和估算。3、用户故事鼓励团队推迟收集需求细节，迅速启动开发。User stories encourage the team to defer collecting details. An initial place–holding goal–level story “A Recruiter can post a new job opening” can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time–constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830–style software requirements specification.Cohn 认为，故事方法鼓励团队推迟收集需求的细节，先用具有占位器功能的目标层故事描述简略的需求，迅速投入开发，然后在适当、必要的时候再补充更多的故事和需求细节。因此，故事非常适合（perfectly）进度紧张的项目。Cohn 没有提及 UML 用例图。其实画用例图比写用户故事卡片更简单，用例图中的每个用例也同样起到了占位器的作用，而用例边界图更好地反映了系统功能的全局视图，所以用例同样可以，甚至比用户故事更好地促进进度紧张项目的敏捷开发。小结事实是，用例图比用户故事更简单、更敏捷，能更好地促进团队推迟描述需求的细节，迅速启动开发。此外，用例图还提供了系统需求的全局视图，这是故事所没有的。
看到此处说明本文对你还是有帮助的，关于“UseCase over UserStory”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
