一个常见的敏捷实践是在项目的早期执行一些高层次的需求设想，以帮助对您想要完成的范围达成一个共同的理解。此时的目标是为工作确定业务目标，开发一个共同的远景，并在高层快速地确定系统的初始需求。此时，您不需要编写大量的文档，相反，您将在稍后的模型风暴会议和通过TDD确定开发周期中的细节。通常，这种初始需求建模工作是以小时或天为顺序的，而不是像我们在传统项目中看到的周或月。本文解决了几个关键问题:

• 什么时候应该进行最初的敏捷需求设想?
• 为什么要进行一些最初的敏捷需求设想?
• 您最初应该建模什么?
• 您应该使用什么建模工具?
• 您实际需要进行多少初始需求设想?
• 你为什么不把细节先写出来呢?
• 什么时候进行大量的需求设想是有意义的?
• 人们真的在这么做吗?

1. 什么时候应该进行最初的敏捷需求建模?

敏捷模型驱动开发(AMDD)，见图1，显式地包含了敏捷项目迭代0期间的初始需求设想工作(一些流程可能称之为预热、初始阶段或初始阶段)。初始需求设想对于将敏捷软件开发技术扩展到更大、更复杂或全球分布式开发(GDD)工作中尤为重要。高层的目标是了解需求,它不是创建一个详细的需求规范在生命周期的早期,传统的做法称为“大需求预先”(BRUF)证明在实践中是非常危险的(传统理论认为BRUF是一个最佳实践,但经验表明否则)。

图1所示。AMDD生命周期:项目视图。

2. 为什么要进行一些最初的敏捷需求设想?

有些人会告诉您，您根本不需要进行任何初始需求建模。然而，我的经验是，以敏捷的方式进行一些初始需求建模有以下几个好处:

1. 你可以回答基本的商业问题。不管你喜不喜欢，人们总是会问你，你的愿景是什么(范围是什么)，你认为它将花费多长时间(计划)，以及它将花费多少钱(预期预算)。您通常不需要详细地回答这些问题，但是您需要说服为您的项目提供资金和支持的人员，让他们相信您了解您的项目团队将要解决的基本业务问题。
2. 提高的生产力。您可以识别和考虑项目面临的一些关键业务问题。
3. 降低业务风险。您的团队获得了拥有指导业务远景的优势，而没有与BRUF相关的缺点。在统一过程中，初始阶段的主要目标是驱动范围与涉众的一致性，从而降低业务风险，而实现这一点的方法是通过初始需求的设想。您不仅确定了工作的范围，还帮助相关的涉众意识到您的系统(而不仅仅是他们的系统)正在满足一系列的需求，而且他们有时将不得不做出妥协。
4. 扩展敏捷软件开发。初始需求模型将是一个关键工作产品任何大规模“敏捷”的努力,因为它提供了你所需的业务方向他们最初的建筑构思总体架构团队的努力(通常在与初始需求建模)和团队成员定义在整个项目和指导他们的努力。

3.您最初应该建模什么?

对于系统的第一个版本，您需要花费几天的时间来确定一些高级需求以及版本的范围(您认为系统应该做什么)。我们的目标是让你对这个项目有一个良好的直觉。我的经验是，你需要一些形式的:

• 使用模型
• 域模型
• 用户界面模型()

3.1使用模型

使用模型使您能够探索用户将如何使用您的系统，如果您想了解他们需要什么，这是绝对关键的。您的使用模型可能是Rational Unified Process (RUP)项目上的一组基本用例或系统用例，一组用于功能驱动开发(FDD)项目的功能，或者一组用于极限编程(XP)项目的用户故事。我通常更喜欢用户故事或者用例，尽管我在实践中的实际选择将由团队所遵循的软件过程(RUP, FDD，…)驱动。

在项目开始时，用例名称列表可能就足够了，尽管通常您需要更详细地介绍。图2描述了我将考虑为一个高级用例考虑的细节级别。它指示名称(在本例中是注册研习班)和用例所涵盖的基本逻辑。我可能会将这类信息写在索引卡或便利贴上(如图7所示，这种基于纸张的建模在敏捷项目中很常见)。我甚至可能决定使用电子工具(如文字处理程序或电子表格)来捕获它，尽管此时，这样的工具可能会阻碍我的建模工作，而不是提供帮助。

 

