引子
最近与一位SM的讨论交流时，听到他抱怨说，当我们团队最初接到SE完成的产品需求时，范围只有一点点，但是等到测试专家确定了测试策略之后，需求的实际范围就成倍扩展，远远超出原先预估的规模，导致团队无法在一个迭代内完整交付。
这是怎么一回事呢？我想这位SM遭遇到了范围蔓延的困扰。
范围蔓延的概念
范围蔓延，顾名思义就是说，需求在实现过程中，由于分析过程的深入细化，其他干系人的未识别需求逐步显现，出现需求范围的不断扩大，出现交付进度趋于失控的情况。这是一种未经控制的产品或需求范围的扩大，因为原先估算的时间、成本和资源均没有进行相应的调整，这对于承接需求的团队来说，是不公平的，上面那位SM的抱怨是合理的。
范围蔓延的后果
遭遇范围蔓延的后果，必然不是好果子。要么交付延期，要么质量下降，顺带着还会折损一些团队的士气。一句话，多快好省的完美情境是不存在的，只能在范围、进度、成本和质量之间取得一种动态平衡，才能健康稳定的交付。
范围蔓延的分析
说到这里，到底是什么原因让范围蔓延变成了现实问题的。我们知道，需求的类型至少包括如下方面：功能、性能、安全、接口、质量、可靠性、可测试性，等等等等。而用户最初提出的需求范围，仅仅局限于功能方面，其它一系列隐含的需求都可能没有被提及，如果需求分析师的视角也局限于用户提出的范围内，那结果是可以推断的，给出的范围估算肯定是局部的，不充分的。剩下的需求范围只能落到需求承接开发之后过程中逐步被发掘和分析出来，其结果必然走向范围蔓延。
范围蔓延的控制
有没有可行的方法来控制范围蔓延？至少有两种方法可以控制范围蔓延：
1、严格执行范围变更控制，超出原先需求范围的内容，一律走CCB流程，就是要求项目给出决策，要么加时间，要么加资源，保证团队的交付质量不下降。这是被动接受型的策略，时机太迟，效果不好。
2、严格建立需求分析输出模版，把各种需求类型的输出内容都格式化，要求需求分析师完整填写，从结果上保证需求范围的完整性。这是主动减轻的策略，效果的好坏取决于执行过程的监控力度，效果中等。
范围蔓延的根源
其实吧，范围蔓延的根本原因，还是需求分析参与者的能力问题。缺少一种系统的需求分析方法论的指导和实践，这是源头上的问题。系统化、模型化的需求分析方法有多种形式，比如说，需求实例化，或者可视化需求建模。项目选择一种适合的方法，解决人员能力的根本问题，才能解决范围蔓延的根源。
结论
最后回到最初与那位SM的对话，他说我们需要重点学习需求实例化的分析方法，尝试一下解决需求范围完整的问题，也尝试一下解决需求场景拆分验收交付的问题。
只要团队有意愿尝试，必定有机会解决自身面临的问题。我们期待吧！
