敏捷，瀑布和需求变化

有没有人遇到过这样的问题，即定义为“敏捷”的项目因需求变更而超支？我正在进行一个开发项目，该项目在Sprint中运行了四个星期，但是这些Sprint之间总是存在变化。那么，它仍然被定义为敏捷吗？我觉得这有点像敏捷流程-敏捷流程的要求应在冲刺开始时定义，并在冲刺结束时进行审查。我说得对吗？请让我知道您的经历。

敏捷过程的要求应在冲刺开始时定义，并对其进行回顾。我说得对吗？

不，这取决于项目的性质（和过程）。

在某些敏捷开发模型中，要求在冲刺期间固定需求，并且仅在下一个冲刺时才更改（最重要的示例是Scrum）。

但是，在某些流程中，几乎任何时候都可能发生更改（只要客户接受更改引起的延迟和额外工作）。看板通常用于管理这些工作流程（尽管看板也可以与Scrum结合使用）。

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

因此，是的，如果客户认为他们需要不断更改需求的可能性，那么敏捷的过程就可以解决这个问题。但是，客户应了解不断变化的后果，并应了解它们会减慢项目速度。

这可以归结为敏捷宣言中的原则，即“流程和工具上的个人和交互”以及“响应计划后的变更”。

我认为您应该问的问题是：为什么您因需求变更而超支？常见原因包括：

• 开发人员与最终用户没有足够的联系，因此他们无法理解用户的需求。取而代之的是，他们将需求像抽象的魔方一样对待-他们遵循需求的字母，甚至没有试图理解他们的精神
• 某人（例如，来自营销部门）正在添加对最终用户没有任何意义的要求（例如，在小册子上听起来不错）。因此，在开发人员的支持下，“实际”需求与“其他”需求之间存在着争斗
• 该项目的范围是不确定的（“好吧，无论如何，如果您正在实现文字处理程序，您是否不能仅添加一个用于支付工资的小模块？是为了使文字处理器也编译C ++代码？”）

无论根本问题是什么，您都需要解决。将其淹没在“敏捷”层（或任何其他方法）下是行不通的。

至少在Scrum中，这似乎是当今最受管理类型欢迎的敏捷过程，Sprint的范围是固定的。如果您的Sprint待办事项列表在冲刺期间发生变化，那不是Scrum，而是混乱。Sprint待办事项列表应在sprint的开始处创建，并保持固定状态，直到sprint结束（此时您将为下一个sprint创建一个新的Sprint待办事项列表）。

如果您的产品待办事项在冲刺期间发生变化，那没什么大不了的。所做的更改将成为对新工作的优先级，估算和选择，就像对下一个sprint的任何其他要求一样。但是，如果需求变化太大，以至产品负责人必须定期取消冲刺，则麻烦您的大写字母为T。

也许您需要较短的冲刺？

出于程序员的理智，最好是在修订/冲刺期间不更改要求。

根据您的情况，有两种明显的选择：

1. 短跑
2. 让客户同意在修订/冲刺期间不更改要求，除非整个修订/冲刺被取消并重新计划

我强烈推荐两者。

主要的问题是您认为自己正在使用Scrum，但是没有使用。尤其是您的产品所有者没有遵循它。在Scrum中，冲刺是一个安全区域，除非取消当前冲刺，否则无法更改已提交的用户案例。Scrum主管有责任执行此操作。如果这在您的环境中不起作用，则是一个过程问题=您没有使用Scrum。

您可以做的最简单的更改（如果您想遵循Scrum）是缩短sprint-例如一周。在Scrum的早期，可以选择4周的冲刺，但今天常见的是1-2周，而3周则被视为上限。在不断变化的环境中4周是很长的时间。