S02E16 Use case or User story (下)
欢迎收听PM网事，今天我们来聊用例和用户故事的下半部分。
上半部分我们聊到了Mike Cohn指出的User story的8个优点中的前4个优点，今天我们继续剩下的内容。
我们开始第5个优点：鼓励延迟细节。
这确实是User story的一个优点，User story会更快速地进入开发状态，而不会在建模上花费时间和精力。
第6：支持随机应变的开发。
Mike Cohn认为，写下一个系统的所有需求，然后从上往下想出解决方案，从来就是一个美丽的陷阱，他引用了其他人的看法来证明他的观点，主要有5点：
第1点：用户及客户通常都不会准确地知道自己的实际需求。
第2点：即便软件开发者知道所有的需求，很多需求细节只能随着他们的开发进展变得清晰。
第3点：就算假设所有的细节可以在前面弄清楚，人们也没有能力理解这么多的细节。
第4点：就算我们真的能理解所有的细节，产品和项目也会经常变更。
最后一点：人非圣贤，孰能无过。
看完了这一段，我想我马上就理解了Mike Cohn的痛点，也就是敏捷之所以强调随机应变开发的重要原因，那就是问题的根本其实是项目层面的问题，而不是软件开发的问题，在项目层面的问题得不到解决的情况下，软件行业只好用自己的方法来解决这一问题，那就是随机应变的开发，换句话讲，敏捷是被逼出来的。但是，我必须要说，软件开发是最不应该随机应变的。
从上面提到的问题来看，在软件工程层面解决问题的方法有两个，一个是用一套严谨的软件工程方法管理需求，让项目的利益相关方弄清楚需求，从而在源头堵住不靠谱的需求，减少不必要的变更，实现真正的精益，这属于软件工程层面的治本，另一个方法就是退而求其次，不得不拥抱变化，用灵活轻量级的方式来实现随机应变的开发，实现表面的精益，这属于治标。从目前来看，敏捷采用了第2种方法，那用第1种方法是否可能呢？我认为完全有可能，但前提是和项目管理相结合。那在软件工程层面第1种方式是什么呢？那就是我们可以借鉴RUP的做法，用经过剪裁的RUP方法，也就是一个适度轻量化的方法来实现，这样的话，就可能从根本上解决我们的痛点。换句话讲，Use case和UML其实可以起到更加积极有效的作用。
所以，站在这个角度来讲，我既认同也不认同Mike Cohn认为User story可以支持随机应变开发的优点。
第7：鼓励参与性设计。
所谓参与性设计，就是需求过程需要足够有趣，可以吸引软件的客户和用户积极参与，Mike Cohn认为，User story足够简单有趣，而且涉及不到任何技术术语，所以会让参与者比较好地融入其中。对于这一点，我非常认同。但是，Mike Cohn同时也指出了Use case的不足，那就是Use case里会涉及到技术术语，而且需要了解用例的格式，一些常见字段也需要了解，例如什么是前置条件、什么是基本流、什么是备选流等等。
说到这里，我就更搞不懂了，Use case是有不同类型的，也就是有不同的stereotype，一种是Business Use case，也就是业务用例，另一种就是System Use case，也就是系统用例，业务用例的写法和系统用例是不一样的，业务用例聚焦业务，不会涉及技术术语，系统用例聚焦技术设计和实现，会在一定程度上涉及技术术语。
用Use case怎么做需求呢？大致的过程是这样的，首先是业务建模，也就是让需求提供方写业务用例，当然这个过程也会输出业务用例图、业务活动图、业务实体等，这个过程完全不涉及任何技术层面的问题，只是用Use case和UML里面的少数图形来描述需求，这个过程完成后，会有一个重要的步骤，那就是把业务模型转换为系统模型，转换为系统模型后，软件团队开始进行系统建模，这一步才会涉及到技术方面的内容，用户界面的细节有可能会在这个阶段冒出来。另外，业务模型转换到系统模型的过程也不需要需求方操作，需求方只需要告诉软件团队哪些业务用例需要实现，这样，软件系统的边界其实也就确定了。
所以，在业务建模阶段，根本不涉及任何技术术语，而且建模的过程也是一个有趣的过程，因为里面会有一些图形，画图的过程是一个充满乐趣和成就感的过程。最重要的是，需求方提出需求的时候，业务建模过程换了一种方式和角度让需求方重新审视自己提出的需求，在业务建模过程中，因为Business Use case的存在和可视化的图形，让原本逻辑混乱、模糊、关系复杂的需求开始变得清晰，这样就潜移默化地让需求方自己主动发现一些之前没有考虑清楚的地方，一句话，你不刺激他，他就要刺激你，你不让他拥抱变化，他就要让你拥抱变化。
当然，Use case确实需要一点时间来学习，但是和在项目过程中不得不频繁拥抱变化所花费的时间相比，实在是不值一提，如果你真的可以做到这一步，那我恭喜你，你应该已经实现了软件工程层面的精益。
第8：传播隐性知识。
关于什么是传播隐性知识，Mike Cohn并没有举例说明，而是一笔带过，所以我也不知道他说的是什么隐性知识，只好不做评价了。
以上就是Mike Cohn所提到的User story的优点，当然，他也提到了User story的3个缺点：
第1个缺点：在拥有大量用户故事的大型项目中，故事之间的关系可能错综复杂，难以捉摸。
第2个缺点：如果开发过程规定要有需求的可追溯性，必然离不开额外的文档。
第3个缺点：虽然故事在一个团队内部能大大促进隐性知识的积累，但还是不适用于特大规模多团队的结构。
第1个缺点和第2个缺点，我认同，第3个缺点，我无法做出评价。
另外，Mike Cohn还提到了Use case和User story的区别：
第1个区别：范围。Mike Cohn提到，两者的大小都以交付商业价值为目标，但User story的范围更小，因为受到了限制，以便于安排工作。而Use case覆盖的范围通常都比User story要大。
第2个区别：完整性。Mike Cohn提到，User story加上验收测试基本相当于Use case。也就是说，Use case的完整性更高。
第3个区别：寿命。Mike Cohn提到，Use case常常作为永久性的工件持续存在，而User story不会超过包含它们的迭代周期，虽然卡片可以保存，但很多团队选择了撕掉。
第4个区别：Mike Cohn提到，Use case比较容易包括用户界面的细节。
第5个区别：使用的目的不同。Use case编写成客户和开发人员都可以接受的格式，这样所有人都可以读懂而且可以达成一致，目的是记录客户和开发团队之间的协议。而User story是为了更方便地制定发布计划和迭代计划，并可以充当用户具体需求对话的占位符。
第6个区别：Mike Cohn提到，Use case一般写成分析活动的结果，User story则写成注释，用以启动分析谈话。
以上6个区别，除了第4个区别，也就是用户界面的细节我不完全认同之外，其余的区别我认同。
说了这么多，我们再提高一个层面来看Use case和User story吧。
Use case和User story都是软件需求管理的工具和方法，对于Use case和User story的对比其实会不可避免地涉及到RUP和Scrum的对比，RUP是一个重量级的、严谨的、有效的、迭代的软件过程方法，之前一直用在传统IT行业，我认为，如果你用了这套方法，通常情况下没有什么需求是搞不定的。而Scrum在很多方面和RUP非常的不同，目前主要用在互联网行业，我们都知道，互联网行业和传统IT是有很大不同的，我们在互联网行业毫无疑问需要比过去更加敏捷，但应该怎么敏捷，可能是一个见仁见智的问题。或许在敏捷现有的多个流派里，还应该再增加一个经过剪裁的RUP，这可能会更加丰富我们的管理和交付手段，毕竟，我们在之前的节目中就曾经提过，互联网的下半场是2B，在2B的环境下，我们的管理方法和软件的交付手段和2C可能是截然不同的，就目前来看，如果不对周围的环境做出大的改变，Scrum想要满足2B的要求，可能有不小的难度。
说到这里，问题依然摆在我们面前，那就是我们在互联网行业的项目里，涉及到软件这一部分到底应该用Use case还是用User story？现实情况是User story相对比较普遍，这样吧，我来打个比方。
假定我们现在要去野外生存，我们只能从下面两个工具中选一个带上，第一个工具是一把普通的水果刀，上面有一把刀、一个瓶起子，这个工具很轻便，方便携带。而另一个工具是一把全功能的瑞士军刀，钳子、剪刀、改锥、镊子一应俱全，甚至于它还配了一个放大镜。这把军刀体积比较大，也比较沉，不太方便携带，甚至于里面有的工具我们还不会用，那我就问你了，如果要去野外生存，让你来挑工具，你会带上哪一个？
我不知道你的答案是什么，我的答案是：带哪一个需要根据野外生存的情况来定，如果只是在郊区的树林里住一个晚上，我毫无疑问会选那把水果刀，如果野外生存玩儿真的，而且需要几天的时间，那我一定会选择那把瑞士军刀。如果不知道野外生存到底在哪里，也不知道要多长时间，我想，我还是会选那把瑞士军刀。你会怎么选呢？
在这期节目的最后，再说一句，据说，只是据说，Alistair Cockburn，也就是User story这个概念的提出者，他，更喜欢用瑞士军刀。
好了，今天我们就聊到这里，我们下期节目见。