本书介绍了如何创建可执行的规范并使用这些规范来测试软件需求与行为。具体介绍了在Scrum框架下如何构建软件，如何将需求与架构相连，如何自动进行需求验证等内容，可帮助读者解决在软件开发中的最重要的挑战：不仅仅要正确地解决问题，更要解决正确的问题。

著名敏捷教练、MVP专家亲笔撰写，多位Scrum专家鼎力推荐，系统讲解Scrum提炼可执行需求说明的理论和实现技术
通过一个迭代式挖掘需求的可靠案例，深度解析在前提条件尚不明确、需求难以把握且需持续演进的情况下如何阐释清楚软件需求说明，创建可执行的需求说明

大多数关于需求说明的图书仍会假设需求从一开始就可以被识别清楚，并且在项目实施过程中不会发生变化。然而，在当今这个现实世界，在说明和构建软件的过程中，必须面对高度且持续存在的不确定性。Scrum等敏捷方法通过演进来反映现实世界。现在，我们有了一个在敏捷环境中当先决条件还不清晰、需求很难把握的情况下如何说明软件需求的完美指南，你在项目中遇到的所有事情都将因此而发生变化。
有着多年敏捷教练和企业级架构经验的Mario Cardinal给我们展现了如何创建可执行的需求说明，并使用它们来测试软件行为与需求是否相符。书中通过一个强有力的迭代式探索需求的实例，从理论到实践，完整地阐释如何一步一步增量式地收集需求，从可执行需求说明中收获关于技术机制和经验技术的全部价值。
　

通过阅读本书，你将学到：
为分析师和架构师设立更加有效的敏捷角色
从FIT、 ATDD 和BDD中整合并简化最棒的技术
识别项目团队必须赖以保障需求探索的“核心的已确定因素”
通过使用短周期反馈环来探索干系人愿望，并以此来管理不确定性
像需求说明所要求的那样去构建小块的软件功能
使用故事板和纸原型来改善与干系人之间的沟通
使用用户故事形式的需求来表达干系人的愿望
提炼用户故事，并利用Scrum Sprint更有效地开展计划
通过使用场景将行为脚本化来确认用户故事
将场景转换成自动化测试，易于确认期望的软件行为
通过说明非功能性需求确保得到更高的软件质量

作者简介
Mario Cardinal　 著名敏捷教练，Scrum的实践者，多年来专攻软件架构，有20多年大型信息系统设计经验。他是Slingboards实验室的创始人之一，该实验室是一个新兴创业公司，他们将即时贴功能做进智能手机、平板电脑和互联网，帮助团队更好地协作。Cardinal已经连续9年获得微软最有价值的专家（MVP）称号。MVP一般授予社区最好的成员、最愿意在社区分享经验并帮助他人发挥潜力而值得信赖的技术专家。

译者简介
黄灵　 PMP、CSM、 CSPO、CSP，管理3.0_敏捷领导力实践培训课认证讲师，敏捷实践者及敏捷教练，有多年软件开发项目及项目群管理、Scrum 实施经验。现供职于上海惠普有限公司，GDC 敏捷推广项目负责人，专注于传统项目团队敏捷转型实施指导、敏捷相关培训以及公司、组织级敏捷转型咨询。与人合作翻译出版了《敏捷技能修炼：敏捷软件开发与设计的最佳实践》和《言语的力量：高效的商务呈现和谈话技巧》。

内容简介
本书由著名敏捷教练、MVP专家亲笔撰写，多位Scrum专家倾情推荐。书中深度解析了在前提条件尚不明确、需求难以把握且需持续演进的情况下如何阐释清楚软件需求说明，不仅提供了一个迭代式挖掘需求的可靠案例，还介绍了如何将需求说明与正在构建的软件连接起来，以创建一个可执行的需求说明。
全书共9章：第1章解释为了有效应对持续变更的需求而采用迭代探索和可执行需求说明的重要性；第2章介绍如何识别那些不可改变的事情，是它们保证迭代式需求探索方法成为可能；第3章揭示为了找出不确定性，团队必须通过短周期反馈环挖掘干系人的期望和需求；第4章介绍如何采用用户故事表达“愿求”，以及如何使用产品待办事项列表记录它们；第5章解释如何通过优化产品待办事项列表来帮助我们做迭代计划，这样可以提高整个反馈环成功的概率；第6章展示如何通过故事场景编写用户故事行为脚本来确认用户故事；第7章解释如何将故事场景转换成自动化测试；第8章介绍如何通过详细说明非功能性需求保障软件的质量；第9章总结全书最关键的要素。