图2。作为高级用例注册研讨会。

• 参加研习班
• 学生选择参加一个研讨会
• 系统检查学生是否可以报名参加研习班
• 系统计算费用
• 学生支付费用并被录取

关于图2的用例，需要注意的一件有趣的事情是，它没有捕获很多细节。例如,它只有一个高度概括的逻辑当事情解决好(行动的基础课程),但它不捕获备选过程如当学生没有资格参加,或没有房间在研讨会上,或者它不适合的计划,或他们不能支付费用,等等。如图1所示，可以通过模型风暴在即时(just-in-time, JIT)的基础上捕获细节。现在的目标是获得对范围的高级理解，而不是编写文档，也就是我们对需要构建的内容的理解。

图2的用例对应的用户故事是:

• 作为一名学生，我搜索研讨会，所以我可以注册他们
• 作为一名学生，我报名参加一个研讨会，这样我就可以参加了
• 作为一名学生，我要交学费，这样我就可以入学了

尽管它们对开发人员来说是相对无用的，但是您经常会发现您想要创建一个UML用例图来概述您所构建的东西的使用需求。图3给出了这类图的一个例子在白板上,虽然你常常会发现,您需要使用一个电子绘图工具如Visio甚至CASE工具,例如Rational System Architect (RSA)“漂亮”图展示等高级管理层和重要利益相关者的“金老板”的项目。尽管如此，我经常在管理演示中使用白板草图的数码照片，如图3所示。他们是成年人，他们明白你有更重要的事情要做(比如构建可运行的软件)，而不是把信息转录成更复杂的工具。

图3。UML用例图的白板草图。

3.2域模型

您最初的建模工作的一部分，特别是对于业务应用程序，可能包括概念域模型的开发。这个模型应该非常精简，捕获主要业务实体及其之间的关系。正如您在图4中所看到的，您的模型并不需要是完整的，它只需要包含足够的信息，使您能够适应主要的业务概念。我会在白板上画一个这样的模型作为开始，并且很可能在整个项目中都把它放在白板上。我的经验是,一个苗条的域模型这样的项目团队是一个有价值的资产,应该非常容易视图(你应该只需要从你的办公桌并查看共享白板在你的工作空间),创建(白板非常包容),和修改。

图4。初始域模型。

域模型标识基本业务实体类型以及它们之间的关系。域模型可以描述为类责任协作者(CRC)卡的集合、瘦UML类图，甚至瘦数据模型。此时，您的域模型将包含足够的信息来理解业务实体的“全景”。图4应用了一个基于UML的数据建模符号(您可以使用任何您喜欢的符号来进行敏捷数据建模，我更喜欢UML)。您的初始域模型将用于帮助指导物理数据模型和类设计。

3.3用户界面模型

用户界面(UI)是用户直接与之交互的软件的一部分。对于大多数涉众来说，UI就是系统，因此确保您理解涉众对UI的期望对于项目的初始成功是至关重要的。探索UI需求的一种方法是创建所谓的基本UI原型，也称为抽象原型或纸上原型。基本UI原型以独立于技术的方式表示用户界面需求，就像基本用例模型对行为需求所做的那样。图5描述了一个基本的UI原型，用于让学生参加研讨会。学生姓名便利贴是一个包含四个活动元素的容器:名字、姓氏、中间和标题。另一个便利贴是学生参加过或正在参加的研讨会的列表。请注意，每个便利贴都有一个描述其用途的名称，但没有说明它是如何实现的。你可以看看便利贴，马上就知道它是怎么用的。

图5。注册研讨会的基本UI原型。

尽管基本UI原型是一项伟大的技术，但许多涉众发现它们太抽象，反而更喜欢屏幕草图和工作软件。图6表示图5的屏幕示意图版本。在这种情况下，有两个屏幕而不是一个屏幕来处理聚合问题——我更喜欢实现单一目的的屏幕，在这种情况下，分别捕获基本的学生信息和让学生参加研讨会。这可以说是一个设计问题(在需求/分析和设计之间有一条很细的线，您将一直跨越这条线)。草图提供最终的详细程度比纸上原型,它是更容易了解如何实现屏幕比从图5中,尽管草图不灵活的,因为很难小部件从一个图的一部分转移到另一个而纸很容易。

