《用户故事与敏捷方法》｜优秀的用户故事有哪些特点？

麦克·科恩品卷一族

2024-12-10

您收听的内容是我们对知识的提炼与再加工，如果你想全面了解书中内容，可以购买此书原版。与本书相关部分书籍的音频链接在文章的尾部，如有兴趣，敬请点击收听。

核心书摘

《用户故事与敏捷方法》从根本观念入手，说明了我们理解的用户需求与用户真实诉求之间的距离，介绍了管理模式的革新，提供了一种高效灵活、完美兑现用户需求的项目管理模式——“用户故事”与“敏捷方法”。本书还结合了真实的案例，详细阐释了这种项目管理模式的概念、意义、目的、实现方法、适用范围、常见问题和优缺点。

适合谁读

· 创业者

· 企业高管

· 开发人员

关于作者

麦克·科恩，敏捷联盟的发起成员之一，Mountain Goat Software公司的创始人，Fast401k的软件工程副总裁，被软件开发界称为“敏捷方法”大师。他1984年开始编程，1988年开始管理软件项目，拥有超过20年的行业经验，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行等知名公司。

学什么？如何满足用户真实需求

人们常常遇到这样的情况：明明做过了市场调研，却发现根据用户反馈的结果所开发出的产品依然与用户的要求相去甚远；眼看APP产品已经在准备更新迭代了，却总是找不到正确的方向；团队很庞大，大家每天都忙得团团转，但就是高效不起来。

本书指出，这种情况其实与用户需求和管理模式有关。传统意义上的用户需求是经过我们再理解的用户诉求。再理解的过程由于语言表意的局限性，往往容易造成双方的误会。而“用户故事”却不一样，它是用户用自己的语言讲述的需求。本书还提出了“敏捷方法”这一高效、灵活、精确的管理模式，它可以完美实现用户需求，解决因与客户沟通的不足与误会而造成的问题。

你还会发现

· “3C方法”是什么；

· 讲述用户故事需要注意什么；

· 怎样理解管理上的“二八法则”。

一、结果偏差常常是因为误会造成的

和用户沟通真不是一件容易的事情，各行各业接触客户和用户的人，往往都会有一些“痛苦”的经验。不必说公文往来造成的各种歧义，就是面对面语言交流，也往往造成误会。

作者在书中讲了一个小孩子洗澡的故事，对记录语言的不精确性造成的项目失败作了生动的说明。一个父亲在浴缸里放满了水，准备让自己的小女儿洗澡，只见这个两三岁的小女孩儿先用脚趾头试了试水温，然后告诉她爸爸：“Make it warmer”，意思是：“水要暖点”。

这个父亲很细心，听了女儿的话，把手伸进水里试了试，这一试，竟然发现水已经很热了，比以往她女儿习惯的水温还要高。父亲此时突然领悟了一个道理，原来女儿的“暖点”和自己理解的“暖点”完全是两个意思，一个成人听到“水要暖点”，当然会理解为“让水更热一点”，但是女儿的意思却是：“水太热了，我不要热水，我要温和一点的水”。

有时候，我们遇到的客户、用户就像这个故事中的女儿一样。他们并不是对这个行业缺乏了解，不是智商或者逻辑有问题，也不是因为某种原因故意要设置障碍，而仅仅是因为语言表意的局限性造成了误会。如果这种歧义出现在某个开发文档中，而且不幸又是一个关键性细节，那么就极可能导致无法挽回的项目失败，随之而来，合作就会变成纠纷，后果是每一个人都不愿看到的。

那么，有没有解决办法呢？有。办法就是：倒着来，也就是作者在书中说的“时刻调换”。既然一开始我们没可能把所有细节都考虑清楚、设置清楚，那么就先不要考虑这些细节，而是遵循“最后责任时刻”原则，一开始并不急于编写一本高大全的开发文档，而是等到开始实现产品特性前，才写下这些特性的具体细节。这样，从一个简单的较低起点出发，经过项目管理的程序再造，就可以避免传统方法的种种弊端。