市面上关于需求说明方面的书籍有很多。不幸的是，这些书绝大多数对于软件开发团队来说都不实用。因为那些书依赖于传统的工程实践。他们假设需求是可以事先获得的，并且一旦被写出来，在项目进行过程中就不会再修改。而且，他们认为就算发生变更，都是一些细微的变化，因此，可以通过变更管理流程来进行追踪。他们创建了从明确需求阶段开始的系列流程，而这个阶段将在团队开始设计和实现产品之前提供详细的需求说明。
本书目标
　　我认为传统的工程实践对软件开发来说并不适用。提炼软件需求说明的流程的核心问题是不确定性很高，这与传统的工程是不同的。幸运的是，在过去十年，随着敏捷社区的成长，我们已经整合出了更符合软件开发现实问题的知识体系。很多书都提到，敏捷方面的书籍已成为对软件开发感兴趣的所有人必读的书籍。这些书绝大部分都包含了至少一到两章跟需求相关的内容，其中有些甚至整本书都只讨论这个话题。我认为描述的有些内容非常重要，因此我会在本书里引用或参考这些内容。
　　我写本书是为了让敏捷知识体系更加饱满。这是可执行需求说明相关的敏捷实践的纲要。可执行需求说明能够让你更加轻松地测试软件行为是否满足需求。在本书中，我自始至终都在解释如何在前提条件尚不明确的时候，以及需求难以把握且需要持续演进的情况下把软件需求说清楚。软件研发实践者们将学会如何一步一步地紧紧围绕愿景，采用浮现式迭代实践，渐进明细地捕捉需求。他们还将学会如何通过编写细小的需求分支而将需求说清楚。
　　本书的目标是解释获得可执行需求说明收益所需要的技术机制。它不仅会提供一个迭代式挖掘需求的可靠案例，还将进一步地教你如何将需求说明与正在构建的软件连接起来。整个流程将引导你创建一个可执行的需求说明书。
　　即使我们有很好的意图也不能强制要求干系人同意我们的做法意识到这一点很重要。有句非洲谚语简洁明了地阐述了这个问题：“你不能拔苗助长。”当认知尚未完善，需求也在持续变更的时候，我们不能再依赖传统的工程技术。相反，强调经验技术的迭代式需求探索方式显得至关重要。探寻目标不仅是为了正确地解决问题，同时也是要解决正确的问题——这是软件构建过程面临的最大挑战。
　　本书的独特之处在于，它将教会你如何通过使用可执行的需求说明把需求和架构连接起来。你将学会通过Scrum框架如何在说明需求的同时，将需求验证过程自动化。读完本书，你可以选择一种工具，开始为将来的敏捷项目创建可执行需求说明。以下我列举了阅读本书的五个好处：
　　你将明白，当从传统的方式转型成敏捷实践的时候，业务分析工作将会发生何种变化。
　　你将学会如何在Scrum 框架内提炼浮现式需求。
　　你将见识如何采用故事板和纸原型法改善跟干系人之间的沟通。
　　你将发现如何开展浮现式设计，同时确保任何时候的实施的正确性。
　　你将了解采用敏捷实践的软件架构师如何随着当前的软件开发进行浮现式设计。
谁应该是本书的读者
　　本书的读者应该是已经在应用Scrum框架或者正在转型实施敏捷实践的人。他们理解敏捷的本质，但是并不熟悉可执行需求说明。他们希望了解为什么可执行需求说明有用，以及最重要的是如何开始实施这一新的实践。
　　随着Scrum框架的大量使用，敏捷团队面临的第二大挑战就是如何将业务分析师和架构师组合成活跃互动的团队成员。任何面临这一挑战的Scrum Master、经理、决策者都应该阅读本书。另外，所有参与敏捷项目的团队成员也将从本书获益。它并没有直接宣称业务分析师和软件架构师将会因找到一本直接说出他们所关注的问题的书而高兴。
　　高级或专家级的敏捷实践者将会对本书清晰的可执行需求说明全局感兴趣。他们可以利用本书成功地将团队引领到这条路上。另外，全书使用的术语可以帮助领导者更有效地与同事沟通。
本书的路线图
　　可执行需求说明提炼方法要求人们在思维方式上做出改变。本书的重点也在于此。可执行需求说明提炼方法有助于缩小干系人希望软件能做什么（什么）和该软件的确能做什么（如何）之间的差距。可执行需求说明以一种使开发团队很容易根据可执行需求说明来验证软件的方法澄清需求，而这跟需求变更一样在频繁地发生。
　　为了促进这种思维方式的改变，本书提供了一个跨越9章的独特思路。
　　第1章：解释了为了有效应对持续变更的需求而采用迭代探索和可执行需求说明的必要性。
　　第2章：解释了如何识别那些不可改变的事情：那些团队应该依赖的、核心的、有把握的事情。而这些有把握的事情不是需求本身。它们是能够保证一个方案得以实现的防护栏。它们组成了一个牢固的基石，保证迭代式需求探索方法成为可能。
　　第3章：揭示了为了找出不确定性，团队必须通过短周期反馈环挖掘干系人的期望和需求（“愿求”）。
　　第4章：介绍了如何采用用户故事表达“愿求”，并学会如何使用产品待办事项列表记录它们。
　　第5章：解释了如何通过优化产品待办事项列表来帮助我们做迭代计划，这样可以提高整个反馈环成功的概率。
　　第6章：展示了如何通过故事场景编写用户故事行为脚本来确认用户故事。
　　第7章：解释了如何将故事场景转换成自动化测试，这样我们就可以很容易地对照逐渐演进的需求说明确认软件行为是否符合预期。
　　第8章：介绍了如何通过详细说明非功能性需求保障软件质量。
　　第9章：本书最后一章，总结了全书最关键的要素。
致谢
　　我最想感谢的人是第一个说服我写作本书的Nathalie Provost。在写作本书的整个过程中，她都一直支持我并照料我们的四个孩子，让我得以实现梦想。
　　感谢我的业务伙伴Erik Renaud，他和我一起讨论了关于非功能性需求和协作白板的内容。同样，感谢Rob Daigneau和Stefan Surdek，他们在我撰写本书的全过程中给我提供了宝贵的意见和建议。
　　众所周知，学习来自于现实世界的经验。感谢Urban Turtle团队，特别是Francois Beauregard、Dominic Danis、Louis Pellerin、Guillaume Petitclerc和Luc Dorval，在他们的帮助下，我学到了很多关于Scrum、优化待办事项列表和可执行需求说明的知识。同样，我也忘不了和Tyco以及RunAtServer team团队，特别是和Yanick Brunet以及Gabriel Labrecque一起探险的经历，跟他们在一起，我有幸体验了使用故事板和纸原型构建一个真正的软件的过程。
　　我想感谢我的审稿人，他们阅读本书初稿并提供了大量的建议帮助我改进本书内容。感谢David Starr、Leyna Zimdars、Robert Bogetti、Jochen Krebs以及另一位匿名的审稿人。
　　特别感谢Leita Boucicaut，她协助审稿和修改草稿。突出的能力和坚定的信念使她总能找到合适的字词。她通过质疑我而使所有的文字都能被所有人理解，即使是不懂技术的读者。
　　最后，我想说的是，如果没有Addison Wesley公司的支持，我不可能出版这本书。感谢首席编辑Christopher Guzikowski、助理编辑Olivia Basegio、资深研发编辑Christopher J. Zahn以及资深项目编辑Lori Lyons。

