前    言

对本书的介绍

在过去十年，敏捷运动向着更轻量、更敏捷的方法发展，已然成为自20世纪70年代瀑布模型出现以来对软件企业具有深远意义的最重要的变革。各种思想的融合加上一批实干家领袖，一些经过实践检验并取得成功的经验，证明了敏捷方法已经在“四个度量”上具有突出的优势，即：生产率、质量、员工士气和上市时间。

在过去五年中这些方法像病毒一样传播。在大型企业中，通常一开始是个别团队采纳各种方法中提倡的部分或全部的做法，从而使新倡仪开始得到贯彻。这些方法主要包括XP、Scrum、精益、看板（更晚一些）和各种混合变体。

不管怎样，随着对这些方法的运用扩散到企业级别，针对其基本方法的一连串扩展就是必须的，这样才能应对较大企业所遇到的在漫长开发过程、机构、应用范围和治理等方面的挑战。

其中敏捷需求工作所面临的挑战就比较严峻，其困难体现在要把团队敏捷性中一些基本、轻量的实践，包括产品待办事项、用户故事等，伸缩到满足企业的项目集和项目组合层面。举例来说，各种敏捷开发实践都引入、采用和增强了“用户故事”（起源自XP），作为表达应用需求的基本方式。而且，针对用户故事运用准时制的原则，可以提供更精益的方式，并帮助消除瀑布风格的许多陈旧做法，比如向开发团队强加的过于繁琐和束缚的需求规范。

虽然用户故事在观念上是强大的，但是用户故事本身不能提供一个充分或足够精益的框架，用以论证较大软件企业中项目团队、项目集和项目组合等组织层面的投资、系统级需求和验收测试。如何才能做到这一点？这正是本书的目的。

本书为编写和测试代码的敏捷项目团队提供了一系列标准的精益和敏捷需求子集，包括：敏捷需求工件的模型、相应的实践、建议的角色、组织模型。而且这种模型也可以伸缩到满足最大型软件企业的全面需要。

为什么要写本书

2000年的时候，我与Don Widrig一起出版了我的第一本书籍：《软件需求管理：统一方法》，这时我已担任软件开发管理的高级经理和企业经营者25年之久。2003年我们又出了本书的第二版：《软件需求管理：用例方法》，它们被认为是管理应用需求的权威书籍。这两本书销量不错，并被翻译成五种语言。更重要的是，许多个人、团队和公司告诉我，这些书籍帮助他们取得了更好的软件产出，而这一点始终都是我们的目标。

在接下来的几年里，我的注意力转向敏捷开发方法，我对这些创新方法的能量、运用这些方法所交付结果的质量和生产率以及它们激励和授权软件团队的方式感到越来越钦佩。虽然过去是在小型的团队环境中对这些方法进行研制和检验，构建大规模软件的挑战则是更有吸引力的谜题，这样的工作一部分是科学、一部分是艺术、一部分是工程、一部分是组织心理学。其结果是，我开始帮助一些较大企业采纳和改造这些方法，在这期间涉及的项目影响着数以百计甚至数以千计的软件从业人员。幸运的是利用一些扩展，就可以对这些方法伸缩来迎接挑战。基于这些经验，在2007年我出版了《可伸缩敏捷开发：企业级最佳实践》，这本书意在帮助较大企业实现敏捷开发的优势。

《可伸缩敏捷开发：企业级最佳实践》采取了更宽泛的软件方法视野，没有特别关注软件需求工作。尽管需求管理一直是许多敏捷团队的难题，但是组织和文化方面的挑战更为巨大，并且还需要处理的一系列新兴的敏捷技术实践。

在过去几年里，软件开发领域朝向精益思想的运动引起了我的兴趣，一部分原因是我过去有从事精益制造的背景。总的来说，精益思想为关于产品开发经济及其附属的软件开发的论证，提供了完整、有深厚理论依据的、严谨的框架。

后来我（和许多其他人）的思想进一步发展，我们开始把敏捷开发，尤其是大规模的敏捷方式，视为“精益思想的软件工业实例”。此外，精益思想的范围超出了软件开发的实验室，它还提供了工具来应对其他部门的变化，比如调度、IT、运销以及项目集和项目组合的管理。简而言之，精益思想为机构性的变革提供了更广泛的框架，它可以帮助我们处理这些较大的挑战，我是精益思想的爱好者。

