浅析需求范围蔓延的识别和控制方法

引子

最近与一位SM的探讨交流时，听到他抱怨说，当我们团队最初接到SE完成的产品需求时，范围只有一点点，但是等到测试专家确定了测试策略之后，需求的实际范围就成倍扩展，远远超出原价预估的规模，导致团队无法在一个迭代内完整交付。

这是怎样一回事呢？我想这位SM遭遇到了范围蔓延的困扰。

范围蔓延的概念

范围蔓延，顾名思义就是说，需求在实现过程中，因为分析过程的深入细化，其余干系人的未识别需求逐渐显现，出现需求范围的不断扩大，出现交付进度趋于失控的情况。这是一种未经控制的产品或者需求范围的扩大，由于原价估算的时间、成本和资源均没有进行相应的调整，这对于承接需求的团队来说，是不公平的，上面那位SM的抱怨是正当的。

范围蔓延的后果

遭遇范围蔓延的后果，必然不是好果子。要么交付延期，要么质量下降，顺带着还会折损少量团队的士气。一句话，多快好省的完美情境是不存在的，只能在范围、进度、成本和质量之间获得一种动态平衡，才能健康稳固的交付。

范围蔓延的分析

说到这里，究竟是什么起因让范围蔓延变成了现实问题的。我们知道，需求的类型至少包括如下方面：功能、性能、安全、接口、质量、可靠性、可测试性，等等等等。而客户最初提出的需求范围，仅仅局限于功能方面，其它一系列隐含的需求都可能没有被提及，假如需求分析师的视角也局限于客户提出的范围内，那结果是可以推断的，给出的范围估算一定是局部的，不充分的。剩下的需求范围只能落到需求承接开发之后过程中逐渐被发掘和分析出来，其结果必然走向范围蔓延。

范围蔓延的控制

有没有可行的方法来控制范围蔓延？至少有两种方法可以控制范围蔓延：

1、严格执行范围变更控制，超出原价需求范围的内容，全部走CCB流程，就是要求项目给出决策，要么加时间，要么加资源，保证团队的交付质量不下降。这是被动接受型的策略，时机太迟，效果不好。

2、严格建立需求分析输出模版，把各种需求类型的输出内容都格式化，要求需求分析师完整填写，从结果上保证需求范围的完整性。这是主动减轻的策略，效果的好坏取决于执行过程的监控力度，效果中等。

范围蔓延的根源

其实吧，范围蔓延的根本起因，还是需求分析参加者的能力问题。缺少一种系统的需求分析方法论的指导和实践，这是源头上的问题。系统化、模型化的需求分析方法有多种形式，比方说，需求实例化，或者者可视化需求建模。项目选择一种适合的方法，处理人员能力的根本问题，才能处理范围蔓延的根源。

结论

最后回到最初与那位SM的对话，他说我们需要重点学习需求实例化的分析方法，尝试一下处理需求范围完整的问题，也尝试一下处理需求场景拆分验收交付的问题。

只需团队有意愿尝试，必定有机会处理自身面临的问题。我们期待吧！