这实际上是一种“大道至简”的思维方法，就如我们都熟悉的《道德经》中说的，“一生二、二生三、三生万物”，有了最初的那个一，再去追求以后的万物就都有了可能，解决问题也是同样的道理，看似复杂的问题，其关键往往是令人难以置信的简单。

沈括在《梦溪笔谈》中记载了一个故事。宋真宗祥符年间，皇城失火，烧得皇宫面目全非。宋真宗命令当时的宰相丁谓担任重修宫殿的工程总指挥。这个丁谓虽然在历史上是个著名的大奸臣，但他确实有真才实学。他知道要修复皇宫，工程浩大，造价也十分高昂，虽然可以用国库的钱，敞开了干，但那就显不出他的本事了，他要的是花最少的钱，用最短的时间把皇宫重新建起来。

于是，丁谓开始对这个大工程进行统筹思考，他发现，修复皇宫有三大难题:一是重建工程要用到大量的城砖，需要取土烧砖，而当时的京城开封附近却没有合适取土的地方；二是工程中还需要大量石料和木材，这些东西需要从南方走水路运到京城，但当时的皇宫离运河码头很远，物料没法直接运到工地；三是工程结束后，会产生大量的建筑垃圾，需要找到合适的地方填埋，运输的工程量也不小。

建筑工程在现代都是一项很复杂的工程，就更别说在运输工具和建筑设备非常落后的古代了，但这个复杂的事还真就让丁谓想出了一个简单但有效的方法，给科学合理地解决了。

简单来说，丁谓就干了一件事，先挖一大坑然后再填上，那么麻烦的三大难题就完美解决了。

具体说，丁谓经过周密思考和精细计算，命人在皇宫工地旁边开挖一条大沟渠，把京城开封附近的汴河水引入渠中，建成一个临时货运码头，这样一来，南方水路运来的木材、石料就可以直接送到工地一线；而开渠挖出的土也不用运走，留下来就地烧砖；等工程基本完工之后，再把渠水从上游截断，把水排净，然后把所有灰土瓦砾等工程废料填进沟里，覆上土压实，就又恢复成了一条光亮平整的大街。

丁谓采取的这种简单的施工方案，顺顺当当地解决了取土烧砖、材料运输、清理废料这三个工程中最难解决的问题。所以沈括说他“一举而三役济，计省费以亿万计”，一举三得，节省的金钱以万亿计算，工期也缩短了一半还多。

丁谓在修复皇宫的工程中所采用的思考方法，就已经比较接近我们今天这本书中所讲的“倒着来”的敏捷方法了。他从结果开始思考问题，用最简单的方法把一个看似复杂的问题顺利解决了。

下面我们就来具体了解一下这种带来软件开发业革命性变化的“用户故事和敏捷方法”到底是什么。

二、用户故事与敏捷方法是什么

“用户故事”和“敏捷方法”这两个词听起来总感觉怪怪的，不那么好理解。实际上这两个词非常恰当，而且基本说出了这种新方法的关键和所能达到的效果。

首先，“用户故事”其实就是“用户需求”，但之所以我们叫“用户故事”，而不是“用户需求”，原因就在于“用户需求”是站在开发者、也就是供给方的立场上对用户需要的一种叫法，而“用户故事”则是由用户用自己的语言讲述的需求。

为什么要让用户自己来讲故事呢？因为上一节中我们讲了，传统意义上的用户需求其实是我们通过用户的表达，再经过我们自己的理解和消化而写在文档上的。而“我们理解”的用户需求，这个过程中由于涉及双方理解的念头和语义的转换，就存在出错的可能。

用户故事是让用户用自己的语言来讲故事，用户自己的表达是最准确的，用户自己的理解是最权威的。为什么要使用用户自己的语言呢？主要是因为用户熟悉他们所在的行业，他们常常会使用各自所在行业的术语，也就是“行话”。