“这是一本很棒的书！它体现了在敏捷环境中，在需求分析方面下工夫的价值，这种价值既有业务层面的，也有技术层面的。本书写得很棒，内容很流畅，适合经理人和程序员阅读。我建议那些需要整合业务分析和架构的Scrum团队成员也阅读本书。”
　　　　——Telerik首席战略执行官、Scrum Alliance 董事会成员Stephen Forte

　　“本书使Scrum最重要又最容易被忽视的问题凸显出来：在迭代开始之前准备好用户故事。团队经常为此抱怨，而作者提供了如何正确地准备好用户故事的可操作性建议。”
　　　　—— 《A Practical Guide to Distributed Scrum》作者之一Steffan　Surdek

　　“让本书闪耀光芒的并非其所展示的深度，而是其广度。这种宝贵的成熟的敏捷实践以高聚合的方式描述了触及产品研发相关的几个重要方面的关键流程。在这本内容紧凑的书里，作者清晰地解释了如何围绕创建可执行的需求说明应用敏捷技术，从而实现有效的价值流。”
　　　　——高效敏捷咨询公司创始人、欧洲首位Scrum.org 认证的职业Scrum Master 培训师Ralph Jocham

　　“作者提供了驱动高效的敏捷团队的技术和实践方面的深刻见解。作为作者描述的同行实践者，遇到那些问‘[ATDD/BDD/TDD/可执行需求说明等]到底是怎么回事？’的人，我现在有了一个书面指南来分享给他们。作者没有太多地关注这些时髦的名字，而是给了我们有效的操作方法。”
　　　　——微软Visual Studio高级项目群经理David Starr