图6。屏幕上的草图。

一个相关的模型是一个UI流程图，通常称为UI故事板，如图7所示。然而，UI流图绘制可以说是一个UI体系结构问题，可以通过并行的初始体系结构设想工作来解决。最重要的是，模型的分类并不重要，重要的是，当它有意义时，你就去做。

图7。UI流程图。

有些项目甚至可能需要开发一个具体的用户界面原型，如图8所示。您通常至少会为UI的一个关键子集这样做，以便在项目开始时研究可用性问题，但不针对整个系统(即BRUF)。

图8。具体的UI原型(HTML页面)。

4. 您应该使用什么建模工具?

敏捷建模者将使用最简单的工具来完成工作。正如您在图3和图6中所看到的，我发现白板图通常足以满足初始需求模型。您的目标是在生命周期的这一点考虑关键的业务问题，而不是创建漂亮的图表。使用更复杂的绘图工具并没有什么错，正如您在图4中所看到的，只要确保您投入的努力是值得的。这完全取决于你所处的环境。此外，基于纸张的工具也很常见。例如，我很想首先在索引卡上捕获图2的用例，然后在适当的时候使用电子工具捕获信息。

5. 您应该进行多少初始需求设想?

快速的答案比“极端敏捷者”告诉你的要多一点，但比专业建模者相信的要少很多。请记住，此时您的目标是了解范围和远景，而不是详细记录人们对他们想要什么的猜测。重要的是要认识到你不需要细节，你只需要足够的信息来回答你被问到的业务问题。如果要点列表足够好，可以让您对实现用例的相对工作量做出合理的猜测，那么现在只捕获这些信息。如果您需要这些细节，可以在项目期间或迭代建模期间通过模型风暴以准时(JIT)的方式收集它们。试图在项目的早期捕获需求背后的细节被称为“前面的大需求(BRUF)”。BRUF在理论上看起来是一个好主意，但在实践中证明是相当危险的，因为它所激发的浪费水平很高。

您的初始需求建模工作有几个潜在的最终产品:

1. 初始需求堆栈。敏捷人员必须来自某个地方的初始“优先级需求堆栈”，而这个地方就是您的初始需求建模工作。
2. 最初的项目远景。为了减少项目上的总体业务风险，您应该考虑开发一个初始的项目远景，一个Rational统一过程(RUP)和项目管理协会(PMI)已经推广了十多年的想法。一个好的项目愿景可以是简单的几个要点或一段话，不应该超过一页。传统的组织，特别是那些错误地以一种沉重的方式实例化RUP，或者以一种沉重的方式引用PMI的建议的组织，经常会在远景声明上投入太多的时间。一个很好的经验法则是，如果您的项目远景超过一页，那么您已经在编写它上投入了太多的精力。
3. 概述图。因为您可能需要向查看项目的主要项目涉众进行演示，所以您可能需要创建几个描述业务的范围图。UML用例图或传统的业务流程模型通常非常擅长于此。如果你花了几个小时在白板上画这些图表，然后把它们抄写到一个工具上美化它们，那你就做得太过分了。

图9描述了建模的价值，显示了当模型还不够好时，它们达到了它们的最大价值，对于大多数项目来说，当涉及到初始需求时，通常在几天或一周左右之后才想到这一点。许多人最初震惊这一说法,但当你回想起你曾经的所有项目上,有多少,如果你允许,你能确定初始范围内一两个星期把几人理解域在一起在一个房间里的白板?我问过几千人这个问题，但只被告知少数几个项目不是这样的。周围许多人的故事无法让人们同意,向我显示,你应该考虑做这个项目完全或尝试一些与一个较小的范围,不能获得利益相关者(一个物流的问题,你可以选择克服如果项目实际上是足够重要的),或者他们根本不知道他们想要什么(现在明确表示不做项目)。这些都是借口，但是它们不是通过做太多初始建模来增加项目风险的好理由。

图9。建模的价值。