比如初入股市的人，听一些老股民谈股市，什么除权啦、期指啦、平仓啦、杠杆啦之类的，肯定一头雾水，觉得对方说的确实是中国话，但就是完全听不懂。如果开发团队也不能真正理解这些行话，就有可能根据自己的理解，有意无意地改造了或曲解了这些话的意思，最后造成误会，给项目造成损失。为了避免这种念头，那就不如干脆让用户用自己的语言来写需求。

那么，“敏捷方法”又是什么呢？简单讲就是以用户故事为基础的一种软件开发方法。“敏捷”这个词翻译得特别好。敏是敏感、灵敏、敏而好学，是灵活机动和及时响应；捷意味着方便快捷，也就是高效、事半功倍。这个名称也反映了敏捷方法相对于传统方法最突出的特色。

也许有人会问，如果让用户用自己的语言写故事，但开发团队仍旧不能理解怎么办呢？不要紧，作者在书中我们提供了一套“敏捷方法”的基本流程，也就是“3C方法”：卡片Card、对话Conversation和确认Confirmation。

每一个用户故事都是写在一张卡片上，然后通过开发团队和客户团队之间的实时对话进行不断的修正，最后经过测试加以确认。经过这样的流程，开发团队与客户团队之间的理解将可以趋于完美。

三、如何实施用户故事与敏捷方法

那么具体来说，用户故事与敏捷方法应该如何操作呢？大致可以分为如下4步。

1、构建一个用户参与的大团队

采用用户故事驱动的敏捷开发模式，一个突出的特点就是团队构成。传统的软件开发，可能经过开发方与客户的少数几次、有时甚至就是一次大型会商之后，开发方就开始着手制作开发文档。

即使是一个不太复杂的软件系统，开发需求文档往往也是一本厚书。经过客户初步确认之后，就开始照此实施。直到软件交付客户验收，期间大家各干各的，不相往来。等到验收的时刻，才发现有些内容和客户期望的相差太远。有时候，文档让客户满意了，但产品上线之后，实际用户却不满意，项目实际上归于失败。

敏捷方法为了从根本上避免这个问题，要求客户、用户，特别是真正的实际用户，还有开发团队一起组成一个大团队，并且客户、用户要全程参与。这里说的大团队，并不是说人数多，而是组成人员的身份包含了传统团队并不包含的客户和用户。

这样构建团队，优势显而易见，因为有客户，特别是实际用户参与，那么沟通就可以随时进行，3C原则中的对话（Conversation）就不再是一种姿态，而是实实在在可以操作的任务。

2、讲述用户故事

构建了团队之后，就可以开始讲述用户故事了。

首先，用户故事要由客户、用户来写，别人，特别是开发人员或者项目经理不能越俎代庖。

其次，用户故事必须代表对用户有价值的功能。因此，用户故事就需要包括三项内容。

一是一项书面陈述，用来做计划或者提示；这样说比较抽象，我们举个例子，比如您是项目客户，需要开发商为您设计一个用来找工作的网站，您的用户故事可能是这样的：“用户可以搜索工作职位”或者“用户可以在网站上发布简历”等等；可见，用户故事就是简述用户需要的一项功能，作为客户和用户，原则上只需要讲述“我要客户或者用户能通过这个系统做什么”就可以了。

但是也要注意，用户故事，必须体现对客户或者用户的价值，不能是与这两个价值无关的东西，比如要求“这个软件要用C++语言编写”就是无用的故事，因为用户要求的是软件能用、好用，他才不会管你如何实现这些价值。

二是有关故事的对话，用于具体化故事细节；用户故事可大可小，各有用途。大到所谓的“史诗故事”,比如：“用户可以搜索工作”。要完成这个故事可能需要很长时间，由于缺乏细节，也很难着手去做。但是，大的故事可以作为一个“占位符”，意思是，虽然这件事必须得做，但想不清楚细节的时候，可以先占个位置，省得以后故事一多，把它忘了。