　　“Scrum几乎算不上是一个流程，而只是一个框架。它是一个工具，你必须提供许多互补的实践与之匹配才能实现真正的业务灵活性。本书很适合正在实施Scrum并希望学习或准备实施可执行需求说明的团队。”
　　　　——Pyxis科技公司Scrum培训师Fran?ois Beauregard

　　“本书反映出在敏捷场景中，需求说明对各种敏捷实践者的利益的重要地位。”
　　　　——Pyxis科技公司技术和研发顾问Erik LeBel

计算机\软件工程

大多数关于需求说明的书仍会假设需求从一开始就可以被识别清楚，并且在项目实施过程中不会发生变化。然而，在当今这个现实世界，在说明和构建软件的过程中，必须面对高度且持续存在的不确定性。Scrum等敏捷方法通过演进来反映现实世界。现在，我们有了一个在敏捷环境中，当先决条件还不清晰、需求很难把握的情况下如何说明软件需求的完美指南，你项目中的所有事情都将因此而发生变化。
　　 有着多年敏捷教练和企业级架构经验的Mario Cardinal给我们展现了如何创建可执行的需求说明，并使用它们来测试软件行为与需求是否相符。书中。通过一个强有力的迭代式探索需求的实例，从理论到实践，完整地阐释如何一步一步增量式地收集需求，从可执行需求说明中收获关于技术机制和经验技术的全部价值。
　

　本书内容：
• 为分析师和架构师设立更加有效的敏捷角色
• 从FIT、 ATDD 和BDD中整合并简化最棒的技术
• 识别项目团队必须赖以保障需求探索的“核心的已确定因素”
• 通过使用短周期反馈环来探索干系人愿望，并以此来管理不确定性
• 像需求说明所要求的那样去构建小块的软件功能
• 使用故事板和纸原型来改善与干系人之间的沟通
• 使用用户故事形式的需求来表达干系人的愿望
• 提炼用户故事，并利用Scrum Sprint更有效地开展计划
• 通过使用场景将行为脚本化来确认用户故事
• 将场景转换成自动化测试，易于确认期望的软件行为
• 通过说明非功能性需求确保得到更高的软件质量

（美）Mario Cardinal 著：暂无简介

黄灵 译：暂无简介

