实例化需求与项目管理的思考

1 背景

在项目开发的过程中，存在各种各样的突发情况，比如：业务方需求不明确，开发、产品对业务规则的认识不统一，需求变更的过程中没有重新进行沟通梳理。这些变动的细节只要没有得到所有项目成员的一致认可，就会出现认知不统一的现象，这些认知不统一的现象就是失焦。

在日常的开发过程中很容易出现失焦的情况，举个例子：现有的系统为了吸引客户注册VIP，同时为了避免运送电子产品和大件物品的后勤问题，决定对系统只提供书籍的免费送货服务。“vip客户如果购买五本以上书籍，系统将会提供免费的送货服务”，需求分析人员分析了这样一个需求之后，将需求传递给开发团队，当vip客户购买5本以上书籍的时候，提供免费送货服务。

当需求给到开发团队后，开发和测试都理解了这句话，然而在测试验收的时候，他们对一些情况产生了失焦：vip客户购买了5本书+1个电冰箱的情况下是否应该免费送货？测试认为应该提供免费送货，因为vip客户购买了五本书。开发认为不应该提供免费服务，因为只有书籍可以免费送货。最后需求分析人员、开发、测试重新对这个场景进行确认，确定在这种情况下不提供免费送货服务，问题得到了解决，项目也成功交付。

简单的一句需求描述，在开发、测试之间就会形成失焦，那么在复杂的日常项目开发中，又会形成多少失焦的情况呢？引起失焦的有很多方面，例如业务方需求不明确，目标不清晰，无法衡量产出等都会引起失焦，然而越晚产生失焦，需要承受的代价就越大。

在软件开发，项目管理的过程中有很多办法可以解决失焦问题，下面就给大家介绍一种规避失焦风险的方法：实例化需求。

2 什么是实例化需求

2.1 实例化需求的简介

“实例化需求说明是一组过程模式，它帮助团队构建正确的软件产品。使用实例化需求说明，团队编写的文档数量恰到好处，在短迭代或基于流的开发中可以有效地协助变更。”

图1 实例化需求规则说明

上图是对实例化需求的规则说明，具体的步骤为：

• 需求提炼成为业务规则

• 用例子来具象规则

• 用例子来分析和澄清需求

• 这些例子随后会转化为测试用例

• 最后再通过测试验证需求

如果将背景中的需求按照实例化需求的过程模式，就会形成这样的说明：

关键实例：免费送货

• VIP客户购买5本书籍可以获得免费送货

• VIP客户购买4本书籍不可以获得免费送货

• 普通客户购买5本书籍不可以获得免费送货

• VIP客户购买5台洗衣机不可以获得免费送货

• VIP客户购买5本书籍+1台洗衣机不可以获得免费送货

与上述的“当vip客户购买5本以上书籍的时候，提供免费送货服务” 的需求相比，“实例化需求”方法从场景出发，以精简的业务实例来澄清需求，通过准确且具体的实例来降低各个干系人之间的理解成本，快速对焦形成共识。

2.2 实例化需求的优点

实例化需求可以帮助团队构建正确的软件产品，而技术实践可以确保正确的构建产品。两者侧重点不一样，实例化需求可以构建正确的产品，而非正确的构建产品，而开发往往是正确的构建并构建正确的软件产品。

图2 实例化需求与产品的关系

这种实例化需求的沟通方式，核心是让所有干系方进行有效的协作和沟通，用实例的方式说明需求，用自动化测试的方式频繁地验证需求，从实例化的需求说明和自动化测试用例中演进出一套“活文档系统”。这套“活文档系统”既可以有效地对系统进行说明，又可以当做交付验收的标准。

• 实例化需求说明能够在适当的时间提供恰好够用的文档，帮助使用短迭代或基于流的开发过程构建正确的产品
• 更高的产品质量，显著地减少返工，并且能更好地促进分析、开发和测试之间的协作

• 更低的知识传递瓶颈，更好地协作。实例化需求可以让团队清晰的定义一个可以普遍理解跟客观衡量的指标

3 如何进行实例化需求

3.1 从目标中获取范围

如果依赖业务方给出对应的用户故事、用例清单或者其他相关信息，那么本质上就是在让业务方设计解决方案。但业务方并不是专业的软件设计师，如果让业务方去界定范围，那么得到的结果就是业务方所要求的，但却不是真正合适的。如果开发团队从业务目标作为起始，然后协作界定可以实现目标的范围，再同业务方一起确定解决方案，这种解决方案往往比业务方自己想出来的方案更优、更容易交付和维护。

3.2 协作制定需求说明

如果在设计需求阶段，开发跟测试都没有参与，只是单独的需求传达者，那么在实践过程中很容易造成误解，在沟通的过程中，也很容易丢失细节，结果就是在交付之后验证失败，这些额外的不必要的返工完全可以避免。在设计需求、完善需求的过程中，协作制定需求或者需求反述能够充分利用团队的知识经验，让每个人更好的参与到交付过程中。

3.3 提炼需求说明

在需求说明的过程中，得到的实例往往会包含很多不必要的细节，这种情况下就需要提炼出来足够精简的业务规则，通过业务规则来形成需求说明，并形成关键实例。明确系统应该正确地实现哪些功能，而不是系统应该如何实现。好的关键实例可以当作验收条件，当所有实例在系统中都能正常工作时，开发才算完成，此时对应的实例其实已经阐释了对应的需求，这也是一种工作规范和验收测试。

3.4 自动化验证

