敏捷软件开发的必读书籍，爱读书的你怎么能错过？

TVP 读书分享会，是为 TVP 打造的专属好书分享会，我们希望能够为大家提供一个分享书籍、交流感悟的平台，使每一位参与者都能在这里获得独特的感受，品味阅读的乐趣。

8月27日TVP举办了「跨“阅”局限」第三期读书分享会，邀请三位技术大咖，分享了六本精选好书。在读书会后，为鼓励大家坚持读书，分享感悟，我们在读书会交流群中举办了首期TVP七天读书打卡活动。接下来，让我们看看优秀读者Jack在活动中都分享了哪些阅读思考和感悟吧~

Mike Cohn所著的《用户故事与敏捷方法》，是了解敏捷软件开发的必读书籍之一。如果说敏捷理念是一场盛宴，那么用户故事就是其中一道经典菜肴。用户故事作为敏捷需求的一种管理手段，从需求的收集到验收和交付，贯穿了整个敏捷研发流程。我们甚至可以说，理解了用户故事，就理解了敏捷的核心思想。

好书简介

书籍名称：《用户故事与敏捷方法》

作者: Mike Cohn

内容简介：《用户故事与敏捷方法》详细介绍了用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。

《用户故事与敏捷方法》对于软件开发人员、测试人员、需求分析师和管理者，具有实际的指导意义和重要的参考价值。

内容分享

1、INVEST原则——用户故事的黄金标准

众所周知，敏捷软件开发是采用用户故事的形式来管理需求的，优秀的用户故事应符合INVEST原则：

Independent（独立的）：减少故事间的相互依赖，方法：依赖的故事合并为一个大的故事、用不同的方式重新分割

Negotiable（可讨论的）：故事的细节在客户团队和开发团队的讨论中产生（重要细节可事先在故事卡上备注）

Valueable（有价值的）：每个故事必须对用户（使用者）和客户（购买者）有价值，最好让客户来编写用户故事

Estimatable（可估计的）：开发人员需要能估算故事的大小，导致不可估计的3个原因：开发人员缺少业务知识、开发人员缺少技术知识、故事太大

Small（小的）：史诗故事分割之（复合故事直接拆解、复杂故事增加一个探针故事）、过小故事合并之

Testable（可测试的）：非功能需求注意量化验收标准

【读书感悟】

用户故事是敏捷迭代的基本工作原料，因此用户故事的质量对敏捷迭代效果有着重要影响。

INVEST原则明确了用户的黄金标准：“独立”使得任务分配和功能交付更加便捷，“可讨论”提醒团队注重“个体和互动高于流程和工具”的敏捷价值观，“有价值”强调了敏捷的核心是关注用户价值交付，“可估计”使团队在需求理解和工作量评估上达成共识，“小的”保证实现快速迭代、小步快跑，“可测试”强调质量内建和测试驱动开发的原则。

由此可见，用户故事的基本原则中，处处体现了敏捷的价值观和原则。

腾讯高级顾问乔梁老师在《持续交付2.0》一书中指出，INVEST六项原则的重要性是不对等的，EST>INV。也就是说，我们在敏捷实践中，至少要保证后面3项特性被满足。

2、收集需求——拖网捕鱼的隐喻

收集需求就像“拖网捕鱼” ：

1. 不同大小的网来捞取不同的需求，大网眼捞取大需求（价值高、重要），小网眼捞取中等需求（价值低、次要）
2. 需求像鱼一样会成长或消亡，今天的漏网之鱼（不重要的需求）明天可能重新捞起来（变得越来越重要）
3. 只在某一个区域不可能捞到所有鱼，因此收集需求也要针对不同用户群体和场景
4. 捞取需求时，捞到的一些废弃物应该及时抛弃，否则会使需求膨胀
5. 收集需求如图捕鱼一样，需要熟练的技能，熟练的需求人员知道如何捕捉需求

【读书感悟】

大师们阐述一个理论时，非常善于使用隐喻的方式，使用一个生活中的简单案例来类比复杂理论，使人易于理解、茅塞顿开。