6. 为什么您不需要，也不想预先了解细节

有几个原因可以解释为什么在开发项目的开始就提出详细的需求在实践中是一个非常糟糕的想法:

1. 它导致了大量的浪费。研究表明，当项目团队采用平均45%的交付功能从未被使用的BRUF方法时，实际上能够将软件交付到生产中。在我看来，45%的浪费是不可思议的。遗憾的是，在项目开始时，经常采用BRUF方法来获取“准确”估计所需的信息，这是财务人员在减少财务风险的错误尝试中所需要的。考虑到由此产生的浪费，很明显，这种方法似乎会增加项目的财务风险，而不是降低它。
2. 它减少了您发现您正在构建错误的东西的机会。详细的需求规范可以为您提供一种错误的安全感，使您能够理解涉众的需求。这反过来又会使您在项目进展过程中失去探索和重新思考需求的动力，从而降低您认识到并处理与涉众实际需要的任何偏差的可能性。
3. 人们不擅长预先定义他们想要什么。这是我们几十年前就知道的，它激发了20世纪80年代的螺旋/RAD运动，以及UI社区中的原型实践。
4. 它会促使糟糕的决策。项目开始时，您对问题域的了解最少，而涉众对解决方案域的了解最少(您还没有生成任何可用的软件来显示它们)。然而，传统的教条是将您所有有限的并且很可能改变对需求的理解写在纸上，这样您就可以开始制定重要的计划和预算决策。然后，在项目的后期，我们惊奇地发现，我们在项目早期所做的决策，特别是我们的评估，证明是相当糟糕的。记住GIGO的格言:垃圾进，垃圾出。
5. 它增加了沟通的风险。几十年来，我们也知道，至少心理学界知道，向某人提供文档是向他们传达信息的最糟糕的方式。对于人们彼此之间的沟通，还有更好的策略，在需求引出的情况下，积极的涉众参与的AM实践将显著降低沟通风险。
6. 一旦需求稳定下来，您总是可以记录下来。如果需要编写需求文档，那么在需求稳定之后，在生命周期中尽可能晚地编写文档会更有效。这并不一定意味着您必须在项目结束时编写文档，需求规范可以而且应该是随时间变化的活文档。此外，大多数敏捷人员更喜欢在客户验收测试(可执行规范的一种形式)中获取详细的需求信息。

许多传统主义者会告诉你，你需要预先对每件事进行详细的建模。他们错误地相信这一点有以下几个原因:

1. 这是他们所知道的。大型预先建模(BMUF)是他们所接受的培训，也是他们在整个IT职业生涯中一直在做的事情，他们被告知，否则工作是无效的。传统的教条是做BMUF，当你已经被这种教条束缚了几十年，你需要几年的时间来打破它。
2. 他们是专家。许多人选择专攻建模活动，结果他们就这样做了，因为这是他们唯一可行的选择。专家不仅倾向于执行他们的专业活动(这并不奇怪)，不管是否需要，他们还会有一个表面上看起来一致的理由，说明为什么这是一件重要的事情。不幸的是，他们的推理通常只关注感知到的好处，而不考虑实际的风险。
3. 传统的项目管理思想激发了糟糕的建模策略。传统主义者常常被迫创建详细的、预先的评估和计划，这是一种错误的尝试，目的是减少项目风险(这种策略不可避免地增加了项目风险，因为它激发了大量可疑的开发活动)。
4. 他们低估了自己的日程安排能力。传统主义者常常认为他们无法在整个项目中接触到涉众，这是一个自我实现的预言，因为多年来，传统主义者一直在培训涉众，认为他们只在需求和用户验收测试阶段才需要。在实践中，获得与涉众的联系通常是非常容易的。
5. 他们已经放弃了希望。许多传统主义者，也许是大多数人，并不真正相信BRUF是一个好主意，而是被组织中的其他人强迫接受的。有趣的是，当你把所有的主要决策者聚集在一个房间里时，人们很快就会得出这样的结论:没有人真正想做BRUF，但他们认为其他人都需要这样做。

7. 什么时候进行大量的需求设想是有意义的?

您需要花费比我前面描述的更多的时间来进行需求想象的原因有几个。这些原因是:

