你如何划分“敏捷开发”和“范围蠕变”之间的界限？

Question

在迭代开发环境中，例如敏捷开发环境，如何在常规迭代和范围蠕变的开始之间绘制线？在什么时候你告诉客户，“不，我们不能做那个改变，因为？”

Answer 1

敏捷迭代具有固定的范围;客户同意在迭代期间不更改范围（尽管他们可以取消当前迭代并重新开始）。在迭代之间，范围可能会发生巨大变化。

鉴于上述情况，敏捷项目中不会出现范围蠕变定义。范围蔓延的概念是遗留瀑布概念，它假设整个范围是预先知道的，并且在项目期间不会改变。只要每次迭代都有一个固定的目标，这个概念就不会将应用于敏捷方法。

Answer 2

这在scrum方法中非常简单。在Scrum中，您可以设置您的冲刺时间，例如2周，然后适合项目。当客户想要添加某些内容时，它会被放入待办事项中并在将来的迭代中完成。如果他们现在想要它，你将不得不向他们解释为了适应迭代而放弃的东西。

Answer 3

对于我来说，当添加新功能而没有明确调整计划时，会发生蠕变。

使用敏捷方法，用户可以深入参与决定哪些故事优先实施。因此，单件功能与另一件功能的交易更加清晰。

我不会将其称为范围蔓延，以便用户按照他们影响的顺序获得他们选择的功能。

Answer 4

这是一个简单的启发式方法，无论您是处理一个月的迭代，1-2周，还是类似看板的环境，其中功能都是连续添加的：

1. 如果您的PO（或客户）添加功能，但期望截止日期保持不变 - 它的特征是蠕变：如果他相应地改变范围和他的期望，它可能不是“Scrum”但它是敏捷的。
2. 如果您的采购订单添加了不会给客户带来任何价值的功能，那么它的范围 - 最糟糕的是 - 浪费！如果功能带来价值，那就是敏捷。

Answer 5

我认为范围蠕变有两种：

1。）扩展项目范围而不增加开发人员可用的支付/预算/时间。当pm / scrum master或其他任何不符合数字并将其他功能压缩到项目/迭代/ sprint中时，这可能发生在敏捷过程中，只有我们使用任何其他进程。

2。）扩展一个软件的范围，超出它的用途。我认为敏捷流程实际上可能有助于解决这类问题，因为功能的成本非常直接地传达给项目所有者，因此成本应该非常透明。但是反对这种范围蠕变的主要工具在任何地方都是一样的：你必须检查每个功能：我们真的需要它吗？我们在这个软件中需要它吗？或者它属于其他地方？或者在管理方面说：构建成本是多少，维护成本（经常被遗忘）是多少，它增加了多少收入。

Answer 6

的答案你在什么时候告诉客户'不，我们不能做那个改变，因为？'取决于？的价值。

通常没有充分理由说“我们不能做这种改变”。你可能会说些些话：

1. 我们可以这样做，但这意味着X，Y和Z会从冲刺目标中消失。
2. 我们可以做到这一点，但这意味着要放下发布时间表。
3. 我们可以这样做，但需要进行额外的测试。
4. 我们可以这样做，但首先我们需要X小时的重构。
5. 我们可以这样做，但首先我们需要稳定或恢复正在进行的功能X.
6. 我们可以做到这一点，但我们可以更快地做X并且仍能提供大部分相同的价值。
7. 我们或许可以做到这一点，但我们需要先做出决定才能估算出来。
8. 我们或许可以做到这一点，但我们需要花费X天的时间来确定一个峰值。

（1） - （5）只需归结为“编写代码需要时间” - 具有不同的细节级别。 （2）/（3）组合可能是最接近“范围蠕变”的传统观念。 （理论上，敏捷团队开发的软件总是处于可释放的状态，但很少有团队那么好。）但是，如果产品所有者对开发团队提出不切实际的要求，范围蔓延只是一个问题。只要开发团队提供了切合实际的估计并且产品所有者接受了它们，开发人员就不应该关注范围可以扩展到多远。

如果开发团队与产品所有者之间存在不健康的关系，那么你真正的意思是“男孩，那是多么愚蠢，我不想在其上工作”，通常的反应是让这个功能看起来真实，非常贵。

鉴于敏捷的主要好处之一是交换实际交付日期的现实估计，但这不是一个好地方。

Answer 7

敏捷最主要的弱点是，大多数做“敏捷”的人真的是坐在他们的裤子旁边。事情不应该在一次迭代中改变，但你应该允许在那之外进行改变。

Answer 8

如果客户愿意付款，为什么要说不？如果只有一个客户支付全部费用，那么他几乎完全掌握了开发的内容（“如果你不这样做，我会拿走我的钱然后告诉别人去做”）。但是，当然，如果产品拥有大量受众，那么您需要明确定义产品应该做什么，因为添加不必要的功能可能会降低其可用性。

当开发团队建议客户端不实现某些功能时，我会想到一些情况。在此之后，无论如何他都想要实施它，这是客户的责任。如果该功能与其他一些更重要的功能冲突，那么不添加它是明智的。如果该功能对客户没有太大价值，那么与实施该功能的成本相比，那么在它上面花费大量资金可能并不聪明。在某些情况下，将某些功能作为一个单独的程序实现可能更有意义，如果它们的目的与原始程序有很大不同 - 最好是让许多小应用程序各自做一件事并做得好，而不是一个很棒的应用程序。应用程序，它可以完成所有操作但不专注于任何操作。

Answer 9

你为什么要说不？我不知道你正在使用哪种敏捷开发方式。 Scrum是最符合规定的/有明确规则来满足这种情况。

1. PO（产品负责人）维护（待办事项列表）待办事项。他决定哪些项目进入积压及其优先级。 PO可以随时在待办事项中添加更多项目。然而，他并没有自由改变冲刺积压（即团队在接下来的几周内开始工作的事情）。
2. 如遇紧急情况（一些新知识），采购订单可以选择放弃冲刺并开始使用不同积压物品的新冲刺。

范围蠕变不应该再发生 - 除非你弯曲规则。你有一辆载有500箱的卡车（发布计划），要在计划中增加100箱（新功能），PO必须首先从他原来的套装中移除（去除）100个最不想要的箱子。