我们在日常工作中其实也经常这样做，有时候在办公室里，会立一块白板，团队中每个人想到什么，就先记下一笔，以后想清楚了，再去做。书中作者提醒我们，千万不能迷信自己的记忆力，科学研究表明，记忆往往不是过去经验的简单复制，而是一种叙事，就是说，现在我们回忆过去的事件，往往只是在讲述一个自己加工过的故事。

小故事呢？主要是表述细节，比如：“用户可以查看发布职位的公司的详细信息”。一般的，一个故事的大小，应该能够保证1-2个程序员在半天到两周的时间内可以写完代码并测试完毕，不能太大，也不能必太小。太大的，可以拆分，太小的可以合并。

三是测试，用来表达故事细节并可以确定故事何时完成；测试表示了用户的期望，比如，你在测试可以通过银行卡来付款的购物网站，此时的测试可以这么写：“用银联卡、Master卡、VISA卡、储蓄卡试试付款”。测试可以很简单，可以不完整，也可以任何时候加入或者删除。开发人员借助这些测试的提示来和客户、用户对话，随时了解客户、用户的期望，随需而动、调整程序，直到完全满足客户、用户的需求。

经过以上三步，一个有效的用户故事基本上就完成了，此时需要把故事记在卡片上。这里的卡片，是一个象征性的说法，不见得非得用卡片，也可以构建一个电子文档。今天我们读的这本书的翻译团队就做了一项有趣又有创新意义的工作，他们把翻译这本书当作一个项目，采用了书中讲的“用户故事”的方法来完成。

翻译团队把每一章作为一个用户故事，用一份Excel文档作为电子白板，每周用Skype召开网上会议。在采用了这种方法之后，项目的推进变得更顺利了，由四个人组成的翻译团队的工作，变得快速而稳定，最终及时地交付了翻译稿。

3、排列故事优先级和构建迭代计划

用户故事经过团队构建完成之后，就要进行排序，意思是排列优先级，先做重要的事情，再做次要的事情，对于不必要的事情，就干脆不做。故事的优先级也是由客户和用户来决定的，优先的故事，意味着对客户、用户来说最重要的价值。

但是，那么多故事，那么多卡片，要排序不是那么容易的，而且一次迭代，也就是一个开发周期，开发团队的精力是有限的，有可能几个故事的优先级都很高，但是也都很大，不能保证它们可以在第一次迭代中同时开始进行。怎么办呢？敏捷方法采用了一种量化故事大小的方式来科学构建迭代计划。而量化故事所需工作量大小的单位就是“故事点”。

一个故事点的大小，可以按照开发团队以往的经验来确定。作者麦克·科恩的团队一般把一个故事点计算为一个“理想日”的工作量。理想日，就是你不被任何无关的事情所打扰，把全部工作时间投入工作的一天时间。这么估算，最后的结果就是某个故事需要4个点，意思是需要4个理想日，1个点就是需要1个理想日。

故事点的估算，主要是开发者的任务，但是，在进行估算时，开发人员仍要尽可能地向客户、用户提问，以确定真正的工作量。此外，也不能只盯着写代码和测试的时间。这是我们日常经常犯的错误：往往我们完成一项任务的实际时间，总是比我们估算的要多。

这有点像我们去商店买衣服，虽然从我们走进店，看衣服、选衣服、试衣服到付款可能只需要一个小时，但实际上我们为这件衣服花掉的时间要远远超过一个小时，这里面包括我们来去路上的时间，到店之后闲逛的时间，还可能有吃东西的时间等等，所以，开发人员，特别是程序员在估算一个故事时，也应该考虑到代码以外的事情，包括和客户讨论，各种测试等等。

用户故事按照故事点估算出工作量大小，就可以制定迭代计划了。迭代计划以故事的优先级为最主要的考量因素，最重要的事情排在第一次迭代里，如果这个故事很大，也就是故事点比较多，那么这次迭代只进行这个故事也是可以的，如果不太大，可以进行几个故事。