1. 你在一个未知的问题空间中工作。您正在处理的问题空间对您的组织来说可能是全新的，因此您可能需要进行更多的初始需求设想，以便更好地理解该空间。在这种情况下，您可能会发现需要在敏捷生命周期的早期创建用户界面原型，这是一个迭代工作，可能需要几周甚至几个月的时间。但是，要认识到您对问题空间的理解仍然需要在整个项目中不断发展。
2. 你在做一个商业产品。很难获得对最终用户的常规访问，这增加了项目的风险。处理这种风险的一种方法是在生命周期的早期与潜在客户保持焦点小组，以便更好地理解他们的需求。由于持有焦点小组的费用，请记住，软件开发是一项经济活动，您的动机是尽可能少地持有。这反过来又促使您比通常情况下提前进行更多的需求建模。但是，这并不意味着您只需要预先执行此操作。明智的产品负责人/经理将与关键的终端用户/客户(或潜在客户)保持联系，并在整个项目中从他们那里获得反馈。
3. 您的治理框架是串行的。许多IT治理框架(尽管它们声称不知道流程)都包含一系列里程碑，这使得软件开发团队很难真正从敏捷方法中获益。好消息是，可以采用支持敏捷方法的精益治理。坏消息是，治理人员通常似乎具有命令和控制的文化心态，使得精益治理所提倡的协作方法对他们来说是一个陌生的概念。遗憾的是，在实践中似乎很难找到合适的IT治理。
4. 你在做系统工程。在系统工程项目中，使用硬件的限制，特别是在开发硬件的时候，会促使您提前进行更多的需求探索，因为如果您的硬件需求出现错误，那么在生命周期的后期修复这个问题的代价将非常昂贵。我强烈建议您阅读实时敏捷，如果您正在这个领域工作。
5. 你的合同要求这么做。许多IT项目涉及将工作外包给其他组织。尽管采用敏捷方法进行外包是可能的，但不幸的是，许多合同采购人员仍然没有理解敏捷，仍然采用串行方法进行开发。这意味着他们编写的契约通常需要使用BRUF方法，即使契约也可能指定开发团队采用敏捷方法进行开发。在这种情况下，我能给出的最好的建议就是尽你所能，与你的合同人员紧密合作，这样他们就能理解他们在合同中所写的含义。
6. 你的组织文化促进了它。许多人仍然在具有串行文化的组织中工作，其结果之一是开发团队将需要预先做太多的建模工作。解决办法是帮助改变文化，这说起来容易做起来难。

请认识到，在敏捷生命周期的早期，很少需要进行大量的需求建模，这些原因可能在不到10%的时间内适用。此外，请记住，与BRUF相关的风险不会在这些情况下消失——您所做的是接受一些风险来降低其他风险。它总是一个权衡的集合。

8. 人们真的在这么做吗?

是的!在我2007年3月的敏捷采用率调查中，我提出的一个问题是，最初的敏捷需求建模在敏捷团队中有多有效。结果如图10的直方图所示。正如你所看到的，敏捷者实际上在实践中做模型。78%的受访者说,他们的组织在做敏捷表示,那些团队也做最初的高级敏捷需求建模,和85%的团队发现的努力值得的(他们给它的评级3或更多的5)。同样的,2008年以电脑建模和文档的调查发现,素描是最常见的主要建模方法(参见图11)。2013年Ambysoft敏捷项目启动调查(直接调查了敏捷社区)发现，超过90%的受访者表示他们的敏捷团队进行了某种形式的预先需求建模。

图10。敏捷团队建模的采用率。

总之，在敏捷软件开发项目的开始阶段进行足够的初始高级需求建模。您不需要很多细节，也不需要很多文档，但是您需要对范围有一个初步的了解。通过对将要构建的内容构建一个初步的远景，并通过处理围绕成本和收益的基本业务问题，您将快速地将您的项目置于坚实的基础之上。

 

原文：http://agilemodeling.com/essays/initialRequirementsModeling.htm

本文：https://pub.intelligentx.net/agilemodeling-requirements-envisioning-agile-core-practice

讨论：请加入知识星球或者小红圈【首席架构师圈】