S02E15 Use case or User story (上)
欢迎大家收听PM网事，今天我们来聊一个偏技术一点儿的话题，那就是用例和用户故事。因为这个话题比较大，所以这个话题将分为两期来聊，今天我们聊上半部分。
听了PM网事全本的同仁们应该都还记得，我们在PM网事第一季里聊过一期敏捷，在第二季的一开篇又聊了一期需求，里面提了一句Use case和User story，今天，我们来稍微深入一下，更进一步，我们还想试着得出一个更深入的结论，那就是在互联网这样一个大环境下，到底是Use case更适用还是User story更适合。
我先说我的看法，可能措辞不太严谨，但意思是清楚的：那就是Use case和User story都是软件需求的管理方法，适用于不同的软件环境，Use case和User story之不同，其实是应用场景上的不同，一个是重量级的、应对大规模和复杂软件开发的重量级过程，另一个，是针对小团队、灵活的轻量化过程。
在展开正式的评论前，我还是照例先做一个声明，我尊重并且感谢敏捷社区给我们带来的不同的理念和实践，我想，我们发表各自观点的目的都是为了促进互联网行业的创业者和从业者们取得更大的成功。
先来分头说一下Use case和User story的大致诞生过程吧。
在1992年，Ivar Jacobson发布了一部著作，著作的名字翻译成中文叫做《面向对象软件工程：用例驱动方法》，Use case从此诞生。除了发明Use case，Ivar Jacobson还发明了UML（统一建模语言）、OOP（面向对象编程）和RUP（Rational统一过程）。
再来说说User story，User story和克莱斯勒汽车公司之间是有一定关系的。当年，克莱斯勒汽车公司发起了一个C3项目，并在1996年邀请了Kent Beck加入项目负责系统的性能调优，但到了后来，Kent Beck成了项目负责人，因为感觉项目过程有问题，所以Kent Beck就开始和Ward Cunningham对项目过程进行改进，再后来，Kent Beck邀请了Ron Jeffries加入团队。在1998年，Alistair Cockburn到底特律参观了C3项目，并且第一次提出了User story的概念，在1999年，XP也就是极限编程诞生，2000年，克莱斯勒取消了C3项目，2001年，Ron Jeffries提出了User story的3C原则。再往后，随着Scrum的推行，User story开始被更加广泛地接受。
我们来说一下User story的优缺点吧。 Mike Cohn在他的著作《用户故事与敏捷方法》里提到，User story有下面8个优点：
第1：强调口头沟通。
第2：人人都可以理解。
第3：大小适合做计划。
第4：适合于迭代开发。
第5：鼓励延迟细节。
第6：支持随机应变的开发。
第7：鼓励参与性设计。
第8：传播隐性知识。
我们挨着个儿来过一遍吧，首先看第1个，强调口头沟通。
看过Mike Cohn写的《用户故事与敏捷方法》这本书的同仁们应该都有印象，Mike Cohn认为User story强调口头沟通是个优点，是因为写在文档里的需求描述容易有歧义，如果想要写的没有歧义，就需要写的非常详细，而且他也认为世界上不存在完美无缺的文档，与其花大量的时间写文档，不如直接和客户沟通。看来，User story之所以被设计的如此简单，就是为了少写文档，并且强迫口头沟通。
对于Mike Cohn的这个观点，我部分认同，因为如果想要把需求写的没有歧义，确实需要写的非常详细，而且口头沟通也确实是必不可少的，但是我认为，哪怕口头沟通再重要、写需求再耗费时间，用文档的形式记录需求是不可动摇的，哪怕是在互联网行业。
我们在PM网事第一季讲敏捷那期节目里就提到过，互联网组织的沟通渠道呈网状，加上变更频繁、迭代频繁，所以沟通成本很高，另外，通过口头语言沟通和传递信息很容易造成失真，而且人的记忆力是有限的，有多少人能记住那么多业务逻辑里的每一个细节呢？只要有一点误解和遗漏，就最终会导致出现问题，轻则产生Bug，重则延误项目产生不良后果。另外，需求写下来确实花时间，但只要清楚地写一次，就可以保证项目范围内相关方对需求的理解趋向于一致，这样可以极大地提升效率、保证质量、降低风险。
另外需求写成文档还有一个作用，在第一季敏捷那期节目里也提过，那就是可以强迫需求的编写者和阅读者进入深度思考的模式，一个需求用嘴说出来进入耳朵经常是不太经大脑的，而如果需求写在纸上，就会严谨的多，尤其是按照模版写那就更能保证需求的质量了。所以，如果我们要是有一个不太靠谱的需求方，从他那里得到靠谱需求的做法绝不是听他说，而是让他写下来，这种做法是经过实践检验确认有效的。
所以，强调口头沟通是User story的优点我基本不认同。
再来看第2个优点：人人都可以理解。
从简单程度上来看，User story确实够简单，无论相关方懂不懂建模和编程语言，确实都容易理解。
但是，作为一种需求工具，人人都可以理解重要吗？当然重要，但是我认为更加重要的是：需求可以准确的描述和理解。而User story的形式过于简单，很难准确描述需求。
第3个优点：大小适合做计划。
因为敏捷要求短迭代周期，所以要求需求工具应该有更小的粒度，User story确实在这方面有一定的优势。但是Mike Cohn还特别提到，Use case的问题在于粒度太大，在做计划时会遇到优先级不好确定的情况。对于Mike Cohn的这一看法，我有不同的意见。
确实Use case的粒度相对User story来讲偏大，但是Use case具有很高的伸缩性，比如说，我们在学习如何写Use case的时候，通常会遇到一个很经典的问题，那就是一个CRUD到底是写成1个Use case还是写成4个，这个问题其实没有标准答案，因为既可以写成1个，也可以写成4个，站在容易管理的角度来看，可以写成1个，如果要缩小Use case的话，可以写成4个。另外，1个Use case包括1个基本流和0到多个备选流，如果要做开发计划，完全可以在这个迭代周期里先做基本流，下一个迭代周期做其中一个备选流，再下一个迭代周期可以做剩下的备选流，总之方式方法灵活多样，而且经过实践检验这样做是没有问题的。
再有，如果要便于做计划，就必然要求准确估算工期而且还要明确任务间的逻辑关系。先说估算工期，因为Use case更能表现清晰的需求，所以Use case其实更能做到相对准确地估算工期。另外，因为需求之间经常有关系，而Use case是可以定义Use case之间关系的，比如：Use case之间既可以是独立的，也支持包含、扩展和泛化等关系，所以Use case相比User story更方便制定计划。
第4：适合于迭代开发。
Mike Cohn特别提到，在迭代开发里User story具有很明显的优势，因为在开始编码前，并不需要写出所有用户故事，可以只写出一部分就开始编码测试，也可以一开始写的比较简单然后再渐进明细，然后再按照需要的节奏进行迭代开发，非常灵活，事实确实如此。但是Mike Cohn也承认，Use case同样可以满足上面所说的要求，但是他认为，Use case有标准模版，所以很容易让人觉得写Use case的时候是在填空而感觉受到了压迫，他提到Martin Fowler把这种现象称为‘完整主义’。
确实，对于大牛来讲，按照模版写需求确实备受压迫，但是对于绝大多数写需求的人来讲，他们根本就和大牛扯不上边好吗？
模版的真正作用是什么？当我刚一开始进入IT行业写代码的时候，我也烦模版，觉得模版就是没事儿找事儿，但随着工作经验的积累，我终于在某一天开了窍，明白了模版的真实作用，在这里我就说一个，那就是保证文档内容的完整性、合理性。
就拿Use case来讲，我们都知道一个标准的Use case包含这样一些内容，有用例名称、简要说明、前置条件、后置条件、基本流、备选流、特殊需求、扩展点等。这说明什么？这意味着我们在按照Use case写需求的时候，在写下需求的此时此刻，我们必须考虑并且弄清楚上面的这些内容，这些内容经过仔细的分析和思考之后如果判定不涉及，那就可以不用写，但是上面这些内容我们是必须要考虑的，如果不考虑就可能会产生不完整或者是不合理的需求，这些不完整或者是不合理的需求都会转变为后续项目过程中的变更或者是Bug，然后我们就会说变化太多，要拥抱变化等等，但实际上大家心里都明白，很多所谓的变化不就是我们自己的失误导致的吗？举个例子，我们现在要分析一个用户登录注册的需求，假定模版里没有特殊需求这一项，我们就会写出来一个比较完备的功能性需求，我们就会觉得需求已经比较完善了，但是，如果我们的模版里有特殊需求这一项，而且在这一项下面还有一行提示性的文字，比如说：特殊需求包含但不限于安全、性能、存储、发布、维护、易用性等需求。那当我们看到这里的时候，我们会突然想到，我们想的可能太简单了，在登录的时候是否要保证一定的性能呢？是不是要考虑到安全方面的问题呢？用户在注册时上传的一些图片是否要考虑额外的存储呢？等等等等，这一点，我在PM网事第二季第一期讲需求那期节目里就已经提到了。所以，如果我们有模版，我们会有更大的概率写出高质量的需求。而不是感觉到受压迫，如果一个小小的模版都能让你感觉到受了压迫，说老实话，你那脆弱的心理还真不适合在这个行业里做，我建议你趁早转行。
另外，让我感到很奇怪的一点是，Use case众多优点中的一个就是适合迭代开发啊，就拿RUP来说，RUP就是一个集成了Use case、UML这样的一个迭代化的软件过程，非常之强大，这一点连我都知道，软件工程界的大牛们会不知道吗？真的很奇怪！我想，Ivar Jacobson可能会很郁闷吧。
好了，因为时间的限制，今天我们就聊到这里，我们下期节目见。