精益关注的是价值流，并且为支持持续降低面市时间、加速价值交付以及消除浪费与迟钝，提供哲学思想、行为准则和工具，这是它的核心。如果软件企业采取精益的道路，将有助于优化它对需求的理解与实现，因为需求是价值流的独特载体，至少是最好的指标。

精益思想向我们重新演绎了一遍工作原理。再次强调，它有助于我们在敏捷的并且逐渐精益的软件开发范式中关注需求管理实践。这就是我撰写本书的原因。

我希望这本书能够帮助软件从业人员、项目团队、项目集和企业做出相应调整以采纳敏捷与精益实践，使他们可以为用户和干系人交付更好的解决方案，并且由此实现成功带来的个人和企业收益。

如何阅读本书

在这本书中，我会讲一个有点复杂的故事，也就是要以实用、直白、易于理解的方式，讨论如何应对敏捷企业所面临的软件需求管理挑战，无论是雇用几名开发人员构建单一产品的企业，还是雇用成千上万的软件从业人员、构建前所未见复杂系统的企业，都会面临这种挑战。

为此，本书内容分为四个部分，后面三个部分阐述了特殊的敏捷需求实践，其复杂程度和范围渐增。 

第Ⅰ部分“概览：企业敏捷需求的全景图”

在第Ⅰ部分，我们介绍一个总体的过程模型，关于如何在项目团队、项目集和项目组合层面运用敏捷需求实践的“全景图”。

我们对软件方法进行了简单历史回顾，描述从瀑布到迭代和增量开发、到敏捷与精益的演化历程；而且介绍敏捷需求的全景图，这是一个关于组织、需求和过程的模型，可以用于团队，也可以伸缩到企业的全面需要。

然后是对这一模型的概述，并且例解如何把它用于团队的敏捷需求、项目集的敏捷需求和项目组合的敏捷需求。

这一部分的内容可以独立存在，它向你引进和介绍了敏捷需求有关的概念、术语和通用实践。

第Ⅱ部分“团队的敏捷需求”

在第Ⅱ部分，我们介绍了适合由敏捷团队用来管理需求的一个简单完备的模型。对这一部分模型被设计得尽可能轻量，不为敏捷团队增添任何不必要的复杂性和开销，这就是典型的敏捷方式。我们介绍了敏捷团队、用户故事、干系人、用户与用户表征、迭代、敏捷估算与速率、验收测试、产品负责人的作用，并在最后介绍了用于发现需求的一些方法。

如果你们团队正在采取敏捷方式，这一部分对敏捷需求的全面阐释正适合你。

第Ⅲ部分“项目集的敏捷需求”

第Ⅲ部分适用于那些涉及构建更复杂系统、经常要协调多支敏捷团队的机构。我们在全景图中进一步延伸，介绍其他一些需求工件、角色、组织结构和一些针对有关目标设计的可行做法。我们介绍了愿景、产品特性与系统特性、产品路线图、产品经理的作用、敏捷发布火车、发布计划、非功能性需求、需求分析技术，最后还包括了用例。

如果你是从事构建这种规模系统的开发人员、测试人员、经理、团队领导、QA、架构师、项目或项目集经理、开发总监，这部分内容正适合你。

第Ⅳ部分“项目组合的敏捷需求”

最后，第Ⅳ部分介绍需求实践的项目组合层面。在这一层面是希望指导企业构建不断增大的“超大型系统”、应用套件和项目组合，这些经常需要大量（20、50、100或更多）的敏捷项目团队的协调与合作。这一部分介绍一些其他的需求工件、角色、组织结构和针对有关目标设计的一些做法；介绍了在敏捷开发中大规模的系统级架构所发挥的作用；为论证这种系统如何以敏捷的方式演化并在必要时重新建构，我们引入了看板；我们还介绍了在项目组合与项目管理中的一些遗留的思维形式，并给出了相应的处理建议。在这一部分的最后一章，介绍投资主题和篇章，如何进行敏捷项目组合规划，后者也是我们的终极目标之一。

如果你是对项目组合、系统软件服务或IT应用进行管理投资的项目经理、开发总监、系统架构师、管理人员或项目组合经理，这一部分内容正好适合你。