Language agnostic 什么是范围蠕变？

这将是所有noob问题中的noobist，但范围蔓延到底是什么，它意味着什么？

是指项目不断地变得比最初计划的更大、更复杂，因此永远落后于进度、超出预算。

范围蔓延“指项目范围内不受控制的变更。当项目范围没有正确定义、记录或控制时，就会出现这种现象。这通常被认为是一种必须避免的负面事件。”

---

.

你从一只老鼠开始，最后是一头大象

---

换句话说，需求每天都在变化，您应该交付的内容与项目开始时应该交付的内容完全不同

当您开始项目时，您设置了某些参数。这些参数是您的范围。您应该考虑您的项目应该做些什么，在多大程度上l成本，以及完成需要多少时间。当更多的功能、时间、金钱……潜入到项目中时，这可以称为“范围蔓延”，它比我所能表达的更完整

范围蔓延（也称为需求蔓延，或厨房水槽综合症）在项目管理中，指在项目开始后的任何时候，项目范围内的变化、持续或不受控制的增长。当项目范围没有正确定义、记录或控制时，可能会发生这种情况。通常认为这是有害的。这与特征蠕变有关，但与特征蠕变不同

范围蠕变可能是以下原因造成的：

• 差的变更控制
• 缺乏实现项目目标所需的适当初始识别
• 弱势项目经理或执行发起人
• 当事人之间沟通不畅
• 缺乏最初的产品通用性

---

范围蔓延是指需求不断被修改或添加到当前产品版本中。例如，您向客户/用户显示演示，他们请求新的报告/按钮/字段。当开发人员想要添加新的“酷”时，也可能发生这种情况“功能等，而不需要它们。最好通过管理项目发布周期来防止这种情况。人们建议特性是一件好事，但是每个参与的人都需要了解对项目和预算的影响。考虑将新的特征请求添加到一个列表中并定期开会，以决定哪些新特征添加到“下一个版本”。

< P>在特征爬行的情况下，我认为需要有一个因素来帮助产品的崩溃。例如，一个城市的发展是好的——城市蔓延是坏的

或者在UI设计的情况下。。所有相关的功能都被卡在一个控制屏幕上——新的功能不断被添加到一个点上，在这个点上，它们微不足道的存在让更多的人感到困惑，而不是发现这些功能有用

为了符合特性爬行的资格，他们应该通过测试，即增加不必要的复杂性或在系统生命周期中使用不必要的扳手。最初不符合此标准的计划外功能不应被简化为功能蠕变

范围蠕变与功能蠕变仅在产品范围级别进行协调。。。例如：

您的团队正在建造一个“空气吸盘”（tm），它从一个位置吸入空气，并将其输送到两个街区以外的工厂。空气吸盘的作用范围是移动空气

---

然后管理层意识到，吸管装置还需要吸管和输送水和沙。空气吸盘从未设计用于运输液体或颗粒材料，因此将空气吸盘的范围扩大到必须对其进行重大改造以满足新的运输要求的程度。

如果您有适当的变更控制，可能是摇钱树

---

有一张著名的照片，上面有一艘大动力船，船上拖着一条小滑道。跑道被称为“原始合同”，动力艇被称为“变更请求”

功能、预算、计划：选择任意2个，但不是全部3个

范围爬行有两种定义

• 没有。范围以不受控制的方式改变，增加了成本和风险

• 肯定的。范围以不受控制的方式改变，因为我们的幻想项目计划是错误的，我们开始学习我们不希望学习的东西

大多数人似乎都喜欢第一个

然而，第二个更准确。少数认识到范围蔓延的管理者能够明智地进行管理并完成工作

其余的管理者认为不受控制的学习是一种威胁。该项目不会在幻想的时间表或预算中创建期望的可交付成果。这意味着要么缩小范围，要么扩大预算

注意，大多数敏捷方法似乎并不太关心范围或范围蠕变。随着对下一个版本的关注越来越少，大的前景变得不那么危险和可怕

---

学习——在敏捷环境中——也会导致范围蔓延，但这是一件好事。那些永远不会有用的东西会被推迟。开始时看似不重要的东西会加快速度。

范围蠕变是对最初商定的规范/项目范围/定义的任何更改。这种变化可能是由于发现了先前的未知因素、内部/外部市场变化、技术变化或计划发起人想要更多的东西。当没有变更控制流程来审查、接受或拒绝变更时，会对项目产生负面影响。

范围扩展如何影响产品进度？ 有没有一种方法可以让范围从您的开发过程中逐渐消失？ 你的项目经理如何处理范围蔓延？ 什么是从范围爬行中产生的最好的特性？

---

等等等等。

范围蔓延就像色情：当你看到它的时候你就知道了

厨房水槽综合征+1。仅