例如：谷歌工程总监James Whittaker，曾经提出一种“漫游测试模型”，把软件测试人员寻找缺陷的过程，比喻成旅行者在一座城市中漫游探索的过程。通过类比城市中不同区域的特点，将软件进行功能分区，然后针对各个分区采取有针对性的探索手段进行测试，以发现尽可能多的缺陷。

使用隐喻看似简单，实际上并不容易。能做到这一点，关键在于洞察事物本质，然后才能触类旁通、以简驭繁。这一点我在“如何用简单比喻来说明复杂道理”一文中有专门论述，感兴趣的朋友可以查阅。

3、验收测试——质量内建的经典实践

用户故事验收测试：在写代码之前，先写好验收测试场景（使测试成为开发过程的一部分，而不是开发的下一个环节）

客户应当参与验收测试的定义，测试人员应当从客户角度测试，而非按程序员的描述去测试

验收测试的类型：以功能测试为主，也可以考虑用户交互测试（所有交互组件正常）、可用性测试、性能测试、压力测试

【读书感悟】

用户故事验收测试，是敏捷开发中质量内建的保证手段之一。质量内建，即确保软件在交付到下一环节前有了基础的质量保证，从而减少质量问题导致的返工，避免浪费大量人力成本。用户故事验收测试，事先从用户角度定义了功能的验收用例，开发在写好代码之后通过验收用例检验功能质量，这样就保证了功能开发不会偏离用户诉求。

在行动之前先明确目标和标准，然后据此制定行动计划，这种“结果导向、以终为始”的思路非常重要。小到个人计划，大到项目团队运作，都应当采用这种思路。

4、故事估算——小方法有大智慧

用户故事工作量估算步骤：

第1步：客户抽取某个故事，读给开发人员听，开发提问，客户解答

第2步：每位参与估算的开发人员在卡片上写出估算值（不要给别人看）

第3步：所有开发人员展示卡片，估算值高的和低的解释一下估算依据，其他人耐心聆听

第4步：大家讨论几分钟，客户可以补充解释或在故事卡上添加必要的注释（也可以写一两个新的故事）

第5步：开发人员再次写出各自的估算值，然后再次展示给所有人看

【读书感悟】

这里给出了一种具体可行的手段，使团队快速对估算结论达成一致。其优点如下：

第一，团队成员集体参与估算，在估算过程中交流了知识，加深了对故事的理解。

第二，通过多轮（实际上最多两轮）的交流，使团队成员对故事的估算达成共识。相对而言，简单的取平均值的做法则忽略了个别人的意见，可能由于考虑不够全面而埋下隐患。

用户故事乃至敏捷开发的很多细节，体现了对管理学、心理学、组织行为学原理的洞察，也体现了敏捷大师们的智慧，这也恰恰是很多国内企业经常忽视的点。

5、任务认领——自组织团队的理念

用户故事开发过程中的任务分解方法：

任务分解后，开发人员自行认领每个任务

每个任务指定一个责任人（即使结对编程等多人执行一个任务），负责确保任务完成

【读书感悟】

敏捷开发要求团队是自组织团队，而任务认领这个小动作，则体现了自组织团队的理念。任务是以认领而非分配的方式对应到人，这个过程包含了“承诺、尊重与信任”。从个人角度而言，一个人自主决定的事情，更会义无反顾地努力达成（自己挖的坑含泪也要填完）；从产品角度而言，自组织的团队更能激发每个人的创造力和潜能。

多人完成的任务，只指定一位责任人总体负责。这个规则可以避免多头管理导致的惰化效应，激发团队的责任意识，简单有效。

6、层次分明——故事的优先级排序

每个故事应该有明确的优先级排序，而不是“非常高、高、中等”模糊顺序的分组

1. 考虑因素

对所有用户的重要性

对少部分重要用户的重要性

故事不能按时完成带来的风险

一个故事对其他故事功能和实现的影响