如果一个故事的故事点超过了一次迭代团队最多能完成的故事点，那么，就需要拆分这个故事，把一个重要的故事拆成最重要的和次重要的故事。这同样需要开发者和客户、用户通过反复沟通对话来完成。

4、“用户故事”的实现、测试和发布

最后，进入到了实际操作的阶段，包括程序编码、测试和发布。这一部分和传统的开发过程看上去没有太大不同。但是，由于前期的时刻调换，用户故事和敏捷方法已经具备了实现高效、灵活和精确的基础。

首先是高效。由于用户故事和敏捷方法并不是先做出开发文档，以此作为实施方案来一步步完成，而是先由用户提出需要的价值，再以重要性排序，按重要性从大到小来完成，这保证了项目最重要的特性在项目早期完成，此时其他的特性还比较模糊，甚至用户还未决定是否需要。

如果用户需要这些其他的特性，可以以后添加上，但是最重要的特性也不需要推倒重来，如果前期做了一些不太重要的特性，那么就还需要以后删掉。所以，做最重要的事情，就保证了不必重复劳动。而由用户来写故事，则保证了我们不会去做用户不需要的事情。用户故事相对于传统开发文档的高效性，实际上也体现出了管理上的“二八法则”：完成百分之二十的最重要的事情，可以解决百分之八十的问题。

其次是灵活。通过大团队的对话来决定优先级，根据工作量和迭代计划来拆分、合并故事，并且实现和客户、用户的实时对话，随时通过增删、编辑测试来实现用户期望，这些灵活的特性，是传统的开发方式无法实现的。实际上敏捷方法的灵活特性中，包含了参与式管理、自组织、自管理的基本原理。

最后是精确。虽然故事点的方法只是一种估算，但是我们能够从中看出很多科学性的管理思维。传统的文案方式，我们几乎只能靠经验来大致估计项目的完成时间，几乎谈不到科学的成本控制。精确，虽然并不代表百分百准确，但它给我们提供了一种可以掌控进度的方法，即使在开发的过程中出现一些意料之外的状况，我们也可以通过小的调整来迅速回归正轨。

当然，用户故事驱动的敏捷方法并不是要完全否认文档的作用，为了方便后续开发，用户故事需要记录下来，组织成为一个综合性的开发文档，以便在后续项目的开发作为参考。

总结

以上就是《用户故事与敏捷方法》这本书的主要内容。通过时刻调换这一大道至简的观念变化，以用户故事的讲述、排序、迭代组织为基础，敏捷开发颠覆了传统的开发文案式管理，实现了高效、灵活、精确的软件开发管理模式。

这一点与我们在上一季书单中读过的一本书《精益创业实战》中的观点非常相似，都是强调不要一上来就追求终极的完美，而是首先确定一个核心需要并围绕这个核心迅速开发出第一代产品，然后根据市场和用户的反馈，采取小步快跑式的更新迭代，通过迭代逐步接近理想中的完美目标。

这种互联网思维即使在其他任何一个行业，都是非常值得借鉴的经营管理智慧，它带给我们的是项目管理中革命性的变化，可以让所有创业者始终保持清醒，始终思考前进方向并不断调整，从而最大化地利用资源、降低风险，这本身，就是走向成功的最佳保证。

恭喜你和“今今乐道”读书会一起读完了你生命中的第1253本书，希望今天的内容能给你有益的启发。（拆书人：王羽）

《用户故事与敏捷方法》金句：敏捷开发的原则是，要让迭代转起来，不停地发布，不停地满足用户故事。

企业要想实现精确的成本控制和团队的高效协同运作，就离不开对用户需求的精准把握和对管理模式的适时革新。

点击右下方“分享”按钮，把掌握“用户故事”与“敏捷方法”的途径送给需要的朋友，使他能更好地满足用户需求。

移情用户系列的其它六本书：

《零售心理战》|三个关键点，抓住用户的“明日需求”。

《超级用户》｜如何找到你的超级用户，保持基业长青