您如何应对不断变化的需求？[关闭]

在我目前的工作中，感觉我们有很多需求变更。我们是一家“敏捷”商店，所以我认为我们应该进行调整，而不能进行调整，但是有时候变化很大，没有什么微不足道的。

我的问题是，您如何有效地传达变更成本？由于敏捷，如果更改足够大，将会从当前的sprint中删除某些内容，但是通常只会在下一次添加。由于我们的模型是SaaS，因此最终客户实际上是企业本身，他们知道n周后将获得削减功能。

我想我要了解的是删除某项功能实际上并没有什么用，因为它仅延迟了n周。您还需要通过什么其他方式来使企业了解变更成本？

@Joe“我们是一家“敏捷”商店，所以我知道我们应该进行调整，而没有进行调整，但是有时候变化很大，没有什么微不足道的。”

如果您的流程不允许您控制需求的变化率，那么您的流程就不是敏捷的，而是偶然的。敏捷并不意味着“采取一切以自己的方式来做”。

为了控制需求变更/蠕变，您可以在过程中采用需求不变的概念（这是Scrum的核心。）将需求变更视为将旧需求替换为新需求。您必须积压需求，并且必须让用户选择他/她想要实现的需求。

您想在两周之内得到X和Y，但是突然间您想要Z。那么，我可以在4周内为您提供全部三个。或者，我可以在两周之内给一个（X和Z）或（X和Y）或（Y和Z）一对，然后其余的再交付。选择。

这就是您与客户进行谈判的方式。这是您传达需求变更成本的方式。如果您的团队没有这种能力，那么您就不在敏捷商店中，对此您无能为力。很烂，但这是真的。

如果您可以协商，则必须（精确地）跟踪实现需求和需求变更所花费的时间。也就是说，您必须从过去和现在的项目中收集此数据。

您收集每个请求（或受N个请求影响的模块）的原始时间估算和实际完成时间（以及开发人员数量之类的资源）。更好的是，估计请求/请求更改的大小（根据过去项目和请求中的代码行或功能点来进行。）

假设您有一个可以与用户交流的指标。您知道，一个新请求将使用1K行代码，或10个网页，每个页面平均5个输入字段（50个功能点）。

然后，通过查看特定于您过去项目的历史数据（某些按代码行，某些按网页，某些按实际功能点），就可以根据绝对完成时间来估算这些成本的成本。对于那些具有足够数据的用户，您还可以确定那些跟踪实际开发人员人数的要求。

然后，您使用它并根据历史数据告诉您的客户；您认为项目失败倾向于遵循指数分布。然后为您的客户准备了以下参数：

根据我们过去和现在的项目数据以及可用资源，您所要满足的要求

1. X的完成时间（失败概率为25％（成功的75％））

2. 完成失败所需的时间*失败的5％（或成功的95％）：1.5 * X

3. 完成* 95％失败（或5％成功）的时间* 0.5 * X

根据时间资源量而定的失败概率通常达到95％，25％和5％（类似于指数分布）。您传达的信息是，一定的基准量可以提供一定程度的成功机会（但存在实际风险） ）。其中的1.5几乎可以给您带来一定的成功机会，而风险却很小，但是要远小于此几率（原始0.5的保证几乎可以肯定的失败）。

你让他们消化。如果他们仍然坚持冒险的主张（昨天完成！），至少您已经书面告知他们。如果希望您的团队不仅敏捷，而且希望像工程专家那样，那么客户可能会认真考虑您的人数，并据此安排此需求和将来的要求。

作为工程师，您需要以工程师，可验证的明确术语解释要求更改不是一顿免费的饭菜。

根据您的描述，您没有问题。他们要求进行更改，要么愿意等到您说可以完成，要么愿意推迟其他功能。似乎在时间，资源和需求之间取得平衡。

您可以尝试设置新添加/更改的最低年龄（不适用于错误修复）。例如，直到3周之前，无法进行新的更改。

具有最低任务年龄是一件好事，因为在开始时，每个任务看起来都非常重要，但是如果您等待一段时间，则重要性通常会大大下降。根据您的时间间隔，它将为您至少提供您正在处理的任务的稳定时间。

要跟踪年龄，您可以将任务添加到某些列表中，但是直到该期限到期，它们才被视为要处理的任务。

这是一个非常常见的问题，无论项目以技术术语进行进度有多快，客户都认为项目进展缓慢得多，并且可以随意更改需求，因为他们希望开发人员无论如何都不要做太多事情。

这种错误的看法来自三个主要的开发任务，这些任务耗费时间，并且永远不会被客户适当地考虑：

1. 代码审查/清理：旧代码变得肿，混乱，需要定期审查和清理，这需要很多时间，客户永远也不会相信。
2. 安全审核和修复：特别是如果您有初级团队成员，您将遇到很多与代码相关的安全问题，并且您将希望定期检查所有已编写的新代码并重写从安全性上看不太好的东西角度来看，客户这段时间永远不会知道或无法解释。
3. 与体系结构有关的更改：不断增长的代码库可能（并且很可能会在多个点）需要结构上的重新思考和重构，这可能涉及：A-与性能有关的更改/优化（算法更改，库替换，缓存引擎等）。或：B-与生产力相关的更改/优化（可读性，代码可重用性，易于理解，新的编码约定，新的框架等）。

最终客户将不会理解上述任何内容，也不能适当考虑这些内容。

基本上没有“视图”（GUI元素）的内容都没有完成。

我们称其为projenix定理，哈哈不只是在开玩笑：D