故事对系统架构决策的影响（影响架构设计的故事优先级高，如性能需求）

1. 混合优先级的故事进行拆解

例如“用户可以根据作者、出版物名称、标题、日期或任意条件的组合来搜索杂志文章”，可以拆分成3个故事：

“用户可以根据作者、标题来搜索杂志文章”（必需功能，最高优先级）

“用户可以根据出版物名称、日期来搜索杂志文章”

“用户可以根据任意条件的组合来搜索杂志文章”

【读书感悟】

敏捷的核心的关注价值交付，因此在用户故事的排序上也体现了价值导向。只要每个故事的用户价值是明确的，那么就一定可以按顺序排列优先级，使团队优先投入到高价值的目标上。这个道理不仅适用于软件开发，也适用于其他场景。

个人认为，优先级排序这个环节，其实也是强迫产品负责人和团队对故事价值做深度思考的过程。想要做一个功能很容易，但是把这个功能的价值大小讲透彻不容易。相信完成故事优先级的排序之后，团队对每个故事的价值必然会有更加深刻的认识。

7、瑕不掩瑜——用户故事的优点和不足

（1）用户故事的优点

促进口头沟通（用户故事认为开发人员与客户的交谈有重大意义）

容易理解（用户和开发人员都能理解，无太多技术和商业术语）

大小适合做计划（大小可以控制，方便做发布计划和开发测试）

适合迭代开发（不需要写出所有用户故事，写出一部分故事就可以开始迭代）

鼓励延迟确认细节（每个迭代只讨论要做的故事的细节，暂时不做的先用史诗故事来代表）

鼓励参与性设计（容易吸引用户参与软件设计）

传播隐性知识（面对面沟通，可以促进隐性知识的传递和积累）

（2）用户故事的不足

大型项目，难以组织好成千上万的用户故事（故事之间关系复杂）

大型项目跨团队开发，只靠面对面沟通难以代替书面文档（建议：少量的必要文档--大范围共享，大量的面对面沟通--小范围交流）

有时需要额外的文档以实现可追溯性

【读书感悟】

任何事物都有正反两方面，因此书中也针对用户故事的优点和不足，进行了全面的解析。

这里特别提醒大家注意用户故事的优点，这些优点恰恰是敏捷与精益思想的体现，比如：沟通交流比文档更重要、清晰描述需求价值而非抽象定义、大小适当利于小步快跑、延迟定义细节避免过度计划引起浪费……所以要想理解敏捷和精益，就有必要深入理解用户故事的理念，并在实践中不断加深认识。

通读本书的朋友，在对用户故事认识更为全面深刻的同时，可能会存在疑问：在现实的软件开发过程中，有多少团队能够按照书中介绍的规则和理念进行实施呢？

在笔者看来，知道正确的理念是什么、但在实践中由于条件限制而有取舍，和不知道正确的理念是什么、因此在实践中没有执行到位，这是两种截然不同的状况。

作为一名软件研发人员，在理解了敏捷理念的情况下，在实践中努力践行，帮助团队尽可能以更敏捷的方式思考问题、解决问题，何尝不是一件乐事呢！

打卡读者感言：

移动互联网时代，时间和专注力成为稀缺资源，读书也似乎成为了奢侈的事。在腾讯TVP读书会的打卡活动中，有优秀的书友推荐好书，有打卡活动进行交流分享，带动更多人加入到读书分享的队伍中来。这样的活动在当前的时代背景下，可谓正逢其时。

——Jack，软件测试与质量专家，公众号“软件测试启示录”作者

（文章内容来自Jack在TVP读书会交流群中的分享）

TVP读书会交流群旨在为大家提供一个读书交流的平台，在这里你可以参与TVP大咖云集的读书分享会，发布读书打卡照片，分享喜欢的金句或想法，也可以找到志同道合一起读书交流的书友，让阅读不再孤“读”！扫描下方二维码或是搜索微信号：yunjiadahui，添加云小助微信，回复关键词“读书会”，即可加入读书会分享交流群，赶快行动吧~