前　　言

市面上关于需求说明方面的书籍有很多。不幸的是，这些书绝大多数对于软件开发团队来说都不实用。因为那些书依赖于传统的工程实践。他们假设需求是可以事先获得的，并且一旦被写出来，在项目进行过程中就不会再修改。而且，他们认为就算发生变更，都是一些细微的变化，因此，可以通过变更管理流程来进行追踪。他们创建了从明确需求阶段开始的系列流程，而这个阶段将在团队开始设计和实现产品之前提供详细的需求说明。

本书目标

我认为传统的工程实践对软件开发来说并不适用。提炼软件需求说明的流程的核心问题是不确定性很高，这与传统的工程是不同的。幸运的是，在过去十年，随着敏捷社区的成长，我们已经整合出了更符合软件开发现实问题的知识体系。很多书都提到，敏捷方面的书籍已成为对软件开发感兴趣的所有人必读的书籍。这些书绝大部分都包含了至少一到两章跟需求相关的内容，其中有些甚至整本书都只讨论这个话题。我认为描述的有些内容非常重要，因此我会在本书里引用或参考这些内容。我写本书是为了让敏捷知识体系更加饱满。这是可执行需求说明相关的敏捷实践的纲要。可执行需求说明能够让你更加轻松地测试软件行为是否满足需求。在本书中，我自始至终都在解释如何在前提条件尚不明确的时候，以及需求难以把握且需要持续演进的情况下把软件需求说清楚。软件研发实践者们将学会如何一步一步地紧紧围绕愿景，采用浮现式迭代实践，渐进明细地捕捉需求。他们还将学会如何通过编写细小的需求分支而将需求说清楚。本书的目标是解释获得可执行需求说明收益所需要的技术机制。它不仅会提供一个迭代式挖掘需求的可靠案例，还将进一步地教你如何将需求说明与正在构建的软件连接起来。整个流程将引导你创建一个可执行的需求说明书。即使我们有很好的意图也不能强制要求干系人同意我们的做法意识到这一点很重要。有句非洲谚语简洁明了地阐述了这个问题：“你不能拔苗助长。”当认知尚未完善，需求也在持续变更的时候，我们不能再依赖传统的工程技术。相反，强调经验技术的迭代式需求探索方式显得至关重要。探寻目标不仅是为了正确地解决问题，同时也是要解决正确的问题——这是软件构建过程面临的最大挑战。本书的独特之处在于，它将教会你如何通过使用可执行的需求说明把需求和架构连接起来。你将学会通过Scrum框架如何在说明需求的同时，将需求验证过程自动化。读完本书，你可以选择一种工具，开始为将来的敏捷项目创建可执行需求说明。以下我列举了阅读本书的五个好处：你将明白，当从传统的方式转型成敏捷实践的时候，业务分析工作将会发生何种变化。你将学会如何在Scrum 框架内提炼浮现式需求。你将见识如何采用故事板和纸原型法改善跟干系人之间的沟通。你将发现如何开展浮现式设计，同时确保任何时候的实施的正确性。你将了解采用敏捷实践的软件架构师如何随着当前的软件开发进行浮现式设计。

谁应该是本书的读者

本书的读者应该是已经在应用Scrum框架或者正在转型实施敏捷实践的人。他们理解敏捷的本质，但是并不熟悉可执行需求说明。他们希望了解为什么可执行需求说明有用，以及最重要的是如何开始实施这一新的实践。随着Scrum框架的大量使用，敏捷团队面临的第二大挑战就是如何将业务分析师和架构师组合成活跃互动的团队成员。任何面临这一挑战的Scrum Master、经理、决策者都应该阅读本书。另外，所有参与敏捷项目的团队成员也将从本书获益。它并没有直接宣称业务分析师和软件架构师将会因找到一本直接说出他们所关注的问题的书而高兴。高级或专家级的敏捷实践者将会对本书清晰的可执行需求说明全局感兴趣。他们可以利用本书成功地将团队引领到这条路上。另外，全书使用的术语可以帮助领导者更有效地与同事沟通。

本书的路线图

可执行需求说明提炼方法要求人们在思维方式上做出改变。本书的重点也在于此。可执行需求说明提炼方法有助于缩小干系人希望软件能做什么（什么）和该软件的确能做什么（如何）之间的差距。可执行需求说明以一种使开发团队很容易根据可执行需求说明来验证软件的方法澄清需求，而这跟需求变更一样在频繁地发生。为了促进这种思维方式的改变，本书提供了一个跨越9章的独特思路。第1章：解释了为了有效应对持续变更的需求而采用迭代探索和可执行需求说明的必要性。第2章：解释了如何识别那些不可改变的事情：那些团队应该依赖的、核心的、有把握的事情。而这些有把握的事情不是需求本身。它们是能够保证一个方案得以实现的防护栏。它们组成了一个牢固的基石，保证迭代式需求探索方法成为可能。第3章：揭示了为了找出不确定性，团队必须通过短周期反馈环挖掘干系人的期望和需求（“愿求”）。第4章：介绍了如何采用用户故事表达“愿求”，并学会如何使用产品待办事项列表记录它们。第5章：解释了如何通过优化产品待办事项列表来帮助我们做迭代计划，这样可以提高整个反馈环成功的概率。第6章：展示了如何通过故事场景编写用户故事行为脚本来确认用户故事。第7章：解释了如何将故事场景转换成自动化测试，这样我们就可以很容易地对照逐渐演进的需求说明确认软件行为是否符合预期。第8章：介绍了如何通过详细说明非功能性需求保障软件质量。第9章：本书最后一章，总结了全书最关键的要素。

目　　录

1.5　参考资料

2.9　参考资料

3.6　参考资料

第4章　使用用户故事表达“愿求”

4.1　使用用户故事描述愿求 4.2　通过研究角色及其利益探索“愿求” 4.3　建立一种通用语言 4.4　使用待办事项列表记录“愿求” 4.5　小结 4.6　参考资料 第5章　优化产品待办事项列表提炼用户故事 5.1　管理产品待办事项列表 5.2　通过合作优化产品待办事项列表 5.3　采用圆点投票法对用户故事进行排序 5.4　采用故事板的方式阐明用户故事的需求 5.5　通过比较的方式估算用户故事规模 5.6　按照业务价值拆分用户故事 5.7　使用协作白板追踪用户故事 5.8　交付一组功能连贯的用户故事 5.9　使用用户故事计划工作 5.10　小结 5.11　参考资料