答复。

项目范围（scope）是对项目应实现的内容及其排除范围的明确定义。准确的范围定义有助于理解工作量，防止“需求蔓延”，并有效控制资源和时间。

业务分析师通过以下方式描述范围：

• 利益相关者地图。
• 上下文、边界和接口的图表。
• 用户故事或用例格式的功能目录。
• 排除清单（out of scope）的备忘录。

关键特点：

• 在详细需求制定之前，项目范围就已确定。
• 成为任何变更协调的基准。
• 为团队建立实际可衡量的承诺量。

设置陷阱的问题。

仅仅确定功能的基本清单，就可以认为范围是固定的吗？

不可以。必须明确指出不包含在项目中的内容，以避免双重解释和“隐含”期望。

业务分析师是否有权单方面扩大范围，如果他认为这样做是有益的？

不可以。任何范围的变更都需与客户/利益相关者协商，并通常通过变更请求（change request）程序正式化。

项目范围在其达成共识后可以更改吗？

可以，但必须通过正式的变更管理流程，重新审查计划、成本、时间评估，并征得所有关键利益相关者的同意。

常见错误和反模式

• 未明确定义哪些内容包含在项目中/不包含在项目中。
• 在不考虑对时间和预算影响的情况下添加新任务。
• 仅通过口头协商来确认范围，而没有文件记录。

生活中的例子

负面案例

范围以口头形式确定，没有明确的文档。在过程中出现了额外的任务，这些任务是利益相关者“期望”的。

优点：

• 灵活性，有适应新任务的可能性。

缺点：

• 项目超出时间和预算范围，团队与客户之间产生误解。

正面案例

分析师记录范围，协调排除项，任何变更通过变更请求系统进行。

优点：

• 对资源的控制，项目的透明性和可控性。

缺点：

• 固定的范围需要额外的时间来协调变更。