曾经经历过以传统开发模式和敏捷开发模式进行产品研发的我，初见原书书名中的Specification一词时，并没有感到多么欣喜。因为，这些年来我见了很多厚厚的产品需求说明书，那种让开发团队既爱又恨的厚厚的产品开发规范，总是试图将明明还不确定的需求写得尽量详尽和具体。尽管我们知道，这些详尽和具体的描述很多都是建立在未来也许并不成立的假设基础之上的。事实证明，不管我们在需求说明上耗费了多少时日，也不管我们做过多少调研，如果不在研发过程中不断地进行修正和调整，最终我们仍然不得不面对原以为已经完美定义的需求早已脱离实际需求的正轨的事实。
　　然而，潜下心来的我发现，Cardinal想揭示给我们的却是跟我想象的传统需求说明别样的风景。
　　穿行在本书的各章节中，首先让我产生共鸣的是，作为软件工作者，很多时候我们把大量的精力和时间都耗费在“正确地做事”上，但现实回报给我们的常常却是大量的过于臃肿和复杂的软件系统。甚至我们耗费主要精力研发出来的功能并不为客户或市场所需要。这是一个常见却并没有得到足够重视的普遍现象。Cardinal不单将这一问题抛出来，引发我们思考，还耐心地引领我们找到解决问题的答案。
　　随着Cardinal的娓娓道来，你将找到一把钥匙，用来帮助你解决软件开发过程中不断出现的不确定性问题。有了这把钥匙，我们才可能具备拥抱变化的能力。这把暗藏于书中的钥匙，正在等待着你的探寻。
　　拥抱变化，并不意味着关于产品的任何部分都可以改变。任何一款软件产品，都有着区别于其他同类产品的核心功能和价值，那是它不可改变的部分，也是我们在迭代式需求探索过程中必须依赖的基础。
　　作为资深的敏捷实践者和专家，Cardinal将Scrum实践中的短周期反馈环跟“试错法”完美地结合在一起，他建议团队跟干系人一起，在Sprint过程中，对正在构建过程中的软件功能不断进行检查和调整，最后迭代式地交付可运行的软件。
　　对于团队来说，如何感知并抓住干系人的期望与需求，是把事情做正确的关键。作者使用具体实例详细阐述了用来挖掘干系人“愿求”的用户故事技术以及产品需求存放的地方——待办事项列表。读至该章时，也许你会有渐入佳境的感觉，因为本书后面会有越来越多可以实施的方法和技术用来帮助探索软件功能需求，并使需求探索、交付和验证过程能够可执行，而这些方法和技术也许正是你在苦苦寻找的解决方案。
　　写到这里，我想我应该停止“剧透”了。各位读者也许是怀着各自不同的目的来品读本书的。哪些是你想要吸收的养分，哪些是能够让你产生共鸣并回想起曾经的相同经历的部分，我真的无从事先判别。但是，如果你是备受困扰的敏捷项目的工作者或者管理者，你应该会对如何“做正确的事”和如何“正确地做事”感兴趣，那么Cardinal的这本书将会成为开启你在敏捷软件开发过程中全新旅程的签证。
　　翻译这本书时，觉得没有以前翻译那么艰难，因为整个过程我都像在跟一位从未谋面的“敏友”交谈，书中让我产生共鸣和触动的地方有很多。每一个理论，每一种实践，在他说来都是那么简洁并清晰明了；贴切的实例和有趣的比喻，使本书具有很好的可读性。最难能可贵的是，Cardinal的这本书将软件产品需求探索至交付和验证整个生命周期的不同阶段与不同的敏捷实践相结合，这才使得“可实施”成为可能，同时更好地帮助我们理解并学会如何在项目实际环境中运用这些实践。在Cardinal的笔下，敏捷实践不过是软件工作者自然而明智的选择。
　　在几个月的翻译过程中，我之所以能够在本就不多的业余时间里专注于聆听作者的讲述，并努力将他原本的意思呈现给各位读者，跟我的家人的支持是分不开的。包容我、理解我的先生，心疼我、帮我分担家务的婆婆，还有我最最可爱的小精灵般的女儿，是他们提供给我一张安静的书桌和一个思考的空间。
　　最后，希望我的努力能够让各位读者在阅读的旅程能够更加顺畅和愉快，这也是我最想回馈给我家人的谢意！