形成固化的关键实例之后，测试人员可以根据关键业务规则形成自动化用例。这样在每次开发的过程中，就可以快速且高效地自动验证对应规则；在自动化过程中，也不需要改变额外的需求说明，这些关键实例与最开始的需求一致。

3.5 演化形成文档系统

随着项目发展，每个开发版本过程中形成的业务规则都会汇聚形成一个文档，通过关键实例来说明需求的变化与领域的关键信息，最后形成一个关于系统功能的可靠、权威的信息源。任何人都可以获得，同时更容易阅读和理解，支持人员可以查明系统功能与设计意图，开发者可以将其作为开发目标，测试伙伴可以用它来进行测试。

4 实例化需求的落地

根据不同的团队特点，实例化需求的推进方式可能不同，具体要根据实际的团队情况来进行实例化的落地。

4.1 团队构成

首先形成一个工作坊团队，一个研发组内需包含1个开发，1个测试，1个需求分析人员。形成一个小型工作坊团队可以从不同方面获得良好反馈，同时在项目实施的上下游更容易形成统一语言。

4.2 规则梳理

梳理目标需求，提取业务规则，形成一份实际的业务规则功能文件（GIVEN-WHEN-THEN）。

• GIVEN：一个前提
• WHEN：当某个行为发生时;

• THEN：满足了什么条件;

将正常情况与异常情况区分处理，尤其是对应的边界值。

回到上述情境，当VIP客户购买一定数量的书籍时，就为他们提供免费送货服务，免费送货服务不提供给普通客户或购买非书籍的VIP客户。假定要获得免费送货服务，至少需要购买5本书籍，那么我们会得到下表这样的预期：

客户类型	购买行为	送货服务
vip客户	5本书	免费，标准
vip客户	4本书	标准
普通客户	10本书	标准
vip客户	5台洗衣机	标准
vip客户	5本书+1台洗衣机	标准

用given-when-then的三段式表达，就形成了这样的说明：

given	when	then
vip客户	买了5本书	可以选择 1 免费送货 2 标准送货
vip客户	买了4本书	标准送货
普通客户	买了10本书	标准送货
vip客户	买了5台洗衣机	标准送货
vip客户	买了5本书+1台洗衣机	标准送货

以上的说明很好地阐释了对应业务规则，同时也具备可测试的特性，并且足够的清晰明确，不需要做额外的说明。

4.3 业务规则同步

再形成对应的业务规则后，在研发组内对具体的实例需求进行规则验证，同时更新对应的具体规则。

4.4 自动化构建

对应的开发人员与测试人员形成单元测试/自动化测试脚本，用于验证对应规则逻辑。

5 实例化需求与项目管理

项目管理是领导一个团队在规定时间内实现目标和达到成功标准的过程，其主要挑战在于在给定的约束条件下实现所有项目目标，在社会科学领域是管理学的一个分支学科。这些讯息通常包含于在开发过程初期建立的项目文档中。主要的约束条件是范围、时间、预算其次是优化资源配置的必要投入，并将其应用于实现既定目标。（引用自维基百科）

因为项目管理的知识体系过于庞大，因此把项目管理分为十大领域和五大过程组。

5.1 十大领域

图3 项目管理十大领域

十大领域分别为资源管理、采购管理、沟通管理、风险管理、整合管理、干系人管理、范围管理、进度管理、成本管理、质量管理，每个项目都可以从以上的十个角度进行项目拆解与思考。

实例化需求的落地过程中，主要从以下四个角度对项目进行干预，助力项目成功落地。

• 资源管理（拉通团队内部形成小型工作坊）

• 沟通管理（运用业务规则形成关键实例，通过实例进行沟通）

• 范围管理（关键实例界定了具体的业务范围与边界）

• 干系人管理（实例化需求可以清晰的描述项目成功后的对应业务流程，降低干系人的沟通成本）

5.2 五大过程组

图4 项目管理五大过程组

五大过程组分别为启动过程组、规划过程组、执行过程组、监控过程组、收尾过程组。这五大过程组是非常经典的项目管理模型，形成了一个普适PDCA循环，意思是任何事情都需要经过计划(Plan)、实施(Do)、检查(Check)、处理(Act)这四个步骤，可以说这四个步骤形成了一个简单的思考和执行框架。

五大过程组其实通过不断的规划->监控->执行的过程，形成一个项目研发的增长飞轮，可以逐步提升项目开发效率。

实例化需求落地过程中，通过不断新增对应的实例需求，形成自动化的业务规则，自动化的业务规则频繁验证了实例的需求。开发团队在开发过程中逐步增加新的实例需求，形成了一个项目研发的增长飞轮，逐步提升项目研发效率。

图5 PDCA循环

6 总结

实例化需求通过抽象的业务规则，形成精简的业务实例，通过准确的业务实例与边界值来描述需求的落地，产生了清晰明确并且可衡量的目标。在业务实例构建阶段，通过开发、测试、业务分析人员的统一讨论参与，从初期就降低了产生失焦的可能。

实例化需求是一种项目管理方法的简单落地，在频繁的需求迭代过程中，不断更新详细的需求说明与测试计划需要花费大量的时间成本。通过实例化需求的方式，小步快跑、快速迭代，降低开发过程中的“失焦”，既能正确的构建产品，也能构建正确的产品。

7 参考文献

[1] 实例化需求：团队如何交付正确的软件 (图灵程序设计丛书 39) [塞尔维亚] Gojko Adzic

[2] 用“实例化需求”，让需求澄清更高效(上) https://developer.aliyun.com/article/917364

本文作者

凯多，来自缦图互联网中心后端团队。