敏捷、瀑布和需求变化

Question

是否有人将项目定义为“敏捷”(Agile)被需求更改淹没的问题？我从事一个开发项目，在4周内运行Sprint，但是在这些Sprint之间总是有变化的。那么，它仍然被定义为敏捷吗？我觉得这是一个子敏捷过程--敏捷过程的需求应该在sprint开始时定义，并在结束时进行审查。我说得对吗？请告诉我你在这方面的经历。

Answer 1

敏捷过程的需求应在sprint开始时定义，并对其进行审查。我说得对吗？

不，这取决于项目的性质(以及过程)。

有一些敏捷开发模型，在这些模型中，需求应该在sprint期间得到修正，并且应该只对下一个sprint进行更改(一个突出的例子是Scrum)。

但是，也有一些过程几乎可以随时发生更改(只要客户接受更改导致的延迟和额外工作)。看板通常用于管理这些工作流(尽管看板也可以与Scrum相结合)。

您所遵循的模型取决于每个项目的细节。

因此，是的，如果客户认为他们需要不断更改需求的可能性，那么敏捷过程就可以适应这种情况。然而，客户应该意识到不断变化的后果，并且应该理解他们会减缓项目的速度。

这归结为敏捷宣言中的原则--“个人和交互而不是过程和工具”，以及“响应改变而不是遵循计划”。

Answer 2

我认为你应该问的问题是:为什么你会被需求的变化所淹没？常见的原因包括：

• 开发人员没有(足够多)与最终用户联系，因此他们无法理解用户的需求。相反，他们把需求当作一个抽象的魔方--他们遵循需求的字母，甚至没有试图理解它们的精神。
• 有些人(例如市场营销人员)正在添加对最终用户没有任何意义的要求(例如，小册子上的声音很好)。因此，在“真实”需求和“其他”需求之间存在着一场战斗，这场战斗是在开发人员的支持下进行的。
• 这个项目的范围是没有定义的(“好吧，如果你正在实现一个文字处理器，你就不能添加一个小模块来计算我们的工资吗?哦，另外一个开发团队的比尔问，让文字处理器编译C++代码也有多难？”)

不管根本问题是什么，你都需要解决这个问题。将其淹没在“敏捷”层(或任何其他方法)下是行不通的。

Answer 3

至少在Scrum中，Sprint的范围是固定的。Scrum似乎是当今管理类型中最流行的敏捷过程。如果您的sprint在Sprint期间发生了变化，那不是Scrum，而是混乱。应该在Sprint开始时创建，并保持固定状态直到sprint结束(此时您将为下一个sprint创建一个新的)。

如果您的产品待办事项在冲刺过程中发生了变化，那没什么大不了的。这些更改只是成为新的工作，它与下一次冲刺的任何其他需求一样，被排序、估计和选择。但是，如果需求发生了如此大的变化，产品负责人不得不定期取消sprint，那么大写“T”就有问题了。

也许你需要短跑？