本书赞誉
译者序
前言
第1章　解决正确的问题　1
1.1　从解决方案中甄别需求　4
1.2　识别不确定性的影响　4
1.3　处理不确定性　7
1.4　小结　8
1.5　参考资料　9
第2章　依赖坚实的基础　10
2.1　界定不可更改的边界　11
2.2　组建一个健康的团队　11
2.3　要求所有干系人参与　13
2.4　明确一个可以共享的愿景　14
2.5　识别出一个有意义的共同目标　17
2.6　识别出一系列高级别的特征　18
2.7　验证“可能存在”的假设　19
2.8　小结　20
2.9　参考资料　20
第3章　使用短周期反馈环探索干系人的“愿求”　21
3.1　运用试错法　21
3.2　应用短周期反馈环　25
3.3　根据预期收益设定反馈目标　27
3.4　关注干系人的“愿求”　27
3.5　小结　30
3.6　参考资料　30
第4章　使用用户故事表达“愿求”　31
4.1　使用用户故事描述愿求　31
4.2　通过研究角色及其利益探索“愿求”　34
4.3　建立一种通用语言　37
4.4　使用待办事项列表记录“愿求”　37
4.5　小结　40
4.6　参考资料　41
第5章　优化产品待办事项列表提炼用户故事　42
5.1　管理产品待办事项列表　42
5.2　通过合作优化产品待办事项列表　45
5.3　采用圆点投票法对用户故事进行排序　46
5.4　采用故事板的方式阐明用户故事的需求　49
5.5　通过比较的方式估算用户故事规模　53
5.6　按照业务价值拆分用户故事　57
5.7　使用协作白板追踪用户故事　59
5.8　交付一组功能连贯的用户故事　65
5.9　使用用户故事计划工作　67
5.10　小结　68
5.11　参考资料　69
第6章　使用场景确认用户故事　70
6.1　使用场景创建用户故事脚本　71
6.1.1　用标准形式表达场景　73
6.1.2　使用FIT表格化格式编写场景脚本　74
6.1.3　使用已知–当…时–那么句型结构编写场景脚本　75
6.1.4　选择FIT表格化格式或者已知–当…时–那么的句型结构　78
6.1.5　规范化通用语言　78
6.2　将场景拆分成指令和查询　81
6.3　两步法流程协同确认　82
6.4　从场景里剔除技术考量　87
6.5　在Sprint过程中演进场景　89
6.5.1　按照特征（feature）组织场景　89
6.5.2　通过特征编写场景文档　91
6.5.3　避免重复和合并冲突　92
6.6　小结　92
6.7　参考资料　94
第7章　使用验收测试自动确认需求　95
7.1　在验收测试中引入场景　96
7.2　使用红–绿–重构循环自动化场景　99
7.3　将场景转换成验收测试　102
7.3.1　使用内部DSL进行调换　102
7.3.2　创建一个测试　105
7.3.3　将DSL代码写进新创建的测试中　106
7.4　将新创建的测试与接口连接起来　108
7.4.1　接口设计练习　109
7.4.2　场景步骤间的背景链　111
7.4.3　使测试失败　112
7.5　实现接口　113
7.5.1　用需求说明–情景测试替换单元测试　114
7.5.2　让测试通过　115
7.6　演进验收测试　115
7.7　使用持续集成并同时运行验收测试　116
7.8　通过测试结果来增强场景　117
7.9　小结　119
7.10　参考资料　120
第8章　处理非功能性需求　121
8.1　使用约束改善外部质量　123
8.1.1　将非功能性需求转换成约束条件　125
8.1.2　将功能性需求范围降低至一个简单场景　127
8.1.3　设置可度量的质量目标　129
8.1.4　使用行之有效的实践来测试约束　133
8.2　使用正确的工程实践确保内部质量　135
8.3　通过协作构建掌握实践　138
8.4　小结　139
8.5　参考资料　140
第9章　结论篇　141
9.1　本书概要重述　142
9.2　流程总结　144
9.3　提请注意各种角色　146
词汇表　148